Re: RDF containers vs. multiple properties of same predicate

* Jan Algermissen <jalgermissen@topicmapping.com> [2005-04-04 09:56+0200]
> 
> Hi,
> 
> does anyone know of a definition (or discussion) of the semantic 
> difference between the RDF graphs resulting from for example:
> 
> <rdf:Description rdf:about="http://example.org/books/some_book">
>    <dc:creator rdf:resource="http://foo.org/persons/joe_smith"/>
>    <dc:creator rdf:resource="http://foo.org/persons/mary_meyer"/>
> </rdf:Description>
> 
> and
> 
> <rdf:Description rdf:about="http://example.org/books/some_book">
>  <dc:creator>
>         <rdf:Bag>
>            <rdf:li rdf:resource="http://foo.org/persons/joe_smith"/>
>            <rdf:li rdf:resource="http://foo.org/persons/mary_meyer"/>
>         </rdf:Bag>
>   </dc:creator>
> </rdf:Description>
> 
> IOW, what is the difference of having several authors vs. having an rdf:bag 
> of authors?
> 
> 
> Thanks for any clarification.

The meaning is dependent on the meaning of the property. You can't
generally just drop in a bag instead of an individual thing and 
expect there to be automatically an appropriate meaning. So in this case
we'd need to see what Dublin Core says. Generally, one should use
special and distinct properties when you want something to point to a
Bag/Seq/Alt (or rdf:List). But I think the original 1999 RDF spec gave
readers the contrary impression. In the DC example above, the idea 
(which was for a while reflected in DC's own RDF spec, though I think
the idiom is falling from favour now) the idea was that in the first 
case, we're saying that these two things are each creators, in the
latter case that there was just one creator, modelled as a collective
entity. But imho using rdf:Bag detracts rather than adds to things here;
if we want to model collective agency, lets do so explicitly with
notions like 'Committee', 'Company', etc. 
rdf:Bags (alongside the somewhat more useful rdf:Seq and the horribly 
confused rdf:Alt) are not great. Sometimes using a Seq is OK since
ordering is necessary. Bags have the ugly combination of features 
that (a) they're supposed to represent unordered groupings (b) they 
are represented using structures like _1 _2 _3 which are both ordered
and pretty annoying to deal with. So my advice is to just ignore bags
and model things with normal classes and properties that describe the
domain you're interested in...

Dan

Received on Monday, 4 April 2005 10:40:03 UTC