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.

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

> 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. 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 ;-)


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

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

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

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, and any MT you might be able to craft,
one can never, ever know what the actual value is -- 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 (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.


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

Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 22 February 2002 03:59:20 UTC