Re: Datatypes: the Bermuda Triangle, and how to fly over it.

Pat,

I agree with your conclusion about the rdf:value+rdf:type idiom.

I've been mulling a similar problem with some of my ideas, and I'm not sure 
I'm convinced by the need to introduce anything new (rdf:dtype, or whatever).

Where there are multiple type constraints, why not simply require that they 
*all* be satisfied, per conjunctive type semantics.  If the various applied 
types cannot be simultaneously satisfied in this way then we simply have an 
unsatisfiable graph.  Tough.

So in your example below, just treat the two rdf:type arcs as introducing 
two "doublets" in conjunction with AAA.  (And if there are multiple AAAs, 
introduce a new doublet for each combination of AAA and rdf:type.)

To avoid confusion in type hierarchies (e.g. between ex:decimalInteger and 
ex:octalInteger), I would suggest using a "pure" value type which does not 
have an associated constraint on lexical-to-value mapping:  clearly, such a 
type could not be used to interpret literals, but I don't see a problem there.

<aside>
I have argued elsewhere, on several occasions, that the definition of XML 
schema datatypes with close dependence on lexical representations has 
introduced some weaknesses for their use in a less lexically oriented 
environment like RDF.  My pet peeve is the lack of a datatype for arbitrary 
rational numbers;  one of the arguments I received for not having these was 
that there isn't a trivially-obtained single representation for 
them.  Having RDF allow pure types that can "ride above" representational 
considerations seems to me like a perfectly reasonable thing to do.
</aside>

#g
--

At 06:44 PM 1/31/02 -0600, Pat Hayes wrote:
>eg:thing---eg:prop--->_:1
>_:1---AAA--->UUU
>_:1---rdf:type--->DDD
>_:1---rdf:type--->EEE
>
>and now any condition that we can state on AAA, UUU and DDD in order to 
>restrict I(UUU) to have the relationship to I(_:1) sanctioned by I(DDD) is 
>going to apply just as well to I(EEE).  Even if we state conditions on 
>doublets, there are two doublets in this graph.  But if EEE is a datatype, 
>there is no guarantee that the lexical-to-value mapping associated with 
>EEE is compatible with that associated with DDD.
>
>One reaction is to just stop this happening by some kind of fiat: forbid 
>subClassOf to be applied to datatypes ....
>(objection: in order to make use of RDFS reasoning on datatypes, we 
>presumably want to be able to say that one datatype is a sub-datatype of 
>another, and it seems natural to do that by saying that one of them is an 
>rdfs:subClassOf the other. In fact, its more than natural: its the *only* 
>way we have of doing it, if datatypes are classes. Another objection: it 
>might follow from normal class reasoning that one datatype value space is 
>a subset of another. After all, they are, as a matter of fact.)
>.....or declare that we will only allow the use of rationally constructed 
>datatype schemes....
>(objection: XSD isn't rational enough.)
>But none of these seem satisfactory as a solution.
>
>Now, the key point about this second problem is not the details of the 
>semantic conditions or the use of bnodes or whatever: it is RDFS class 
>inheritance. That is what causes all this trouble.  And that arises from 
>our using rdf:type in the triangle in the first place. Even if we allowed 
>literals as subjects, so that we could put the literal and the datatype 
>name in a single triple (which is about as 'local' as one could get in a 
>triples notation with datatype class names) :
>
>UUU rdf:type DDD .
>
>the problem would still be there.
>
>So here is my proposal to fix this second problem: DON'T use rdf:type to 
>associate datatypes with nodes. Instead use a new property, which I will 
>call rdf:dtype. This can be required to be an rdfs:subPropertyOf rdf:type, 
>so we can do a fair amount of class-membership reasoning using it. But now 
>the bad inferences are blocked, because

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
        __
       /\ \
      /  \ \
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Received on Friday, 1 February 2002 07:34:18 UTC