Re: "Datatyping for Dummies" (or Occam's Razor Slash Fest)

>On 2002-02-22 1:53, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>
>
>>>  What the rdfs:drange is really saying is that the property
>>>  value can be *either* a value bNode or a literal
>>
>>  No, its saying that the property value is in the value space of the
>>  datatype (just as if it were rdfs:range) but *in addition* it is
>>  imposing some interpretation conditions on literals that occur at or
>>  'near' the object nodes of triples using the property.
>
>This makes no sense to me.
>
>If xsd:integer is the value space alone and
>
>    ppp rdfs:range xsd:integer .
>
>restricts values of ppp to values of xsd:integer, then
>
>    xxx ppp "15" .
>
>is an error.

Well, we can take it either way. If we say that literals denote 
rigidly (ie always strings) then it is an error, yes. If we let them 
denote flexibly then its not an error. That is precisely the 
difference between the two proposals I just put up.

>
>>>  -- i.e the
>>>  datatype class contains the members of both spaces, i.e the
>>>  datatype class is the union of the value space and lexical
>>>  space of the datatype.
>>
>>  No, its definitely not saying that.
>
>Then I don't see how the above range constraint can be valid.
>
>
>>>  Why not then, for the sake of the users (and us too ;-) toss
>>>  out all the extra d* vocabulary, and both the value triple
>>>  and doublet idioms (which were desparate measures before
>>>  considering datatype classes as unions) and say exactly the
>>>  same thing using the present RDF/S vocabulary using a treatment
>>>  of datatype classes as unions of lexical and value spaces?
>>
>>  Because not everyone might want to invoke datatyping by using
>>  rdfs:range, so I thought it should be an option.
>
>They don't have to. An rdfs:Datatype is an RDFS class just like
>any other. It has members. And rdfs:range constrains the values
>of a property to the members of that RDFS class.
>
>If an rdfs:Datatype is treated as a union of the value space
>and lexical space of some extra-RDF datatype, then rdfs:range
>works as it always has, and should work.
>
>Folks who use rdfs:range on non-datatype classes do not
>invoke datatyping. Only folks who use rdfs:range on
>rdfs:Datatype's invoke datatyping.

That is what I thought should be an option. BUt lets agree that this 
isnt an issue.

>  > If people are willing to make this non-optional then we could attach
>>  the condition to rdfs:range, it is true. I guess this would be OK,
>>  since then one could assert range information about a sub/super class
>>  of the datatype class, and that would not invoke the datyping
>>  conditions on literals. OK, yes, that would be an option. Good point,
>>  I hadnt thought of that.
>
>Thanks. Sorry for taking so many words to make it clear. I guess
>I need to go take a remedial writing class (or a math class ;-)
>
>>  We should still have something like rdfs:dlex around, though, in
>>  order to record value-lexical links when datatype information isn't
>>  available for some reason.
>
>Seems that the good old meaningless rdf:value would work.

Yes, it would. But I thought that we had agreed to not put any extra 
meaning onto rdf:value.

>The
>datatype interpretation is provided by the fact that the range
>is an rdfs:Datatype.
>
>Thus, given
>
>    ddd rdf:type rdfs:Datatype .
>    ppp rdfs:range ddd .
>
>all the following are "equivalent" insofar as datatyping
>interpretation (extra-RDF ;-) is concerned:
>
>    xxx ppp "zzz" .
>
>    yyy ppp _:1 .
>    _:1 rdf:value "zzz" .
>
>    zzz ppp _:2 .
>    _:2 ddd "zzz" .
>
>(ooooh... deja vu ;-)

Right.

>
>>>  And that the statement
>>>
>>>     xxx ppp "34" .
>>>
>>>  in isolation of any datatyping knowledge has no datatyping
>>>  interpretation.
>>
>>  Well, it has to have SOME interpretation, since it is legal RDF. So
>>  we should have it be satisfied by any interpretation, ie an
>>  undatatyped literal can mean anything at all, like a bnode.
>
>The RDF MT interpretation is that it is a literal. It has no
>datatyping-specific interpretation either in the MT or based
>on the set rules for application (extra-RDF) interpretation
>of datatyping based on the datatyping idioms and the
>rdfs:Datatype class.
>
>>>  It might get some later, but that's the risk
>  >> of the inline, implicit idiom.
>>>
>>>  But, insofar as the graph syntax and MT is concerned:
>>>
>>>     The literal "34" in all cases above, in the graph itself,
>>>     denotes the literal "34". It *never* denotes 34, ever.
>>
>>  NO no no. You just contradicted yourself. Stop while you were ahead.
>
>No no no, I didn't ;-)  I'm not talking about it denoting 34
>in the MT.
>
>To an extra-RDF application that *knows* what xsd:integer is,
>the pairing ("34",xsd:integer) *means* 34, but that meaning
>can *not* be captured in the RDF graph or MT, not until all
>and every bit of relevant knowledge about xsd:integer is
>expressed in RDF, which it likely never will be.
>
>>>
>>>     The URI xsd:integer denotes the RDF datatype class,
>>
>>  Yes
>>
>>>   which
>>>     contains both values and lexical forms of the xsd:integer
>>>     datatype (is the union of the value and lexical spaces).
>>
>>  No
>
>I'm saying it does. That's a premise of the solution. That we
>treat rdfs:Datatypes as representing some extra-RDF datatype
>DDD and having as its members the members of both the value
>and lexical spaces of DDD.
>
>>>
>>>     The bNode _:1 denotes the value but *NOT* 34
>>
>>  ??? What is the value, if not 34?? It has to denote SOMETHING.
>
>See above. It can never be made explicit in the MT that the
>value actually *is* 34. Only that the bNode denotes a single,
>specific value, whatever the datatype mapping says it is.

So what does it denote if there is no datatyping information? A 
single, specific value that could be any value? Thats incoherent. If 
you say things like "single, specific", then you are locking the 
value down, and then it cannot be delimited or altered by other 
information. If it can be so altered, then its NOT a single, specific 
value. So what is it?

>
>>  Better to say: In a simple RDF interpretation, it can denote
>>  anything;
>
>It can't denote anything. It denotes a single value, we just
>can't know which value exactly since RDF doesn't grok the
>datatype.

Again, that is incoherent. Are there any constraints on what it 
denotes in an interpretation?

>
>>  in a datatyped RDF interpretation, it denotes 34.
>
>No. It doesn't.  Only with special extra-RDF knowledge about the
>datatype can we determine that 34 is the actual value it denotes.

Thats what I mean by talking about a *datatyped* interpretation.

>
>This is really, really important, and really, definitely true, so
>*please* try to work through my non-mathematical mumblings to
>understand it.
>
>Based on RDF knowledge,

By which you mean, knowledge included explicitly in the RDF graph 
syntax? If so, I agree. BUt Im not talking about that: Im talking 
about how to represent that other, extra-RDF datatype knowledge as 
a(n extra) semantic restriction on  RDF interpretations., so that we 
can say precisely (which is what the MT is for) what its import is 
for RDF processing when done in the context of such information: what 
new entailments it supports, what interpretations it now rules out, 
and so on.

>  and any MT you might be able to craft,
>one can never, ever know what the actual value is

Well, you can impose restrictions which ensure that the denotation of 
some part of the RDF graph is that actual value in all satisfying 
interpretations that conform to the datatype conditions.

>  -- only that
>there is a single, consistently determinable value, based on
>the N:1 mapping from lexical to value space defined for all
>extra-RDF datatypes represented by instances of rdfs:Datatype.
>
>>  Adding
>>  the datatyping restricts the set of satisfying interpretations.
>
>Yes. It does. But the nature of that restriction cannot be
>expressed or captured in the MT

Nonsense. Of course it can, that's what we are trying to do here. ANY 
semantic constraint ever devised by human thought can be expressed in 
an MT, with enough work.  There are MTs for a pretty large fraction 
of most human natural languages, and Ive developed at least one MT 
for diagrammatic reasoning and map interpretation. If we can't do it 
for RDF plus XSD then we are being pretty pathetic.

>  (at least not without being
>able to actually *define* datatypes a'la XML Schema in
>RDF).
>
>>>  (you need
>>>     an application that knows about xsd:integer to *know*
>>>     that the value is 34! Apart from the actual extra-RDF
>>>     interpretation you can *never* know what value the bNode
>>>     actually denotes! only that it denotes a single determinable
>>>     value obtainable from the datatyping interpretation)
>>
>>  There are two different notions of satisfiability and hence two
>>  notions of entailment. The one with datatyping added is 'stricter'
>>  than the other.
>
>But the strictness is opaque to the MT.

No, its not. The MT *expresses* the stricter conditions.

>
>
>>>  And with the additional assertions that:
>>>
>>>     Everything denoted by a literal node has an rdf:type of
>>>     rdfs:Literal.
>>>
>>>     Everything denoted by a URIref node or bNode has an rdf:type
>>>     of rdfs:Resource.
>>>
>>>     rdfs:Literal is not a subclass of rdfs:Resource
>>
>>  I don't see why not.
>
>We can leave this extra bit for now. It's not central to
>the "Dummies" solution. And it may not be absolutely needed
>(we may not care to restrict idioms, only achieve consistent
>constraints on lexical forms, which is already provided).
>
>
>>>  Surely if you can make the MT work for your latest treatment of
>>>  the inline idiom, which really does assume a union treatment of
>>>  datatype classes, it can be made to work for the above minimalist
>>>  solution and we can achieve a solution that users will *enjoy*
>>>  using and not flail about over with moaning and gnashing of teeth.
>>
>>  Well, let us hope so.
>
>I certainly do. I hope my ramblings above have helped to clarify
>how we might realize that hope.

Not really, I'm afraid.

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 Friday, 22 February 2002 12:39:32 UTC