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

>On 2002-02-21 11:13, "ext Patrick Stickler" <patrick.stickler@nokia.com>
>wrote:
>
>>  On 2002-02-21 0:29, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>
>>>  Ok, guys. Another version now at
>>>  http://www.coginst.uwf.edu/users/phayes/simpledatatype1.html
>>>  This changes the previous one as follows.
>
>Pat,
>
>Your latest treatment of inline literals seems to embrace
>the outside-the-graph interpretation view that I've been
>suggesting for the union-based minimal proposal (and
>which in fact I've been suggesting for several months now).

Well, I don't quite see how, but then I don't understand that 
proposal in any case.

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

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

>
>And the interpretation is that, if the property value is a
>literal, it is treated as a lexical form (how else can you
>equate it to the value triple idiom?) and if its a bNode it
>is a value. This is my union-based proposal exactly.
>
>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.

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.

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.

>I.e. That both of the following have the same datatyping
>above-the-graph

I really do not know what that phrase means, BTW.

>interpretation
>
>    ppp rdfs:range xsd:integer .
>    xxx ppp "34" .
>
>    xxx ppp _:1 .
>    _:1 xsd:integer "34" .
>
>and in both cases, we're talking about the integer 34.

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.

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

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

>
>    The bNode _:1 denotes the value but *NOT* 34

??? What is the value, if not 34?? It has to denote SOMETHING.

Better to say: In a simple RDF interpretation, it can denote 
anything; in a datatyped RDF interpretation, it denotes 34. Adding 
the datatyping restricts the set of satisfying interpretations.

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

>
>Simple. Clear. Unambiguous. Easy.
>
>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.

>
>Then using range intersection, folks can constrain property
>values to either the inline idiom (lexical forms only) or
>the datatype triple idiom (values only) using one of
>
>    ppp rdfs:range ddd .
>    ppp rdfs:range rdfs:Literal . (lexical forms only)
>
>or
>
>    ppp rdfs:range ddd .
>    ppp rdfs:range rdfs:Resource . (values only)
>
>Again, simple, clear, explicit, intuitive, easy.

But unfortunately, totally wrong. HOwever, I don't see why we need 
this stuff, since we don't need to make the dataype classes into 
unions in the first place. The value and lexical domains are the 
domain and range of the datatype property, and if we make the 'exact 
fit' assumption then we can talk about them with confidence.

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

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 Thursday, 21 February 2002 18:54:00 UTC