Karen Coyle
Sat, 03 Jan 2009 08:45:57 -0800
On Sat, Jan 3, 2009 at 8:01 AM, Mikael Nilsson <mik...@nilsson.name> wrote: > Karen, > > I really don't see the issue with defining classes for these object. I don't either, in the RDF sense of "class as structure." Although, as Jon points out, some of them may be syntax encoding schemes, so we need to think about it more. What I don't want is for the RDF to get in the way of presenting this to the library community, so I prefer for it to stay in the background, doing the work it needs to do without interfering with our users, who are not going to be RDF-compliant ;-). We will be pointing people to the registry to see what we have done. I'm afraid that if we start defining classes at this point we might change things to the point that it won't look like RDA to our key audience (the creators of RDA), since they don't think in those terms. This means that for we should stick with their structure and definitions (which I encourage everyone to view at http://www.collectionscanada.gc.ca/jsc/docs/5rda-elementanalysisrev2.pdf) (this is what you, Mikael, saw at the London meeting). Perhaps we can discuss where we see classes emerging, and do some background work to figure out how they could / if they could / facilitate the creation of application profiles based on RDA. The "empty nodes" in the RDA element analysis are the ones with 'element' and 'sub-element': production statement publication statement distribution statement manufacture statement series statement dissertation or thesis information place and date of capture These are NOT the only areas that might be relevant for an analysis of classes; these are just the ones where we have the 'empty node' problem. There are many elements that have a defined element and defined element sub-types, which we are treating as properties and sub-properties in the registry. Whether there are any classes to be defined around these is another large question. (In fact, I think that many of them are just properties and sub-properties.) In terms of classes, as you may know, we will be looking at FRBR and FRAD entities as classes. I think this works well for agents (group 2), but I'm less clear on the Group 1 entities (work, expression... etc.) because they have a lot of overlapping properties, and the group 3 entities (subjects) because group 3 becomes a kind of super-class, where every other class can be a member of that class. Not that that's a problem, we just have to figure out if it works for us to define it that way. I'd love to have a discussion of the implications of the FRBR and FRAD entities on the RDA data -- at the moment the connection is tenuous, and I'm not sure it's a good idea to firm it up. kc -- -- --- Karen Coyle / Digital Library Consultant kco...@kcoyle.net http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet mo.: 510-435-8234 ------------------------------------