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

Primer - review

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Mon, 29 Apr 2002 20:53:49 +0100
Message-Id: <5.1.0.14.2.20020429173128.00abda90@joy.songbird.com>
To: Frank Manola <fmanola@mitre.org>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
Frank,

I think it would be great to see this formally published ASAP.  I 
particularly liked the consistent and well-reinforced alternation of 
RDF/XML and graph diagrams.  More than the text, I think they'll go a long 
way to showing people how RDF is put together.

I do have some comments about this material, some of which I feel are quite 
important to consider before we go to a final recommendation status.  I've 
tried to offer text that I hope you can use (if we all agree, of course).

At 08:25 PM 4/25/02 -0400, Frank Manola wrote:

>There is a new version of the Primer at 
>http://www.w3.org/2001/09/rdfprimer/rdf-primer-20020424.html

My 1st comment is a real nit:  the "latest version" link actually points to 
an older document !


Section 1
---------
In the list of documents, delete "(and datatypes)" from the RDF schema listing.

Section 2.1
-----------
The string distinction between URLs and URIs seems to against some other 
W3C work:
   http://www.ietf.org/internet-drafts/draft-mealling-uri-ig-02.txt
[[
    Further according to the contemporary view, the term "URL" does not
    refer to a formal partition of URI space; rather, URL is a useful but
    informal concept: a URL is a type of URI that identifies a resource
    via a representation of its primary access mechanism (e.g., its
    network "location"), rather than by some other attributes it may
    have.
]]

I think this text goes against that viewpoint:
[[
The Web provides its own form of identifier for these purposes, called the 
Uniform Resource Identifier (URI). URIs are similar to URLs, in that 
different persons or organizations can independently create them, and use 
them to identify things. However, unlike URLs, URIs are not limited to 
identifying things that have network locations, or use other computer 
access mechanisms. In fact, we can create a URI to refer to anything we 
want to talk about, including
]]

I'd suggest something more like this:
[[
URLs, whose use in RDF is noted above, are a particular use of the general 
Uniform Resource Identifier (URI) form of Web identifier.  URLs share a 
number of general URI properties, in that different persons or 
organizations can independently create them, and use them to identify 
things.  URIs are not limited to identifying things that have network 
locations, or use other computer access mechanisms. In fact, we can create 
a URI to refer to anything we want to talk about, including
]]

Section 2.3
-----------
Your N-triples examples are split over several lines, which isn't allowed 
for "real" N-triples (personally, I think line breaks should be allowed, 
but tat's water under the bridge.)  Clearly, you need line breaks to fit 
the examples on a page, so I think the introduction to N-triples should 
make this point.

[[
As defined, each statement expressed in N-triples must occupy a single line 
of a file.  But if long URIs are used, such lines can get very long, so for 
the purpose of presentation in this document, the three parts of an 
N-triple are placed on separate lines, as shown below.
]]
(insert somewhere soon after figure 2.)

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.

...

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:

(a) use of a type name in place of <rdf:Description>

(b) use of attributes rather than elements to encode properties.

In particular, I think it would be useful to show, early on, how RDF/XML 
syntax can look very much like "ordinary" XML.  Here's an example of the 
sort of thing that might be added at the end of section 3 (with apologies 
for the immodest choice of topic -- I just happened to have some RDF data 
for that lying around):

[[
The basic structure for encoding an RDF graph in XML has been described 
above.  This is completely sufficient for describing any graph that can be 
described using the RDF/XML syntax, but can sometimes seem unwieldy and 
difficult to understand.  The RDF/XML syntax also provides some alternative 
forms that allow some graphs to be expressed more compactly, or in a 
fashion that is more familiar to many XML users.

1. The name of an <rdf:Description> element can be replaced by an RDF class 
name (RDF classes are described more fully in section 4.1).  This is 
equivalent to writing an <rdf:Description> element containing a 
corresponding <rdf:type> property in addition to all the other contained 
properties.

2. Non-repeating properties with literal values can be written as 
attributes of the containing description.

3. When describing a property value that is itself a resource, properties 
of the target resource's attributes can be added as attributes of the 
property element referencing that resource.

Using the abbreviated form (1), the following is legitimate RDF:

<rdf:RDF
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:foaf="http://xmlns.com/foaf/0.1/"
     xmlns:wn="http://xmlns.com/wordnet/1.6/">

     <wn:Document rdf:about="http://www.w3.org/TR/CCPP-struct-vocab">
         <dc:title>Composite Capability/Preference Profiles (CC/PP):
                   Structure and Vocabularies</dc:title>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Graham Klyne</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Franklin Reynolds</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Chris Woodrow</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Hidetaka Ohto</foaf:name>
         </dc:creator>
         <dc:date>2001-03-15</dc:date>
         <dc:language>en</dc:language>
         <dc:identifier 
rdf:resource="http://www.w3.org/TR/CCPP-struct-vocab/"/>
     </wn:Document>
</rdf:RDF>

Using the abbreviation form (2), this can be written as:

<rdf:RDF
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:foaf="http://xmlns.com/foaf/0.1/"
     xmlns:wn="http://xmlns.com/wordnet/1.6/">

     <wn:Document rdf:about="http://www.w3.org/TR/CCPP-struct-vocab"
                  dc:title="Composite Capability/Preference Profiles (CC/PP):
                            Structure and Vocabularies"
                  dc:date="2001-03-15"
                  dc:language="en">
         <dc:creator rdf:parseType="resource">
             <foaf:name>Graham Klyne</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Franklin Reynolds</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Chris Woodrow</foaf:name>
         </dc:creator>
         <dc:creator rdf:parseType="resource">
             <foaf:name>Hidetaka Ohto</foaf:name>
         </dc:creator>
         <dc:identifier 
rdf:resource="http://www.w3.org/TR/CCPP-struct-vocab/"/>
     </wn:Document>
</rdf:RDF>

And combining this with abbreviation form (3), we can write:

<rdf:RDF
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:foaf="http://xmlns.com/foaf/0.1/"
     xmlns:wn="http://xmlns.com/wordnet/1.6/">

     <wn:Document rdf:about="http://www.w3.org/TR/CCPP-struct-vocab"
                  dc:title="Composite Capability/Preference Profiles (CC/PP):
                            Structure and Vocabularies"
                  dc:date="2001-03-15"
                  dc:language="en">
         <dc:creator foaf:name="Graham Klyne" />
         <dc:creator foaf:name="Franklin Reynolds" />
         <dc:creator foaf:name="Chris Woodrow" />
         <dc:creator foaf:name="Hidetaka Ohto" />
         <dc:identifier 
rdf:resource="http://www.w3.org/TR/CCPP-struct-vocab/"/>
     </wn:Document>
</rdf:RDF>

These three examples all describe exactly the same RDF graph, viz:
   <<<graph diagram>>>

Using these abbreviation forms, it is possible to write RDF data that is 
also quite recognizable as XML data.
]]


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

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


Section 4.2
-----------

Again, there's very great emphasis on "constraints":
[[
RDF Schema also provides a mechanism for specifying simple constraints on 
the use of properties and classes in RDF data. The basic constraints are 
those that describe limitations on the types of values that are valid for 
some property, or on the classes to which it makes sense to assign such 
properties. Specifically:

A range constraint specifies that the value of a property should be a 
resource of a designated class. For example, a range constraint applied to 
the author property might specify that the value of an author property must 
be a resource of class  Person.

A domain constraint specifies that a property may be used on resources of a 
certain class. For example, a domain constraint applied to the author 
property might specify that the author property could only originate from a 
resource that was an instance of class Book.
]]
I'd suggest trying to put more emphasis on "information":
[[
RDF Schema also provides a mechanism for specifying information about the 
use of properties and classes in RDF data.  The basic information indicates 
the classes of resources that are indicated by a property, or on the 
classes to which properties are assigned. Specifically:

A range constraint specifies that the value of a property is an instance of 
a designated class.  For example, a range annotation applied to the author 
property might specify that the value of an author property is an instance 
of class Person.

A domain constraint specifies the class of resource to which a properry is 
applied. For example, a domain constraint applied to the author property 
might specify that the resource to which the author property is applied was 
an instance of class Book.
]]

Generally, I'd look to replace "constraints" with a more neutral term like 
"attributes".

Section 4.4
-----------

Where you say "@@The above could clearly be developed a great deal 
further!@@" I think you have said just about the right amount for a 
document that is about RDF(s), and suggest you resist any temptation to 
elaborate this section!


Section 5
---------

The RDF model theory does not currently mention rdf:Alt.  I think this is a 
point of
coordination to be resolved ... somewhere.

--

That's all, folks!

#g



-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Monday, 29 April 2002 15:45:11 EDT

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