On Sat, Jan 3, 2009 at 8:01 AM, Mikael Nilsson <[log in to unmask]> 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
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
|