- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Mon, 29 Apr 2002 20:53:49 +0100
- 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 UTC