Re: a few issues with daml+oil+concrete (XMLSchema Datatypes)

Peter wrote:
> A few comments on Sandro's message.
> 
> From: Sandro Hawke <sandro@w3.org>
> Subject: a few issues with daml+oil+concrete (XMLSchema Datatypes)
> Date: Thu, 15 Feb 2001 23:11:02 -0500
> 
> > 
> > 2.  The proposal treats datatypes as if they were the classes which
> >     conventionally have the same name (eg "integer"), but according to
> >     the XMLSchema spec, they are not.  For example, [2] contains:
> [...]
> >     which both seem to be treating these XMLSchema datatypes (integer
> >     and decimal, respectively) as if they were the classes of numbers.
> > 
> >     But the XML Schema Datatypes spec [4] says that "a datatype is a
> >     3-tuple, consisting of a) a set of distinct values, called its
> >     value space, b) a set of lexical representations, called its
> >     lexical space, ..."  
> [...]
> 
> I don't see this as a problem.  An XMLSchema datatype may be a three-tuple,
> not a set, but classes are not sets.  Just as we have an type relationship
> between an abstract object and an abstract class, which is modelled in the
> model-theoretic semantics as set membership, we can have a similar
> relationship between the integer 10 and the XML schema datatype 
> http://www.w3c.org/xml/xmlschema#integer, which is also modelled in the
> model-theoretic semantics as set membership.

I have to confess that I don't really understand the model-theoretic
semantics document. 

I think my problem is really with the definition of "datatype" in
XMLSchema.  If xsd:integer is "a tuple", then (using programmer's
terminology) it should have methods like "getFirstElement()" or
"getValueSpace()" returning the set of all integers.  That's quite
different than the definition you seem to be using where
you would have methods like "getSuccessor()" returning an integer.
That later definition is clearly the conventional one, and may be what
XMLSchema really meant.

I wonder if we can rephrase the definition of datatype in XMLSchema to
talk about relationships instead of tuples.  Something like:

    A datatype is a class with the following characteristics:

      - The set of possible instances of a datatype are sometimes
        called its value space.   

      - A datatype has a relation to a set of strings called its
        lexical space.

      - Each instance of the datatype has a one-to-many relation to an
        element in the class's lexical space called its lexical
        representation.    (Alternatively: something about the
        datatype having a relation to the above set of relations.)

      - Each instance of the datatype also has a one-to-one relation
        to an element in the lexical space called its canonical
        representation.
    
      - (plus some stuff about Facets)


> > 3.  Using the property rdf:value to link from a point in the value
> >     space (eg 10) to a point in the lexical space (eg "10") seems
> >     completely backwards.   That's saying:
> > 
> >           the number 10 has a value which is the string "10"
> > 
> >     when the correct form (IMHO) is
> > 
> >           the number 10 has a lexical representation which is the 
> >           string "10"
> > 
> >     I know rdf:value is given in RDF M&S, but that doesn't make it
> >     right.  We need a property lexicalRepresentation (and probably
> >     canonicalLexicalRepresentation) to be clear here.  [...]
> 
> Agreed.  I also think that this is the wrong way around.  However rdf:value
> is used for precisely this relationship in RDF M&S.  One other reason for
> using rdf:value is that it is shorter than rdf:lexicalRepresentation.

If space is more important than clarity, let's use xxx:lexRep.  It's
about the same size and more accurate.

I guess using rdf:value in this weird manner is okay; we can assume
some day the software will know rdf:value = xxx:lexRep != rdf2:value.
But I'd prefer to just stay away from broken peices of vocabularies.

   -- sandro

Received on Friday, 16 February 2001 11:21:22 UTC