Re: Review of RDF primer Revised Editor's Draft 21 July 2003

Again replying to just the problematic bits:

Dave Beckett wrote:

> On Wed, 30 Jul 2003 15:42:50 -0400
> Frank Manola <fmanola@mitre.org> wrote:
> 
> 
>>Just replying to the problematic bits (and asking for comments from the
>>WG, not just replying to Dave):
>>
> 
> I'm not replying to all of these either.  You decide.
> 
> 
>>Dave Beckett wrote:
>>
> 
> <snip/>

> 
>>>5.1 Describing Classes
>>>
>>>Paragraph "The meaning of this rdfs:subClassOf ..."
>>>
>>>I see the use of an "RDF processor" and "RDF schema software"
>>>The latter you define, but not the former.  If you could avoid
>>>both that would be good.
>>>
>>If you could suggest some alternatives, that would be even better.  DanC
>>wants to talk only about "languages", which is fine in principle, and I
>>appreciate that we are not "defining a processing model" (as this is
>>generally put).  The problem is that we don't really have distinct
>>languages in the sense lots of people think of languages being
>>distinct.  Given an RDF schema, this is *both* RDF and RDFS.  The
>>difference between the "languages" is whether particular conclusions can
>>be drawn from particular pieces of reserved vocabulary or not.  Pat
>>describes this in terms of different kinds of entailments, but that
>>doesn't seem appropriate in the Primer, and saying "conclusions can be
>>drawn", being passive voice, elides the issue of who or what does the
>>conclusion-drawing.  I think characterizing this difference in the
>>Primer as one between different kinds of software (or software written
>>to understand different stuff) is reasonably clear, and it's not clear
>>to me what the problem is in saying that way in a non-normative document
>>(e.g., what inappropriate entailments are introduced?).  But I'll be
>>happy to entertain alternative ways of saying the same thing.
>>
> 
> I said you only defined one.  If you want to introduce an RDF processor term,
> you'll need to say what such a thing does (taking RDF/XML and making
> graphs, manipulating them, storing them, doing RDF-entailment on the graphs, ...)
> 
> I've no real better suggestions.
> 


Well, I can certainly say generally what we expect of an RDF processor 
here.  It's true that we might define "RDF processor" in terms of all 
the things you mention (and a complete definition would certainly need 
to cover things like those).  However, it seems like overkill for making 
the distinction between the vocabularies the software understands that 
is the core of all this.  BTW, this issue initially comes up in Section 
2.4 on typed literals, where we have to point out that RDF doesn't 
define specific datatypes (except, for my sins, XMLLiteral!), and hence 
software has to be written to "understand" specific datatypes, i.e., a 
vocabulary that extends RDF with additional terms, and which does 
additional things based on knowledge of the "meaning" of those terms. 
Software not written to understand those datatypes may correctly process 
the RDF, but not be able to do datatype-specific processing.  The same 
situation exists here, but now it's the RDFS vocabulary that is the 
extension in question.  If the phraseology used in Section 2.4 is OK, 
perhaps we could use something similar here.


> 
> 
>>>Example 22 should have an xml:base, since it has rdf:IDs
>>>[example 23 does].  Later after example23 you mention use
>>>of xml:base so I expect you should change the rdf:IDs in
>>>example 22 to be full URIs.
>>>
>>Why?  rdf:IDs work relative to the document don't they?  
>>
> 
> Yes but that document in example 22 has no URI given. Hence no base URI,
> so you cannot know the URIrefs that the rdf:IDs make.  Either change
> them to rdf:about="absolute-URI" or make the document URI known - it's
> unlikely you really want the document URI of the example 22 to be the
> namespace URI less the '#': http://example.org/schemas/vehicles
> 
> I found another example with rdf:ID in examples with no
> URIs - example 9 (not so important, you don' t give the triples).
> 
> My advice is that using rdf:ID without xml:base (prefered) or stating
> the document URI is problematic.
> 
> 
>>>Example 24 - !
>>>
>>>Yes, it's correct but I'm sure people will get burnt with this kind
>>>of thing.
>>>
>>What kind of thing?  If you mean not using an xml:base, the text says
>>they ought to use one.
>>
>>
>>>Maybe you could explain the benefit (is there only one? :) of rdf:ID
>>>- checking for duplicates in 1 document so that people can see when
>>>it makes sense to use it.
>>>
>>How important is this;  like, how many sentences is it worth?  :-)
>>
> 
> How about:
> rdf:ID is useful to abbreviate URIrefs but also provides an additional
> useful check that the value of the rdf:ID attribute is unique against the
> current base URI (usually document URI).  This helps pick up repeating
> rdf:ID values such as when defining properties and classes in RDF schemas.


This is good (but we might want to say this in Section 3, where rdf:ID 
is first introduced, rather than here (?).  In addition, this raises an 
additional question:  it's fairly clear how this works if the id values 
are being checked within the scope of a particular document, but if you 
use rdf:ID in combination with a base URI defined with xml:base, how do 
you really do a uniqueness check, since there's no guarantee that all 
the rdf:ID values in question are in the same document?


> 
> <snip/>
> 
>>>Appendix A: More on Uniform Resource Identifiers (URIs)
>>>
>>>Please label the state of this and other appendices in or near the
>>>titld - this one is informative, but for the definitive use of URIs,
>>>see RFC2396.
>>>
>>I'm not sure I understand.  The whole Primer is informative, so
>>obviously the Appendices are.  I can emphasize that the defining spec is
>>RFC2396 in the text.
>>
> 
> Yes, the point is that it's clear you aren't defining URIs but giving
> an overview of some parts.  Yes, you don't need to worry about
> informative in the section titles.


Got it.


> 
> 
>>>Appendix B: More on the Extensible Markup Language (XML)
>>>
>>>Ditto, "see XML 1.0 (Second edition)" for definitive info.
>>>
>>If this is also what you meant for URIs, that's fine.
>>
> 
> Yes.
> 
> 
>>>Paragraph "Finally, XML provides ...
>>>
>>>Well, it is finally here, but XML provides lots of stuff and if you
>>>include all the XML things that we do (XML, Namespaces, Infoset,
>>>Base, Canonicalization, [schema]) then it's just a small intro, which
>>>is the case.
>>>
>>Could you translate this? :-)
>>
> 
> The sentence implies that's all of XML, but it's not.  It's probably
> enough that people care about for the RDF primer.   I'm just
> pointing out there is more to say if people are interested.


OK.


--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Thursday, 31 July 2003 09:51:52 UTC