fre 2009-01-02 klockan 11:43 -0800 skrev Karen Coyle:
> I think that this
> is an area where we will eventually want the library data to abandon
> the now unnecessary empty node.
Is it unecessary? I was under the impression that it was of some value
to keep the values together, as they have some form of relationship
(just as it would be vary lossy to introduce creatorName, creatorAddress
etc in the Book+Creator example).
Anyway, some cases are more artificial than others. Surely you don't see
the Agent example as "artificial"? Also, the LOM "Contribution" example
makes sense if you think about it as a resource describing a
"contribution event"
publication statement sound like a reasonable resource to me.
placeanddateofcapture is maybe unnecessary, though, unless there are
sometimes multiple of those, so that a date needs to be associated with
the right place.
/Mikael
>
> 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.
> >
>
>
>
--
<[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.
|