Comments on the new RDF Concepts and ADM Draft

First, thanks much for setting this draft out, I think it clears the way to a 
finally unambiguous definition of the data model, and solves my previous rants
on the data model part in the MT
(cf. from
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0107.html :
+ issue of literal information in the semantics
+ "no free meal" for blank nodes (and related instances problem))
provided of course the MT is updated accordingly. 

Ideally, the MT might just refer to this draft for any ADM definition :)

Even, it touches the other big issue regarding the Test case drafts, namely 
the previosuly erroneous/fuzzy notion of graph isomorphism, cf.
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0081.html
and
http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0083.html
(incidentally, I think we didn't get a final resolution about the conformance issue
there yet; oh well ;).

Back to the doc, some comments, plus a couple of discussion points (XML literals, fragid's).


*** Sections 1 and 2:

> [[[NOTE: it is anticipated that some of the material in this document may be 
> moved to other documents as part of the document review process.]]]
Yes, this is definitely an option: I found the doc very well written, but,  
so to say, like it's putting together things of a very different nature: ADM 
formal definition, general principles about the semantics, etc.
Mostly, 2.1, 2.2 and 2.3 don't seem to belong to the next part, the ADM 
definition. I'll let you figure out how to deal with this. An option might be 
to move 2.1, 2.2 and 2.3 to the Primer, for example. Anyway, just a matter 
of personal reading tastes.


*** Section 3.2

> Two RDF literals are equal if and only if they are either both XML 
> literals and equal or both string literals and equal.
This def is superfluous, and can be cleared out.

*** Sections 3.2.1 and 3.2.2

These defs don't work, because they give in the ADM that XML literals 
overlap with RDF literals. This ambiguity was a problem already implicitly
present in the old RDF spec, and never really clarified so far. You need to 
make the ADM more fine-grained, and extend their ADM representations 
with a flag or so, to make these two sets disjoint (but see also the 
next issue).


*** Section 3.2.2
This is a more higher-level issue on XML literals: do we really need to 
have them at the ADM data model level? With the ongoing work on data
types, wouldn't it be better to just have string literals as the only 
basic datatype here? 
I see this is already somehow mentioned in 2.2.5:
> [[[Review this on resolution of datatypes issues]]]
and I would favor to drop them if possible, and just use a generic datatyping 
mechanism (otherwhise, the basic ADM gets more complex (as seen above), and risks 
to unnecessarily complicate the datatyping mechanism. Anyway, yes, this is 
dependant on the final resolution on datatyping.


*** Sections 3.3, 3.4 and 3.5

> A tidy set of nodes is one in which no two nodes have equal labels. A tidy 
> set of nodes may have any number of distinct blank nodes
Mmm, do we need to introduce the "tidy" concept (as a name)? It's not 
really needed (there are not "untidy" sets used in RDF), and it gives a 
longer and more complex def.

So, suggestion: just define the RDF graph in its shortest and simplest way: 

: B is an infinite set disjoint from (RDF-Lits U URI-refs)
: An RDF-triple belongs to ((URI-refs U B),URI-refs,(URI-refs U B U RDF-Lits))
: An RDF Graph is a set of RDF-triples.

(note: I'd even say a *finite* set of RDF-triples, but if nobody else cares, 
I'm fine with the more general, "non-always-computable" def).


*** Section 3.6

> Two RDF graphs are equal if and only if they are isomorphic
We just need the notion of "isomorphism", so this should be deleted, and 
the section renamed accordingly with "3.6 Graph Isomorphism"
(there's no real use to have two names for the same thing).


*** Section 4.2

Do we really need this? This whole part is made out of linguistic statements
(because, admittedly, the issue is hairy), but so it should be either formalized
(and then, likely put in the MT), or taken out.
Restated: suppose the whole section is striken out: what would change?
I'd suggest RDF stays out of the very hairy fragid's issue for the time being.


Thanks!
-M

Received on Wednesday, 4 September 2002 21:46:45 UTC