RE: Answer to the question: What is a "value" to RDF

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