- From: Pasqualino \ <assini@kamus.it>
- Date: Sun, 26 Jul 1998 02:43:24 +0200
- To: www-rdf-comments@w3.org, swick@w3.org
.. message starts after citation .. > "Ralph R. Swick" <swick@w3.org> on 07/24/98 10:18:28 AM > To: Bob Schloss/Watson/IBM > cc: w3c-rdf-syntax-wg@w3.org > Subject: Re: New public version of RDF Model and Syntax Draft Specifi > > At 08:16 PM 7/23/98 -0400, Bob Schloss wrote: > >"Pasqualino \"Titto\" Assini" <assini@kamus.it> on 07/23/98 03:45:57 AM > >To: meta <meta2@mrrl.lboro.ac.uk> > >I also have a question. By reading the standard I couldn't understand if > >the following description: > > > > <rdf:Description about="http://mycollege.edu/courses/6.001"> > > <s:students resource="http://mycollege.edu/students/Amy"/> > > <s:students resource="http://mycollege.edu/students/Tim"/> > > </rdf:Description> > > > >is equivalent to: > > > > <rdf:Description about="http://mycollege.edu/courses/6.001"> > > <s:students> > > <rdf:Bag> > > <rdf:li resource="http://mycollege.edu/students/Amy"/> > > <rdf:li resource="http://mycollege.edu/students/Tim"/> > > </rdf:Bag> > > </s:students> > > </rdf:Description> > > > >or to: > > > > <rdf:Description about="http://mycollege.edu/courses/6.001"> > > <s:students> > > <rdf:Seq> > > <rdf:li resource="http://mycollege.edu/students/Amy"/> > > <rdf:li resource="http://mycollege.edu/students/Tim"/> > > </rdf:Bag> > > </s:students> > > </rdf:Description> > > > > > >or if its meaning is application dependent and not specified by the > >standard. > > I guess we need a forward reference to 3.4. in 3.2.1. Of course, > "meaning" is schema-dependent not application dependent. But > the three RDF graphs above are quite distinct. > -Ralph Why are they distinct ? According to section 3.1 the meaning of (1) is "The students in course 6.001 are Amy, Tim and their order isn't significant" (1) <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:students> <rdf:Bag> <rdf:li resource="http://mycollege.edu/students/Amy"/> <rdf:li resource="http://mycollege.edu/students/Tim"/> </rdf:Bag> </s:students> </rdf:Description> while the meaning of (2) is "The students in course 6.001 are Amy, Tim and their order is significant" (2) <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:students> <rdf:Seq> <rdf:li resource="http://mycollege.edu/students/Amy"/> <rdf:li resource="http://mycollege.edu/students/Tim"/> </rdf:Seq> </s:students> </rdf:Description> Now consider the meaning of (3): it's clearly that "The students in course 6.001 are Amy, Tim". (3) <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:students resource="http://mycollege.edu/students/Amy"/> <s:students resource="http://mycollege.edu/students/Tim"/> </rdf:Description> There are now only two possibilities, either the order of the students is significant and then (3) is logically equivalent to (2) or their order isn't significant and then (3) is equivalent to (1). As the reification of a Description is a Bag this implies that the order of properties is not significant so I would say that (3) should be considered equivalent to (1). Section 3.4 states that these 3 RDF graphs are distinct but I think that the adduced reasons are wrong. The assertion: "In this example there is no stated relationship between the publications other than that they were written by the same person." is right but it's wrong to imply that, had we used a Bag instead of a the simple repetion of the property, this would have implied the existence of some additional relation between the Bag elements. What would such relation be ? Also the assertion that: "It would be incorrect to model this sentence as three separate approvedBy properties, one for each committee member, as this would state the vote of each individual member." is right but it's wrong to add that: " Rather, it is better to model this as a single approvedBy property whose value is a Bag containing the committee members' identities: " The proper modelling in this case would be to define a Description instanceOf Committee and refer to is as the value of the property approvedBy. A committee is not a Bag, it's a logical entity that will likely have a name, some powers and that probably will be composed by different people at different times. In conclusion I don't think that section 3.4 provide any good reason for differentiating between (1) and (3). Naturally it would be possible to argue that the real meaning of (3) is that "The students in course 6.001 are Amy, Tim and it's not specified if their order is significant or not" But choosing such an alternative might lead to undesiderable logical consequences. Consider the description: (4) <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:students resource="http://mycollege.edu/students/Tim"/> <s:students resource="http://mycollege.edu/students/Amy"/> </rdf:Description> that's to say (3) but with the order of students inverted. Is (3) equivalent to (4) ? The question can not be answered as we are unaware if order is significant. This means that the relation of equality between two RDF graphs can assume 3 values: true, false and unknown. Do we really want to get in such a mess ? If for some reason it's deemed inappropriate to state in the RDF standard if the order of the repetition of a particular property is significant or not it should be made mandatory to specify it in the RDF schema. But this would also mean making mandatory the presence of an explicit schema, at least if equivalence between RDF descriptions needs to be calculable. I have another question. Would you consider defining a normal form for RDF, that's to say a form such that if two RDF graphs have the same normal form they are equivalent ? (a nice consequence of that would be that equivalence might be determined by a simple string comparison between the XML serializations of the normalized graphs). It would be better to specify it in the standard, otherwise any application will have to define its own normalized form. -- Pasqualino "Titto" Assini --- assini@kamus.it Kamus Internet Consulting --- http://www.kamus.it/
Received on Sunday, 26 July 1998 18:10:02 UTC