Re: New public version of RDF Model and Syntax Draft Specification

At 02:43 AM 7/26/98 +0200, Pasqualino \"Titto\" Assini wrote:

>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>

Correct.  Specifically, this says there is a collection whose
members are Amy and Tim and course 6.001 has this collection
as the value of its student property.  The collection is unordered.

>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>

Also correct.  The only difference from (1) is that the collection
is ordered.

>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>

Here is where the prose sentence is easily misleading.  This graph
does not have a collection resource.  So it is a different graph.
In order to change the enrollment of the course it is necessary to
add a property *to the course*.  In (1) and (2) the properties of
course 6.001 do not change; rather, a property is added to the
collection resource (said resource also being the value of a
property of the course).

The distinction may not matter, as you observe:

>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).

(3) is either logically equivalent to (1) or it is "similar to" (1).
The schema designer says what the semantics of collection values
are.  The schema designer can say, as you suggest, that there is
no semantic difference between having a collection as a property
value and having repeated property values.  Other schema designers
will want to be able to recognize the grouping given by collections
as semantically significant.  This was the intent of Section 3.4
to show a motivating example for delaring a difference.

>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).

excellent reasoning for deducing that the order of property statements
is not significant.  You are correct; properties within a Description
are unordered.

>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 ?

You wish me to invent a possible relation to justify putting these
two publications together into a collection?  I can do that -- but
it is not the point of the example.  You are correct to be concerned
about the relation(s) implied by collections.  Indeed, there is no
other relation other than "membership in a specific collection".
Any other semantics of that collection would have to be described
by additional properties on the collection.

>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.

You are apparently concerned that the prose sentence uses the term
"committee" which might bring with it other (procedural) implications
while the graph in Figure 7 just uses the generic 'Bag' as the value of
the instanceOf property.  To represent the full semantics of a 'committee'
it would be necessary to get into details of the RDF Schema design
and that is out of the scope of this document.

Your model would certainly be an improvement for any real case.
In fact, RDF Schema allows the instanceOf property to be repeated.
Figure 7 could be altered by adding an RDF:instanceOf arc from the
anonymous node to a new node labelled s:Committee.  A second alternative
would be to use the class definition facilities of RDF Schema to define
'Committee' as a subtype of Bag, in which case the anonymous node
would need only a single RDF:instanceOf arc to this Committee node.

>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.

I appreciate your feedback.  Yes, the term "committee" invokes other
concepts that are not represented in the graph as shown.  From a
pedagogical point of view I would prefer to find a more semantically
neutral term than "committee" rather than get deep into the details
of how properties of Committees and instances of Committees are
described (or describable, since it is really the schema designer's
prerogative) in RDF.

>In conclusion I don't think that section 3.4 provide any good reason for
>differentiating between (1) and (3).

OK; do you feel that such a distinction is never going to be useful
to any schema designer?  Perhaps we need to work harder to find a
motivating example for this differentiation.  On the other hand,
you might wish to convince us that any such need would be so small
that the additional complication in RDF to give schema designers
this flexibiilty is unjustifiable.  I do welcome your further remarks.

>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"

This is not the intention of the RDF spec.  Thank you for providing
an example of the additional confusion that would result if we
permitted this interpretation.

>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).

Yes, we do see the need for a 'canonical form' for serializing
RDF graphs.  This will become critical when we add facilities
for signing (RDF) metadata.  This is on our work agenda and
we expect to consider it after the first RDF specification has
been adopted.

>It would be better to specify it in the standard, otherwise any
>application will have to define its own normalized form.

If you have a set of requirements that this canonical form would
need to meet, please send it to us (www-rdf-comments@w3.org).  We
have a range of possible requirements that have been presented
in preliminary discussions.  Feedback including real application
scenarios would help us prioritize.

Again, thank you for your well reasoned comments.  It is quite
valuable to the Working Group to have such independent feedback
at this stage in the process.  The group has been working with
these concepts for so long that we run the risk of neglecting
to explicitly make points in the specification that have become
"obvious" to us.  And conversely, features we have come to think
of as mandatory may on further questioning be found to be
unjustifiable complication.

Regards,
Ralph Swick
W3C/MIT

Received on Monday, 27 July 1998 12:22:24 UTC