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
>



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