- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Tue, 20 Nov 2001 14:12:20 -0600
- To: Patrick.Stickler@nokia.com
- Cc: w3c-rdfcore-wg@w3.org
> > >Are you saying that given >> > >> > xxx --foo:date--> "2001-11-29" >> > >> >that foo:date is not a data type? >> >> No, but the S idiom would say that its being a datatype does not >> entail that that literal "2001-11-29" *denotes* a date in the RDF >> semantics; rather, this RDF triple should be understood as saying >> that xxx is a date, and that '2001-11-29' is a lexical form of that >> date in the datatype in question. So the literal label in this triple >> denotes a string, not a date. > >I don't find this treatement intuitive. It is essentially >saying that any form > > x --some:type--> > >might be a contraction for > > x --rdf:type--> some:type ?? No, I don't see it in those terms at all. In the S proposal, as I understand it, datatype names would NEVER be used as class names, so this expansion would never be appropriate. But in any case, that expansion has nothing to do with the literals-are-strings idea. The DC proposal (and the ones in your recent message) also make the literals-are-strings assumption; all the 'bNode' style proposals do so, in fact. >yet how do we know *which* properties correspond to that contraction? >Do we all make them subPropertyOf rdf:type? It's just making things >messier and less well defined that at present. > >I think that we have a case of the tail (MT) wagging the dog (graph) Please, don't keep saying things like this. The MT can handle any of the proposals that have been suggested (so far); it isn't wagging any dogs at all. What the S and DC (and URV) proposals do keep simple is the idea that RDF graphs can be tidy on literal nodes as well as on uriref nodes, which would indeed allow the RDF graph syntax to be stated more concisely since there would be (as Dan C. has noted) no need to bother with the distinction between nodes and labels. >such that the S treatment is preferred because it is (supposedly) >easier to define in the MT but it does not reflect common usage >or present definition of the RDF graph model or intuitions about >the purpose and semantics of terms such as rdfs:range, rdfs:subClassOf, > or rdfs:subPropertyOf. I think it respects all of this except maybe current usage. The S proposal doesn't require us to revise anything in the graph model or the meanings of any of the rdfs vocabulary. > >And the present idiom based on anonymous nodes is IMO much >clearer and accomplishes the same purpose but does so per >the present RDF "tradition" without mucking up type and >property distinctions: > > xxx --rdf:type---> foo:date . > xxx --rdf:value--> "2001-11-29" . > >Thus, the anonymous node (bNode) denotes the value, and it >has properties for type and lexical form, and thus acts >as the identity in the graph for that pairing. That is the DC idiom. But that has some severe problems of its own, as we have already noted in earlier discussions, and I was under the impression that the S proposal was generally considered superior. The chief problem with the use of rdf:value to link values to lexical forms is that the link between type and form is too weak, and if the same value is specified in two ways, then the link can be completely lost, eg if xxx --rdf:type --> xsd:binary xxx --rdf:value --> "111" and xxx --rdf:type --> xsd:integer xxx --rdf:value --> "7" Notice BTW that if we use rdfs:subClassOf on datatypes then xxx rdf:type xsd:integer . will be entailed by xxx rdf:type xsd:binary . and the upward-incompatibility problems that you raised concerning the P proposals would apply here in just the same way. That objection applies to *any* datatyping proposal that uses class reasoning on the value spaces of datatypes; the S proposal escapes it precisely by treating datatypes as properties rather than as classes. I can't see any simple way around this problem, by the way. If datatypes are classes and if we expect to be able to use normal class reasoning on them - which includes the use of rdf:type - then normal, valid, RDFS class reasoning is liable to produce wrong datatype answers, in general. This is a very general and robust problem, and there is no simple way to wriggle past it. The only ways I can see to get past all involve somehow isolating datatype reasoning from class reasoning, either by removing it completely (the URV and S proposals); or maybe by providing a special subproperty of rdfs:subClassOf to be used on datatypes , something like rdfs:subDatatypeOf, with its own special semantic conditions; or maybe by declaring that RDF is only guaranteed to give correct answers when used on 'upward compatible' datatyping schemes (ie those for which aaa rdf:type rdfs:datatypeClass . bbb rdf:type rdfs:datatypeClass . aaa rdfs:subClassOf bbb . together entail aaa rdfs:subDatatypeOf bbb . ) Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Tuesday, 20 November 2001 15:11:46 UTC