- From: pat hayes <phayes@ai.uwf.edu>
- Date: Tue, 10 Dec 2002 12:33:23 -0600
- To: Dan Connolly <connolly@w3.org>
- Cc: w3c-rdfcore-wg@w3.org
>On Tue, 2002-12-10 at 09:10, pat hayes wrote: >> >On Mon, 2002-12-09 at 18:35, pat hayes wrote: >> >> >> >> >I'm not comfortable with the SHOULD in >> >> > >> >> >"A 'datatype-aware' RDF engine SHOULD be competent to recognize at >> >> >least the rdfs:XMLLiteral datatype and the set of all the XML >> >> >Schema primitive datatypes." >> >> > >> >> >insofar as XML Schema datatypes are concerned. >> >> > >> >> >I think the SHOULD should only be limited to rdfs:XMLLiteral. >> >> > >> >> >I don't believe this is an editorial issue. I don't believe that the >> >> >WG has agreed that this expectation should be placed on datatype >> >> >savvy applications. >> >> > >> >> >I propose the following rewording: >> >> > >> >> >"A 'datatype-aware' RDF engine SHOULD be competent to recognize at >> >> >least the rdfs:XMLLiteral datatype. It MAY, and typically will, >> >> >recognize other datatypes, >> >> >such as the XML Schema built-in simple datatypes." >> >> >> >> On reflection, I don't think we should shilly-shally with 'typically' >> >> when using this strict language, so Ive simplified this to: >> >> >> >> A 'datatype-aware' RDF engine SHOULD be competent to recognize at >> >> least the built-in rdf:XMLLiteral datatype. It MAY also recognize the >> >> set of all the XML Schema built-in datatypes. >> >> >> >> >> >> OK?? >> > > > >no; 'RDF engine' seems completely out of place. Well, OK, let me respond more to the point. I don't see why it is out of place, and I would prefer to keep it in. I don't understand the basis for your objection to it. > > >Please strike all mentions of it. >> >> I don't see how that is possible. > >[Sigh... again, no pointer to the relevant document... >I'll go hunting... in your message of >09 Dec 2002 10:59:22 -0600 you referred us to >http://www.coginst.uwf.edu/~phayes/RDF_Semantics_finalCall.html#ReifAndCont >but I can't reach that.... hmm... lemme try from another >machine... ok... I have something last >modified Tue, 10 Dec 2002 00:38:22 GMT] > >It seems straightforward to me... > >change > > make it easier to implement RDF reasoning engines which can check > formal RDF entailment. > >to > make it easier to implement RDF entailment checking in software. I don't mind making that change, but it seems purely stylistic to me. It says the same thing. > > >Strike the para that begins... > > In operational terms, in order to make use of datatyping information, > a reasoning engine would require that the uriref of a datatype > provides access to a process which at least can determine, for any > character string, whether or not it is a valid lexical form for that > datatype. ... I can't just strike it, since it says something important that needs to be said. How about rephrasing along the lines you suggest, as follows: ..in order to make use of datatyping information, any software which is checking RDF entailment would require .... What I dont like about this is that it presupposes that software is going to be 'checking' entailment. Some engines might do other things, though, based on entailment, like generate consequences or do abduction or whatever, I don't know. I'd rather not pre-guess what it is going to be doing. >Strike... > > A 'datatype-aware' RDF engine > SHOULD be competent to recognize at least the built-in rdf:XMLLiteral > datatype. It MAY also recognize the set of all the XML Schema >built-in > datatypes. Im happy to strike that. >I'm not sure what to do with the occurence in the glossary; >if it's informative, (a) it seems harmless, but (b) the >glossary should say so, right under the heading. Yes, I will label the glossary as informative. >If it contributes some novel technical information to >the spec, I'd much prefer that the glossary entries >had pointers to the sections where the terms >are introduced (bonus points for usage pointers too). Yes, I will do that. I would like to put invisible pointers from the text back to the glossary, like the XML schema doc does, but my HTML expertise does not yet run that far. > >Hm... I see 'engine' isn't the only term that needs scrubbing... > >reasoner... > >Strike this: > >[[[ >Thus, the inclusion of a triple of the form > ><ex:somedatatype> rdf:type rdfs:Datatype . > >in an RDF graph can be understood by a datatype-aware RDF reasoner as a >claim that ex:somedatatype identifies a recognized datatype. Such >reasoners MAY post a warning or an error condition when they are unable >to access the minimal relevant datatype information. >]]] > >'regognized' is defined as a relationship between interpretations >and datatypes; there's no need to bring reasoners into >the picture. But that relationship only makes sense in this context. > >I don't understand this bit: > >[[[ >While normal RDFS reasoning is valid when applied to the datatype >vocabulary, other implications which depend on the properties of the >datatype spaces may be missed, and datatype clashes or other error >conditions may be undetectable. >]]] > >if it contributes some novel information to the spec, please >supplement it with an example (and let's get that example >in the test suite). Otherwise, please strike it. OK, I can strike it. > >Strike this: > >[[[ >Although RDFS entailment rules apply robustly to such graphs, >datatype-aware RDF reasoners MAY treat a datatype violation as an error >condition. >]]] > > >strike this: > >[[[ >Although the definition of entailment means that a D-inconsistent graph >D-entails any RDF graph, datatype-aware RDF reasoners SHOULD NOT publish >'trivial' conclusions derived from a recognized datatype-clash >contradiction. >]]] > I think we need to say something about this, as otherwise we have a normative semantics which justifies inferring anything at all from a datatype clash. I know this is logically correct, but I bet it will confuse a hell of a lot of people. I also think that we should tell people that it is OK for a reasoning engine to stop drawing conclusions when it finds a datatype violation. There are valid entailments from badly-formed datatypes, so a reasoner which purports to be complete might well be understood to be required to generate them all. The point of this is to day that is OK to post an error and refuse to generate the valid RDFS conclusions in this case, and still count yourself as a complete reasoner. > >> When talking about datatypes we are >> forced into talking about information 'inside' RDF and information >> coming from 'outside'. The 'side' that these words are referring to >> is the boundary of a hypothetical RDF reasoning engine. >> >> I note that the XML spec makes a similar reference to a hypothetical >> XML parser, and it does not seem inappropriate there. > >(a) I think it is very inappropriate there; I fought >tooth-and-nail to keep it out, but lost. I think >the cost has been much higher than the benefit. When reading the XML spec, that is the least of the problems I find. I honestly do not know what it is that is bothering you so much here. All of these languages are intended for use by software, so why the prohibition against referring to what software is supposed to do or not do? Pat >(b) the XML WG did not introduce that term lightly. >There were endless discussions of what constraints >to put on XML processors. Endless in the sense >that they continue to this day... > > >> >> Pat >> >> >> -- >> --------------------------------------------------------------------- >> IHMC (850)434 8903 home >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32501 (850)291 0667 cell >> phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes >> s.pam@ai.uwf.edu for spam >-- >Dan Connolly, W3C http://www.w3.org/People/Connolly/ -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
Received on Tuesday, 10 December 2002 13:33:31 UTC