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

review of Schema (quick)

From: Frank Manola <fmanola@attbi.com>
Date: Sun, 10 Nov 2002 18:16:13 -0500
Message-ID: <3DCEE8BD.8040906@attbi.com>
To: w3c-rdfcore-wg@w3.org

General comments:

There need to be section numbers added to the various titles, in order 
to be consistent with the other specs.

Also, I'll repeat here a comment I make later specifically about the 
statement (reification) vocabulary: These descriptions are very bare, 
and in many cases convey practically nothing about why the terms are in 
the vocabulary.  The descriptions need to at least point to some other 
document that explains what they are in the vocabulary for, if that 
material is not going to appear here. In some cases, this can be the 
concepts doc, in some cases, it might be the model theory (I know 
there's a section there on reification, although I don't know whether it 
explains the specific vocabulary). As things stand, in many cases, it 
might well have to be the Primer. The point is, there needs to be a 
pointer to explanations of things, if those things are not going to be 
explained here.

I'll vote "concur" on publication, if called on to vote.

Introduction

I think it would be helpful to have, in the Introduction, a brief 
paragraph (more or less echoing section 2.3.1 of the concepts document, 
and therefore very short), going over the graph model, and the fact that 
statements have subjects, objects, and predicates (properties), and so 
on.  This would help make the spec more self-contained (and also 
establish better context for the other material).

I question the use of "data model" here.  I like "data model" myself, 
but this isn't exactly the place to explain the relationship.  We'd do 
better to stick with the terminology used in the Concepts spec.

Example

This is a good example, but what is the significance of the box at the 
bottom around some of the resources and properties?  I was kind of 
expecting it to surround the application-specific stuff, leaving the 
generic RDF stuff outside, but it doesn't seem to do that, since eg:Work 
and eg:Agent are outside the box.  Also, this should have a figure number.

RDF Schema - a vocabulary description language

The first sentence here is too complicated, and needs to be broken up. 
For parallelism with how you describe rdf: as a "prefix", why not 
describe rdfs: the same way?

The description of how the RDF Schema type system differs from that of 
an OO programming language isn't very complete.  In particular, it isn't 
clear why the RDFS approach allows subsequent definition of additional 
properties (you might want to look at the Primer for some text you can 
steal, although you probably wouldn't want to steal all of it!).

RDF Schema overview

The tables probably should have names (and links).

RDF Core Classes and Properties

The def of rdf:type, last sentence, says:

"The value of an rdf:type property will always be a resource that is an 
instance of rdfs:Class. The resource known as rdfs:Class is itself a 
resource of rdf:type rdfs:Class."

The use of two successive vocabulary terms doesn't read very well. 
Suggest "is itself a resource whose rdf:type property has a value of 
rdfs:Class"

I'd also suggest trying for more parallelism in the way the definitions 
are expressed.  Many of the defs start "The foo property" (if it's a 
property") or "foo..." (if it's a class).  rdfs:range, however, starts 
"An instance of rdf:Property that....".  This could easily be parallel 
with those, as in "The rdfs:range property....".

Also, the definitions (or at least the first sentences) of both range 
and domain seem a bit convoluted (particularly domain).  It seems to me 
these could both be more clearly expressed by reference to the statement 
model (which, as I've suggested, needs to be introduced earlier 
anyway)), as in something like:

rdfs:range

rdfs:range is used to qualify a property to indicate that the objects of 
statements in which the property appears are members of specified classes.

rdfs:domain

rdfs:domain is used to qualify a property to indicate that the subjects 
of statements in which the property appears are members of specified 
classes.

rdf:List, rdf:first, etc. need to be included in the tables.

The description of rdf:value needs more of a definition (again, there's 
some text in the Primer you might want to steal from).  If nothing else, 
the current definition might be read to suggest that rdf:value would be 
applied to the *property* (to describe its principal value), rather than 
to the resource that serves as the property value.  Thus, it might be 
more accurate to say something like "The rdf:value property is used to 
indicate the principal value of a structured resource that serves as a 
property value".

rdf:Statement, rdf:subject, rdf:predicate, rdf:object:  These 
descriptions are like those for most of the other vocabulary defined in 
this document:  they are bare descriptions, but convey nothing about why 
they are in the vocabulary.  They need to at least point to some other 
document that explains what they are in the vocabulary for, if that 
material is not going to appear here.

The normative references should include all of the RDF normative specs, 
and the informational references should include the Primer.
Received on Sunday, 10 November 2002 18:00:06 EST

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