W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2002

Re: Datatype question

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 24 Jun 2002 16:03:45 +0300
To: ext Geoff Chappell <geoff@sover.net>, RDF Interest <www-rdf-interest@w3.org>
Message-ID: <B93CF361.1741A%patrick.stickler@nokia.com>

On 2002-06-24 15:46, "ext Geoff Chappell" <geoff@sover.net> wrote:

> Patrick,
> Thanks for your response - a few comments inline below.
> --geoff
> ----- Original Message -----
> From: "Patrick Stickler" <patrick.stickler@nokia.com>
> To: "ext Geoff Chappell" <geoff@sover.net>; "RDF Interest"
> <www-rdf-interest@w3.org>
> Sent: Monday, June 24, 2002 2:45 AM
> Subject: Re: Datatype question
>> On 2002-06-23 19:05, "ext Geoff Chappell" <geoff@sover.net> wrote:
>>> I'm sure this has come up in rdf core datatype discussions but I can't
> find
>>> in the archives why it was rejected. Can someone familiar with those
>>> discussions clear this up for me?
>>> Why can't a datatype class be interpreted as a union of the datatype
> values
>>> and their string representations? and as a mapping from value to
>>> representation when used as a property? for example:
>>> abbrev_integer the datatype contains the sets {10, 3} and {"10", "3"}
> and
>>> the mapping ("10"->10, "3"->3)
>>> abbrev_integer the class contains the members {10, "10", 3, "3"}
>>> abbrev_integer the property has extension (10, "10"), (3, "3")
>>> {range age abbrev_integer}
>>> {age x "10"}
>>> is consistent with (and implies)
>>> {age x ?y}
>>> {abbrev_integer ?y "10"}
>>> and is enough to indicate that ?y=10
>>> If a datatype is understood to contain a set of values, a set of
>>> representations, and a mapping between the two sets, what is wrong with
> just
>>> defining that when viewed as a class, it looks like the union of the two
>>> sets, when viewed as a property, it looks like the mapping (i.e.
> different
>>> aspects of the datatype are seen depending upon how it is used)?
>>> It seems so simple and fully captures the common usage of specifying a
> value
>>> by either it's string representation or in a more qualified form (using
> the
>>> same property).
>>> Thanks for any responses.
>>> Geoff Chappell
>> Taking the class extension of a datatype to be the union of the lexical
>> and value spaces was discussed back in February/March. C.f.
>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0469.html
>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0124.html
>> Many members of the WG felt that this approach was "ugly" and
>> it was ultimately rejected due to problems pointed out by
>> Jos De Roo in
>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0151.html
> I see. I guess the effective disjunctive range (i.e. either a string or a
> datatype value) makes this approach incompatible with owl:UniqueProperty. Of
> course, you might be able to just say that it is just not correct to use
> owl:UniqueProperty in the context of a datatyped property and define a
> owl:UniqueDataTypeProperty, or... but I imagine that could be a slippery
> slope that results in something truly ugly (like some of the solutions
> proposed with six different variations and spelling of range :-)

Yup. Ugly.

>> A functionally similar approach which also uses rdfs:range for
>> expressing global datatyping constraints, which is one of two
>> final proposals presently under consideration by the WG, is to
>> have the literal node of the inline idiom simply denote
>> the datatype value, where the literal node is similar to a blank node,
>> but with the lexical form included as a contextually interpreted label.
> I can see the value of the untidy literal approach to datatyping. I do think
> though, there is a practical impementation advantage to tidy literals (which
> admittedly may not outweight the cost of keeping them).

There is no such practical implementation advantage to tidy literals. You
can, in your implementation, employ tidy literal nodes in the triples
store, so long as you preserve the semantic untidyness. There are numerous
ways to optimize storage of untidy literals. So no worries there.

Having the literals as untidy in the conceptual model (which need not
correspond exactly to any underlying implementation) helps to reinforce
the fact that the interpretation of literals would be context sensitive.

But, to say again, this is only one proposal. The other proposal
has literals both syntactically and semantically tidy, but with other

> It also seems that
> the prohibition on literals as subjects pretty clearly indicates that the
> current RDF design intends literals to be tidy.

I don't think it's possible to say for sure one way or the other. I suspect
that the limitations of the RDF/XML serialization had alot to do with it,
along with literals simply not being considered interesting enough to say
anything about (at least then ;-)



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Monday, 24 June 2002 08:59:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:37 UTC