 |
 |
Mikael, it makes sense if I willfully forget the meaning of the word "class" and don't think about the classes that have sub-classes, which make more sense to me. ;-) Actually, it makes the most sense if I think of it as an abstract object, in OOP terms. But if we are to call it class, I'll try to do that. It's a shame that there are two logically different relationships that get the term "class." Some of the RDA structures that will be this kind of class are unfortunately artificial, because they are simply based on the fact that in the card catalog days they were data elements that were written on the same line -- and therefore were gathered into a single field when the card data became machine-readable. I think that this is an area where we will eventually want the library data to abandon the now unnecessary empty node. kc On Fri, Jan 2, 2009 at 10:40 AM, Mikael Nilsson <[log in to unmask]> wrote: > Karen, > > Classes as "aggregations" is a very common situation when translating > from hierarchical structures to RDF. In IEEE LOM, we have > > Learning Object > Contribution > Role > Entity > Date > > i.e. a contribution to a learning object is a three-part aggregate. > > When translating this to RDF, it naturally comes out as n-ary. We > introduce a class called lom:Contribution to hold the center node. > > There's really nothing strange with that. Think about the Book+Creator > example: > > Resource > Creator > Name > E-mail > Address > > In this case, an Agent class is very natural for the middle node, with > name, e-mail, address properties. > > To come up with the right abstraction for the class is sometimes a bit > interesting - as in the above example, you want to avoid coding the > "Creator" characteristic into the class. In other words, the class > reflects the properties used to describe it (Agents have names etc), but > does NOT necessarily reflect the specific context where it is used > (Agents can related to resources in other ways than being Creators). > > Hmm. did that make any sense? > > /Mikael > > ons 2008-12-24 klockan 09:43 -0800 skrev Karen Coyle: >> Thanks, Alistair -- I checked out the n-ary relationship. Yes, I do >> believe what we have here fits that n-ary possibility, but I notice >> that you refer to the "blank node" as a possible class. We need to go >> over the RDA elements and see if we can define or discovery classes. >> The particular elements that brought this up (like 'publication >> statement') are whole/part relationships. I think of classes as being >> "is a kind of" relationship. If classes can be an aggregate with >> parts, then some of these 'statement' fields can be classes. But I so >> far haven't run into classes being used in that way. >> >> kc >> >> On Tue, Dec 23, 2008 at 8:46 AM, Alistair Miles >> <[log in to unmask]> wrote: >> > On Mon, Dec 22, 2008 at 10:51:12AM -0800, Karen Coyle wrote: >> >> On Mon, Dec 22, 2008 at 9:00 AM, Alistair Miles >> >> <[log in to unmask]> wrote: >> >> >> >> > I couldn't find an appropriate property for the "size" of a >> >> > manifestation in scenario 7. >> >> >> >> It's "dimensions" -- that's what I should have written there. Sorry. >> > >> > Ah, I'll update the RDF. >> > >> >> > Not directly related to any scenarios, I found that rda:placeOfCapture >> >> > is a sub-property of rda:placeAndDateOfCapture, which doesn't look >> >> > right. This looks like a case where Tom Delsey's "sub-elements" >> >> > pattern got wrongly translated to RDF sub-properties, where rather it >> >> > should be modelled in RDF as an n-ary relation. >> >> >> >> I don't understand 'n-ary', but this is one of those areas where RDA >> >> has an "empty node" that has parts, like "publication statement" which >> >> is made up of place + publisher + date. We really didn't know what to >> >> do with those -- we could ignore the empty element and just include >> >> the "sub" elements, but we figure that since the empty ones are on the >> >> RDA list of elements people might look for them in our list. There >> >> never is a value for placeAndDate... itself, just the sub-elements. >> > >> > There's a good document on n-ary relations at: >> > >> > [1] http://www.w3.org/TR/swbp-n-aryRelations/ >> > >> > If you don't want to get into the technicalities, just look at the >> > pictures, should give a feel for the n-ary relations patterns. >> > >> > If I were using an n-ary relations pattern for an RDA publication >> > statement, I would do something like: >> > >> > ex:M1 rdf:type frbr:Manifestation ; >> > rda:publicationStatement ex:PS1 . >> > >> > ex:PS1 rdf:type rda:PublicationStatement ; >> > rda:placeOfPublication ex:PL1 ; >> > rda:publisher ex:CB1 ; >> > rda:dateOfPublication "2008"^^xsd:year ; >> > . >> > >> > I.e. the publication statement itself (an n-ary relation) becomes an >> > entity (resource) with it's own properties. >> > >> > You could also abbreviate the above, using a blank node for the >> > publication statement, to something like: >> > >> > ex:M1 rdf:type frbr:Manifestation ; >> > rda:publicationStatement [ >> > rda:placeOfPublication ex:PL1 ; >> > rda:publisher ex:CB1 ; >> > rda:dateOfPublication "2008"^^xsd:year ; >> > ] ; >> > . >> > >> > For the schema, what you need is a class for the n-ary relation >> > (e.g. rda:PublicationStatement), and a set of properties which give >> > the various participants in the n-ary relation >> > (e.g. rda:publicationStatement, rda:placeOfPublication, rda:publisher >> > etc.). Whether these properties point to or away from the n-ary >> > relation is a matter of convenience and intuition -- this is >> > illustrated quite well in the various alternative patterns presented >> > in [1]. >> > >> > Cheers, >> > >> > Alistair. >> > >> > -- >> > Alistair Miles >> > Senior Computing Officer >> > Image Bioinformatics Research Group >> > Department of Zoology >> > The Tinbergen Building >> > University of Oxford >> > South Parks Road >> > Oxford >> > OX1 3PS >> > United Kingdom >> > Web: http://purl.org/net/aliman >> > Email: [log in to unmask] >> > Tel: +44 (0)1865 281993 >> > >> >> >> > -- > <[log in to unmask]> > > Varning! E-post till och från Sverige, eller som passerar servrar i > Sverige, avlyssnas av Försvarets Radioanstalt, FRA. > WARNING! E-mail to and from Sweden, or via servers in Sweden, is > monitored by the National Defence Radio Establishment. > -- -- --- Karen Coyle / Digital Library Consultant [log in to unmask] http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet mo.: 510-435-8234 ------------------------------------