RE: Enumeration in RDF?

> -----Original Message-----
> From: ext Garret Wilson [mailto:garret@globalmentor.com]
> Sent: 17 September, 2003 00:54
> To: Dan Brickley
> Cc: Barstow Art (NMP-MSW/Boston); www-rdf-interest@w3.org
> Subject: Re: Enumeration in RDF?
> 
> 
> 
> 
> Dan Brickley wrote:
> > * Art.Barstow@nokia.com <Art.Barstow@nokia.com> [2003-09-15 
> 11:49-0400]
> > 
> >>Do the latest RDF specs define a way to do enumeration
> >>(e.g. a Bag may contain only 4 strings)?  If so, please
> >>send me the pointer.
> > 
> > 
> > http://www.w3.org/TR/rdf-schema/#ch_collectionvocab
> > The rdf:List collections mechanism allows the members of a 
> list to be 
> > enumeated in a way that makes it clear the whole list has been
> > represented.
> 
> But as one can always add an infinite number of rdf:first 
> properties to 
> any rdf:List resource (see your citation about), does this 
> really help 
> ensure that nothing more is added to a list---or even, as you put it, 
> "makes it clear the whole list has been represented?"
> 
> Saying we ignore the new rdf:first properties doesn't help, 
> because that 
> would make rdf:List unstable---once someone adds another 
> rdf:first to an 
> rdf:List, which rdf:first is part of the "whole list" and 
> which one isn't?
> 
> Garret

[Disclaimer: This is my personal opinion, and is probably 
 contrary to the more prevalent opinions of the RDF Core WG]


The problem identified about, that of conflicting definitions
of collections, is why, IMO, collections in RDF are essentially 
out of place in RDF.

One of the most fundamental characteristics of RDF is the
ability to freely syndicate knowledge from disparate sources.

If one schema defines the members of a collection, and another
schema defines additional members, the total set of members
should merge seamlessly. 

Collections, being structures, go contrary to that, as there
is no formally defined way to merge collections.

The chief motivation (apparently) for collections, especially
the new list structure, is to somehow have control over the
defined members of a collection. But in fact, the design fails
to do that, since RDF has no official means of keeping track
of source and/or authority (though one *can* use reification,
but being able to do something does not make it "the" way to
do it).

The argument goes like this: since rdf:first and rdf:rest
can be given a cardinality of 1, we can detect contradictions
if someone else tries to modify a previously defined list.
Fair enough. That's true. BUT...

Since source/authority is not, by the standard, tracked for
assertions, an application is left with no means to determine
*who* modified the list or which possible variant was the
original. And if a given application employs additional 
machinery, such as reification or some other proprietary
extension, to track source/authority for each statement, so
that one *could* determine which statements correspond to the
original, the very *need* for the collection structure evaporates,
since one could simply just ask for all membership assertions
asserted by that particular source/authority, which would simply
disregard any asserted modifications.

BUT, if the same authority makes membership assertions in different
sources, the total membership is seamlessly merged in the graph
when viewing those membership assertions through the particular
"filter" of that authority.

This approach also allows one to assert cardinality of membership
on collections, which can be considered specific to the context
of that authority, avoiding conflicting cardinality assertions
by other sources/authorities.

Collections in RDF seem overly influenced by its XML associations
and ill suited to the dynamic nature of arbitrary knowledge 
syndication, and these problems relating to preserving the integrity
of originally expressed collections and constraining the membership
of collections reflects, IMO, the ill suited nature of these
constructs.

That said...  and getting back to the topic of the thread...  ;-)

One can achieve cardinality (and other) constraints for collections 
effectively by defining a custom container class and a subproperty
of rdfs:member, e.g. to define a collection that takes 4 and only 4
xsd:integer values:

   ex:myCollection rdfs:subClassOf rdfs:Container .
   ex:myMember rdfs:subPropertyOf rdfs:member ;
               rdfs:domain ex:myCollection ;
               rdfs:range xsd:integer ;
               owl:cardinality "4"^^xsd:nonNegativeInteger .

and thus

   ex:foo a ex:myCollection ;
          ex:myMember "1"^^xsd:integer ;
          ex:myMember "-18"^^xsd:integer ;
          ex:myMember "128891"^^xsd:integer ;
          ex:myMember "0"^^xsd:integer .

would be valid, but

   ex:bar a ex:myCollection ;
          ex:myMember "1"^^xsd:integer ;
          ex:myMember "blargh"^^xsd:string ;
          ex:myMember "128891"^^xsd:integer .

would not be valid, due to (a) too few members and incompatible
value types (datatypes).

Reifying the statements according to source (and thus, implicitly
according to authority per the owner of that source) allows one
to be clear about the membership of a given collection insofar as
a given source and/or authority is concerned.

If ex:myMember assertions are made from some other source/authority,
one can choose to ignore them, or choose between the conflicting
sources/authorities, without having to muck about with explicit
*structures*, but rather simply consuming knowledge within a particularly
defined context of trust.

Regards,

Patrick

--
Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Wednesday, 17 September 2003 05:29:14 UTC