W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Re: Primer - review: WG please advise/comment!

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Tue, 30 Apr 2002 18:33:46 +0100
Message-Id: <5.1.0.14.2.20020430182404.0325d500@joy.songbird.com>
To: Frank Manola <fmanola@mitre.org>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
BTW, if I wasn't clear, I don't think any of my comments justify any delay 
to publication of the next Primer WD

Some clarifications/responses below...

At 08:40 PM 4/29/02 -0400, Frank Manola wrote:
>>Section 3
>>---------
>>Description of rdf:ID.  I had a vague idea that we'd decided that rdf:ID 
>>wasn't for new resources, but simply a syntactic variation with similar 
>>meaning to rdf:about.
>>In particular, is the following RDF legal?:
>><rdf:RDF xmlns:rdf= ... >
>>    <rdf:Description rdf:ID="foo">
>>       <ex:prop1>value1</ex:prop1>
>>    </rdf:Description>
>>    <rdf:Description rdf:ID="foo">
>>       <ex:prop2>value2</ex:prop2>
>>    </rdf:Description>
>></rdf:RDF>
>>I thought it (now) was, but the current primer text suggests not.
>
>
>The following appears as a constraint in the idAttr production of the 
>Syntax spec:
>
>"The names used as values of rdf:ID and rdf:bagID attributes must be 
>unique in a single RDF/XML document since they come from the same set of 
>names. This applies with respect to the in-scope base-uri property of the 
>current element; so the same value can appear on different elements in the 
>same document but only if the in-scope base-uri values were 
>different".  Also, the idAttr and aboutAttr productions are sufficiently 
>different so I thought they weren't simply variants of each other 
>(although I could be misreading this).
>***Anyone know what the right interpretation here is?***

I overlooked that -- I now agree with your reading and retract my comment.

>>Section 4 seems to be missing any discussion of the other abbeviated 
>>syntax forms allowed by RDF.  I think the primer should cover at least 
>>some of these, especially:
>
>
>I assume you mean Section 3 (on the RDF/XML syntax;  Section 4 is on the 
>Schema).

Yes, I did.

>***This is something I'd like WG input on***.  I'm quite willing to 
>include this discussion, but I'm getting other vibes that suggest the 
>Primer is getting too long as it is.
>
>
>>(a) use of a type name in place of <rdf:Description>
>
>
>I discuss an example of this abbreviation in Section 4.2.  The problem 
>here is that I didn't want to discuss this until after I'd introduced the 
>"type" property (and the whole notion of things having types), which 
>doesn't come until the Schema section.

Yes, I wrestled with that a bit.  Maybe the whole bit about "abbreviated" 
syntax could come later.  The point I was particularly keen to get over is 
that RDF/XML doesn't *have* to look about as friendly as a cornered rat.

>>Section 4
>>---------
>>I think the introduction to the type system weighs too heavily on schemas 
>>as constraints (which IMO is one of the problems of likening RDF types to 
>>OO types):
>>[[
>>The RDF Schema specification does not specify a specific vocabulary of 
>>classes like Tent or Book, and properties like weightInKg or author. 
>>Instead, it specifies the mechanisms needed to define such classes and 
>>properties, and to control which classes and properties are used together 
>>(for example, you probably wouldn't want the property jobTitle to be used 
>>in the description of a Tent). In other words, the RDF Schema mechanism 
>>provides a basic type system for use in RDF models.
>>The RDF Schema type system is somewhat similar to the type systems of 
>>object-oriented programming languages such as Java. For example, the RDF 
>>Schema type system allows resources to be defined as instances of one or 
>>more classes. In addition, it allows classes to be organized in a 
>>hierarchical fashion; for example a class Dog might be defined as a 
>>subclass of Mammal which is a subclass of Animal, meaning that any 
>>resource which is in class Dog is also considered to be in class Animal.
>>]]
>>I'd suggest rewording this as:
>>[[
>>The RDF Schema specification does not specify a specific vocabulary of 
>>classes like Tent or Book, and properties like weightInKg or author. 
>>Instead, it specifies the mechanisms needed to define such classes and 
>>properties, and to indicate how classes and properties are expected to be 
>>used together (for example, the property jobTitle is typically used in 
>>the description of a person).  In other words, the RDF Schema mechanism 
>>provides a basic type system for use in RDF models.
>>The RDF Schema type system shares some characteristics with the type 
>>systems of object-oriented programming languages such as Java.  For 
>>example, it allows resources to be described as instances of one or more 
>>classes, and for classes to be organized in a hierarchical fashion.  A 
>>class 'Dog' might be defined as a subclass of 'Mammal' which is a 
>>subclass of 'Animal', meaning that any resource which is in class Dog is 
>>also considered to be in class Animal.
>>However, RDF classes are in some respects very different from programming 
>>language classes.  An RDF class is not a straitjacket into which 
>>information must be forced, but is rather an annotation that provides 
>>additional information about its instances.
>>]]
>
>
>The current text generally follows the way these concepts were described 
>in earlier versions of the Schema document (yet another consistency 
>problem), but you raise an important point.  As your suggested text reads, 
>though, it seems to me it goes too far in the other direction: making 
>these definitions seem mostly advisory.

I have noted some similar thoughts about the current schema draft.  I'd say 
the properties add information to the graph rather than are merely 
advisory, but I do find the characterization as restrictions on use goes 
against all my understanding.   Maybe we should get the schema draft 
settled before wrestling too much with the primer text?


>>I'd also suggest getting the idea of using the RDF language for writing 
>>RDF schema stated up-front;  e.g. rewording:
>>[[
>>The RDF Schema specification uses the RDF data model itself to define the 
>>RDF type system, by providing a set of pre-defined RDF resources and 
>>properties that can be used to define user-specific classes and 
>>properties. These pre-defined RDF Schema resources effectively define the 
>>RDF Schema vocabulary, and become part of the RDF model of any 
>>description that uses them. We will illustrate these basic resources and 
>>properties in the following sections.
>>]]
>>as:
>>[[
>>The RDF Schema specification maps the RDF type system into the RDF data 
>>model, and thus uses the RDF language itself to describe new types and 
>>properties.
>>It introduces pre-defined RDF classes and properties for describing 
>>relationships with user-specific classes and properties.  These 
>>pre-defined RDF Schema resources underpin the RDF Schema vocabulary, and 
>>become part of the RDF model of any description that uses them.
>>]]
>
>
>I'm not sure I see a major difference between these wordings (?)

Not a lot!  Mainly, getting the use of RDF language (as well as RDF data 
model) for schema stated up front.

>I understand your point, but (a) I do think they are constraints, they're 
>just not as "constraining" as might appear on the surface, and (b) 
>"attributes" might get confused with either XML attributes, or 
>"properties".  We could just call them domain and range "specifications" (?)

I think "specifications" works.

But I'm also thinking we need to get some WG discussion on this area.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Tuesday, 30 April 2002 15:01:38 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:47:40 EDT