Quick review of RDF primer

RDF Primer
W3C Working Draft 11 November 2002
This version: http://www.w3.org/TR/2002/WD-rdf-primer-20021111/


I think this is looking very good.  I haven't done a detailed read 
through:  I started looking for overlaps with RDF Concepts.  Those overlaps 
that I noticed (e.g. URIs, RDF graph model, structured information) had 
such different forms of presentation that I think they really stand 
separately as extended explanations, with very little real overlap.

[RDF graph model:  cross-ref from concepts?  Likewise simple facts -> 
structured data?]

Buried in section 3.2 (syntax) is an important discussion of anyone being 
able to add RDF assertions about any resource.  Maybe this should be more 
prominent?

Section 4:  built-in *types* should be *classes*??

Section 4.3.1:  maybe needs to split into two sections;  one to deal with 
breaking up n-ary relations, and another to introduce rdf:value?

General comment, not specifically Primer:  the description of rdf:value is 
fine, but how does it relate to a normative specification?  What can we say 
formally about rdf:value?   What formal semantics (interpretation) allows 
us to make inferences like:

    my:cat rdf:type ex:DomesticCat .
    my:cat ex:weight _:x .
    _:x rdf:value "15" .
    _:x ex:unit ex:Kilogram

=>

    my:cat rdf:type ex:Obese .

but NOT:

    my:cat rdf:type ex:DomesticCat .
    my:cat ex:weight _:x .
    _:x rdf:value "15" .
    _:x ex:unit ex:Pound

=>

    my:cat rdf:type ex:Obese .

?

My point here is if we are to encourage such usage of rdf:value, then there 
ought to be some normative description to back up such usage.


Section 4.3.2, given the links to XML schema datatypes we now have, and the 
subtleties (i.e. non-obviousness from a typical programmers' PoV) of the 
alternative approach of using rdf:type for true/false values, and the 
distinction of meanings viewed from an open-world perspective, I wonder if 
this section really belongs here?

Section 5, para 2:  (RDF schema) mechanisms to *describe* rather than 
*specify*?

Section 5.1, para 2, typo: "different kins of moFor"

Is it worth noting, in passing, that it is not necessary to define a schema 
to use new vocab, even if it's recommended practice to do so for the 
purposes of documentation and consistency checking?

5.3:  very good!

5.5: "specifying that two different classes, defined in separate schemas, 
actually represent the same concept."  Or have the same members?  (I think 
this is a subtle difference between the RDF view of a class and the 
DAML/Description Logics view.)


6. Examples.  I've only skimmed these, so I may be missing something.  I 
think it would be useful to have an example that shows some simple 
inference in action.  I have come to the view that it is the ability to 
have standard tools do inference -- even very simple inference, and the 
ease of doing so, that sets RDF apart from other network data formats like 
XML.  I'm thinking of maybe something of DanC's work relating to travel 
schedules might work.  A simple example I like is DanC's tools to create 
graphs from arbitrary RDF:  at heart, a simple cwm inference rule defines 
the nodes to be graphed.


Section 8:  does it make sense for a non-normative document to have 
normative references?

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 28 November 2002 12:03:44 UTC