BTW, I just looked at the ERD that was created out of the RDA
documents (and that forms the basis of the online system) (and is
unfortunately not publicly available... but we hope that it someday
will be)... and it looks like there are many empty nodes beyond the
few that I listed here. So I'll look at that some more.

Meanwhile, as you know the full draft of RDA is out, but is huge and
hard to read. (The ToC is 74 pages long!) For our purposes, it would
be good to look at the element list that I cited earlier today, and
one or two representative chapters. The list of documents is at
http://www.rdaonline.org/constituencyreview/

Chapter 0 (http://www.rdaonline.org/constituencyreview/Phase1Chp0_10_22_08.pdf)
gives an overview, but I don't think it gives you a real flavor for
the rules.
Chapter 1 (http://www.rdaonline.org/constituencyreview/Phase1Chp1_10_23_08.pdf)
might be more useful as an illustrative chapter for bibliographic
description.

The other part of RDA is "access", and the creation of access points.
These are primarily relevant to the FRBR Group 2 elements, and for
that Chapter 8 is key
(http://www.rdaonline.org/constituencyreview/Phase1Chp8_10_25_08.pdf)
as is chapter 18
(http://www.rdaonline.org/constituencyreview/Phase1Chp18_11_2_08.pdf).

I'm particularly concerned about the chapters on relationships,
chapters 17 - 22. Chapter 17 had me gritting my teeth over its concept
of "identifier."
(http://www.rdaonline.org/constituencyreview/Phase1Chp17_11_2_08.pdf)

I doubt if many of us will get through all of these documents, much
less the whole of RDA, but I recommend dipping a toe in to get a sense
of the rules and treatment of elements of bibliographic data.

kc

On Sat, Jan 3, 2009 at 8:45 AM, Karen Coyle <[log in to unmask]> wrote:
> 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
> ------------------------------------
>



-- 
--  ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
mo.: 510-435-8234
------------------------------------