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

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/>
> > Paragraph "Example 7 illustrates"... "For readability"
> > 
> > On entities - in this case only entities defined in the document,
> > i.e. in the "internal DTD subset" are likely to work.
> > 
> > You can use RDF/XML with a DTD and probably could do things
> > like declare entities there (or default attributes on elements etc. -
> > trickier since there is no DTD for RDF/XML) but we really
> > should encourage that.
> > 
> > Anyway, that's just information or advice.  Which might belong here.
> 
> I'm basically following the model of the OWL specs here (DOCTYPE and all).  

The point is that this isn't a DTD - but an internal DTD subset (that's
the term), and the only thing I'd encourage using it for is these
entities.  Presenting full DTD power with RDF/XML is something I'd
discourage.

<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.


> > 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.

<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.

> > 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.

<snip/>

> You might take the blank lines out before and after <!DOCTYPE> - some
> > parsers are sensitive to that.
> 
> Do you think it's equally readable having done that (I'm more worried
> about human readers than XML parsers!)?

My point is that I've seen that white space before the root element
cause some XML programs to crash or behave oddly.

Dave

Received on Thursday, 31 July 2003 06:42:59 UTC