- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Thu, 02 Jan 2003 13:53:34 +0000
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: www-rdf-comments@w3.org
At 12:48 31/12/2002 -0500, Peter F. Patel-Schneider wrote: [...] >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. Thank you for the suggestion. > > >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. Perfection is something we strive for, yet rarely achieve. My current understanding of your objection is: o that the new text does not say anything that is false o the new text does not state something you consider it important to make clear o that which you desire be made clear is a technical issue for semanticians o that which you desire made clear is made clear in the semantics doc If that understanding is correct, I see no problem, so I presume my understanding is incorrect. Please help me understand. > > >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. What discussion? This is what URL's are for. > 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''. I don't see a contradiction there. >[..] > > > >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, ....'' Right, and the term 'property' is correctly used in the technical sense to which you refer. > > >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. I agree it doesn't do any harm to mention it in passing. Fixed. >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. Hmm, I think the intent is that 5.1 lists the names in the rdf namespace but does not define their meaning. I think this is a comment on the concepts doc rather than schema. > > >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! Its all to do with layering. > > > > 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***! OK. [...] > > >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.) The current text says: [[but does not say whether or how an application should use it.]] The applicable concept here is not "use", but "application use". Whilst to you, an applications using a vocabulary for data validation, for inference and for constructing a useful user interface might all be doing the same thing, i.e. "restricting the set of interpretations", I don't agree that language is helpful in making the point we are trying to make. I believe the meaning of the text will be clear to its intended audience, an opinion I am willing to revise in the light of other feedback to the contrary. >[...] > > > > 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. Would marking the section as informative rather than normative help? [...] Brian
Received on Thursday, 2 January 2003 08:52:47 UTC