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.