Strawman: RDF-Model-Summary-1

Dan,

I read through your summary as if it were a model spec, and here are my 
comments.  I'm not trying to compare with the original, just commenting on 
what I see.  Some of the points are probably already raised on the issues list.

For myself, some understanding of RDF came when I started to ignore the XML 
syntax, and focus on the model which you have summarized (together with 
TimBLs DesignIssues series).  As such, I think a document like this could 
be a good introduction to RDF concepts.  How that might be aligned with the 
RDF M&S status as a REC is not clear to me.

--

Section 2, definition of "resources":  allows use of fragment IDs without 
saying anything about MIME type.  Also, doesn't allow relative URIs, which 
I think is a good thing in the abstract model.  I am also unhappy that the 
resources used here are not necessarily the same as web resources -- or are 
thay?  (The reason I think not is that web resources are identified by URI 
without fragment ID.)  If I am right, I think the lack of some clearly 
stated distinction is confusing.


Section 2, definition of "properties":

(a) the test implies that the definition of a property (specific meaning, 
permitted values, etc.) must be defined, even if the means of such 
definition is deferred to [RDF-schema].

(b) how do property names relate to resource names?  This bit doesn't seem 
to say how properties are named.  (Later they are described as a subset of 
resources.)


Section 2, definition of "statements":  does not allow URI+fragment for 
specifying a resource.


Section 3:

(a) Why does RDF need to define container objects?  The only use I am aware 
that it makes of them is to describe lexical statement grouping, and in a 
way that I'm not sure really provides value.  I'l suggest, controversially, 
that the container model could be layered on rather than built into the RDF 
model.

(b) As recent discussions have shown, the definition of 'Alternative' 
collections is particularly confusing.  The best interpretation I have is 
something like 'Anycast' IP addresses.  I suspect that this is a concept 
best left out of the core RDF specification.

(c) The whole issue of 'types' in the RDF model is slipped in here without 
being properly introduced.  I think a section (or subsection or 2) 
introducing the RDF resource type framework would be appropriate.

(d) As noted elsewhere, I think the use of arbitrary property names to 
define order is problematic.

(e) I think the whole approach to treating containers here muddles the 
specification of RDF with a description of an approach to information 
modelling.  I think I can achieve what RDF does with its container types by 
different mechanisms that don't reference them.


Section 4, final paragraph.

I think that statement grouping in <Description> elements, reification and 
Bag containers are a poorly matched set of concepts.  At the abstract model 
level, a bag can contain statements that cannot be contained in a single 
<Description> element.  More harmful:  this form of definition creates a 
spurious linkage between the RDF model and one possible serialization of it.

(I think the desired effect is better achieved using contexts, which are 
not part of the core model.)


Section 5:

(a) The table containing points 1-4 could usefully contain a cross 
reference to the definitions in section 2, or otherwise clarify what is 
meant by "Resources", "Literals", etc.

(b) Point 4 - is 'Statements' *really* a set?  (Just checking ;-)

(c) Points 5, et seq - the XML namespace syntax has been introduced rather 
sloppily in something that is supposed to be a formal definition.  I think 
it would be better if the formal model could get by without reference to 
XML namespace syntax:  I would say that use of this syntax is a property of 
a particular serialization format used.  On a careful re-reading, I not 
that "RDF:type", "RDF:Statement", etc. are not presented as URIs, so the 
previous comments don't apply -- it's not entirely clear.  If these are not 
URIs I think it would be better to label them in a way that doesn't look so 
much as if it might be one (e.g. RDF-type, RDF-Statement, etc., preferably 
using a different font).

(d) Points 10, 11:  (Repeat comments about need for containers in the core 
model.)


--

#g
------------
Graham Klyne
(GK@ACM.ORG)

Received on Monday, 11 September 2000 14:50:42 UTC