Re: review of LCC documents as of 26 December 2002

From: Brian McBride <bwm@hplb.hpl.hp.com>
Subject: Re: review of LCC documents as of 26 December 2002
Date: Sat, 28 Dec 2002 12:17:18 +0000

[...]

> >Section 1:
> >
> >Is this a normative document or not?
> 
> Yes.  I've modified the paragraph I think you are commenting on to:
> 
> [[
> This document is intended to provide a clear specification of RDF Schema to 
> those who find the formal semantics specification, RDF Semantics 
> [RDF-SEMANTICS] daunting. Thus, this document duplicates material also 
> specified in the RDF Semantics specification . Where there is disagreement 
> between this document and the RDF Semantics specification, the RDF 
> Semantics specification should be taken to be correct.
> ]]
> 
> >   Saying that the semantics document is
> >more-authoritative is not nearly as helpful as saying that this document is
> >non-normative.  Also, it leaves unspecified which document is
> >more-authoritative when this document conflicts with, for example, the
> >Concepts document.
> 
> True, but there is less danger of that.

I find it very difficult to find normative information in the RDF Core WG
documents.  Normative information is spread out amongst a large number of
documents, even for concepts that I would have thought should have been
completely covered in a single document.  (By the way, the introduction of
the Concepts document has not helped in this regard.)  

I think that the best solution to this problem would be to identify and
move *all* the normative information into either the Syntax document or the
Semantics document and then label the Primer, Concepts, Schema, and Tests
documents as informative.  

> >RDF Schema is not described in terms of RDF.  This error, which has been
> >made in several other places, must be ruthlessly eradicated.  Instead, RDF
> >Schema is a semantic extension to RDF.
> 
> Hmm, I'm not sure that the intended audience for this document will 
> appreciate the difference.  Whilst I don't want to say anything that is 
> technically incorrect,  this document also needs to avoid over reliance on 
> understanding model theory.  I've modified the passage in question to:
> 
> [[
> RDF's vocabulary description language, RDF Schema, is an extension of 
> RDF.  All RDF vocabularies share some basic common structure: they describe 
> classes of resource and types of relationships between resources. RDF 
> Schema uses RDF graphs to describe these classes of resources and 
> relationships.
> ]]

This is still unacceptable to me.  The RDF documents need some way of
distinguishing semantic extensions (like RDFS) from things that fit within
RDF or RDFS (like the formal part of the Dublin Core).  RDF Core needs to
make this distinction perfectly clear to readers.

> >This document again makes the claim that RDF ``allows anyone to extend the
> >description of existing resources, one of the architectural principles of
> >the Web''.  Again, would that this were so.  There are many statements in
> >the RDF documents and being currently made in the RDF Core WG that
> >contradict this claim.
> 
> Just as it takes two to tango, it takes at least two to contradict.  Can 
> you help me out here with a more specific objection.

The discussion concerning allowing ``owners'' of resources to control their
use runs counter to this claim.  Also the Concept document says that
``[c]ertain URIs are reserved for use by RDF, and may not be used for any
purpose not sanctioned by the RDF specifications''.  

[..]

> >Section 2:
> >
> >Property is a technical term in RDF and should not be used for other
> >purposes.
> 
> I'm not sure what text you are objecting to here.

``Only one of these classes has the property that it was defined by the tax
office, ....''

> >What is ``common set theory''?  It would be much better to be more precise
> >here.
> 
> The witless response to that is "how much better, precisely" :)
> 
> Again, I could have said "standard (Zermelo-Fraenkel) set theory", as in 
> the MT.  But I was wary of the word standard and I don't expect 
> "Zermelo-Fraenkel" to mean much to much of the audience of this 
> document.  I'm inclined to stick with things as they are, unless of course 
> I get further comment that there is a real benefit to the audience of this 
> document in being more precise.

Well common set theory is an undefined term.  You are allowing sets that
contain sets so you are going outside of flat sets.  As long as you have
gone that far, why not just say ``Zermelo-Fraenkel set theory''?  Any reader
that understands sets enough to understand the problem should not be
troubled by this reference.

The general problem here is that a little description is a dangerous
thing.  It is better to either ignore the issue or to be reasonably precise
and comprehensive.

[...]

> [[The RDF specifications define the following classes.]]
> 
> >  The Concepts document claims otherwise.
> >What does it mean that the core RDF specifications define a class?  What
> >does it mean for a thing to be described by RDF?
> 
> I really have no idea what you are getting at here.  Is there some more 
> specific way you can make this comment?

Concepts states that 
	Vocabulary terms in the rdf: namespace are defined in section 5.1
	of the RDF syntax specification.
but you include several terms form the rdf: namespace in your list.

> >Section 3:
> >
> >The RDF semantic does not support the inference that properties with no
> >rdfs:range or no rdfs:domain have a range or domain of rdfs:Resource.  In
> >any case, this would be a non-monotonic inference as stated.
> 
> Are you referring to, in 3.1
> 
> [[In this specification, where no rdfs:range is specified for a property, 
> the rdfs:range of that property is rdfs:Resource.]]
> 
> and in 3.2
> 
> [[In this specification, where no rdfs:domain is specified for a property, 
> the rdfs:domain of that property is rdfs:Resource.]]
> 
> This was an editorial judgement.  The intent here is that, in the interests 
> of brevity, the text omitted statements that the domain and range of 
> properties were rdf:Resource.  The summary table however, and the rdf/xml 
> representation of the schema has these in full.
> 
> No inference is stated or implied.

How can you say this?  If no rdfs:domain is specified for a property, then
there is *no* rdfs:domain for that property.  To say otherwise is just
incorrect!
> 
> However, if this is not clear, it would be possible, though tedious, to go 
> back and add in the text.
> Are you sure this is necessary?

Yes, YES ***YES***!

> >It is misleading to impute any semantics to rdfs:label, rdfs:comment, etc.
> >It would be much better to state that these properties have no meaning in
> >RDFS, but are conventionally used for particular purposes.  It is
> >more-than-misleading to state that such properties clarify the meaning of
> >RDF classes and properties.
> 
> I'm not sure what to make of this.  On the one hand I think you are using 
> the term 'meaning' here in a specific technical sense, and within that 
> sense, I have no doubt you are correct.  On the other hand, this document 
> is intended for a more general audience to whom the idea that the 
> rdfs:comment field in a schema might indeed document the intended meaning 
> of say the dc:Creator property.  To that audience the description of 
> rdfs:comment is useful and meaningful.

This is a long-standing problem with RDF and RDFS.  On one hand they are
supposed to be some sort of machine-interpretable formalism.  On the other
hand, ... well I'm not sure what the other hand is supposed to be, but it
has something to do with conventional use of RDF and RDFS, although there
are what appear to me to be misguided attempts to make these conventional
uses somehow have consequences.  The blurring of the line only causes
problems.

[...]

> >It is more than misleading to say that RDF Schema does not specify how
> >domains and ranges are to be used.  The RDF semantic states precisely how
> >domains and ranges are to be used.
> 
> Oh?  Where exactly?  We have tried to be careful to stay away from any sort 
> of processing model.  I grant you that RDF Semantics specifies what 
> entailments are justified, but that is not the same thing as how they might 
> be used.

The RDF semantics states that domains and ranges are used to eliminate
certain interpretations what might otherwise be valid.  (The use of a
notion is not tied to a processing model.)

[...]

> >  and these other things may
> >even be reasonable extensions of RDF, but any allusion to such activities
> >needs to have a very strong disclaimer attached to it.
> 
> This section is present to deal with a common issue raised about RDF.  The 
> term 'schema' tends to be associated with validation and this has led to 
> much confusion. All this section is saying that domain and range may be 
> used in different ways by different applications.  It is important to say that.

It is important *not* to say that in a place or manner that might cause it
to be construed as part of the definition of RDFS.  Because this document
has some sort of normative status, great care should be taken not to put
more into RDFS than is actually there.

[...]

> >RDF reification does not allow one to describe a triple.
> 
> Fixed: it describes the occurrence of a triple.

RDF reification does not allow one to describe the occurrence of a triple
either.

> >   RDF reification
> >is nothing more than an uninterpreted collection of resources that are
> >conventionally used for some weird things that have very little to do with
> >any form of reification.
> 
> We didn't pick the term.
> 
> Its going to be hard to write something coherent about this that does not 
> overstate the semantics, but still provides some useful description of the 
> vocabulary and how it is used.  The WG decided not to remove this - its 
> there to satisfy a need and folks are using it.  I've done the best I can 
> and am open to constructive suggestions to how to improve it.

My suggestion is to remove all discussion of it from the document.

[...]

peter

Received on Tuesday, 31 December 2002 12:49:04 UTC