W3C home > Mailing lists > Public > www-archive@w3.org > February 2002

(offlist) Re: simplified datatyping proposal

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 20 Feb 2002 13:49:21 +0200
To: Pat Hayes <phayes@ai.uwf.edu>
CC: Brian McBride <brian_mcbride@hp.com>
Message-ID: <B89959E1.F0F8%patrick.stickler@nokia.com>


(offlist)


On 2002-02-20 13:22, "Patrick Stickler" <patrick.stickler@nokia.com> wrote:

> If one wishes to also exclude value bNodes for a given
> property, then in addition to the rdfs:drange constraint
> one can add
> 
>  ex:age rdfs:range rdfs:Literal .
> 
> and if one wishes to exclude inline idioms, then add
> 
>  ex:age rdfs:range rdfs:Resource .
> 
> and that is that.
> 
> Since multiple ranges are treated as an intersection, the
> intersection of ddd.(val U lex) and rdfs:Literal is ddd.lex
> and the intersection of ddd.(val U lex) and rdfs:Resource
> is ddd.val.

Pat,

Your efforts in distilling, clarifying, and defining
the recent convergence of datatyping ideas have been
fundamental to moving us to a point of near closure,
and we all owe you unbounded appreciation and applause
for your seemingly untiring contributions. Trully and
sincerely.

I hate to seem to be the continual sand in the gears,
and am as eager as everyone else to see us reach closure
on this, but I have this awful nagging feeling that
while we have nearly achieved a complete solution, there
is this one important thing still being missed... and
it's something really, really fundamental and crucial.

To indicate how important I think this is, I am willing
even to concede the doublet idiom and let it be left out
in order to see reasonable treatment given to this particular
issue. It would be inconvenient, but I think far less
inconvenient for users in general than if we did not
provide for the use of datatyping *with* the inline/S-B idiom.

Many folks, myself included, have data and systems that
have presumed that the combination of an inline literal
and a range constraint should mean *something* within the
context of datatyping.

Now, it's perhaps fair to say "nope, that's wrong", but
to do so will make the DT solution a much harder sell, I
think, and deny users of a very convenient and intuitive
form of expression.

We gave up on the inline idiom I think out of exhaustion
in trying to force the literal graph node itself to denote
the value, or contextually be either a literal or a value,
etc. which never would work. We went round and round and
round about whether some range constraint denoted the
lexical space or the value space, and came up with all
kinds of silly mechanisms (multiple URIs, variant
vocabularies, etc.) to try to make it work, to no avail.

However, the idea of treating the datatyping range constraint
as the union of the lexical and value spaces is pretty
new, and I don't think we've really given it fair consideration
(understandably so, given the late hour and pressing schedule).

I appreciate your comments about it being a weaker range
constraint -- and of course it is, that's the whole point.
But in conjunction with additional range constraints for
rdfs:Literal and rdfs:Resource, as outlined above, we can,
I think, have our cake and eat it too.

For most applications, they won't care about the weaker
constraint. All they care about is that the context of
interpretation is clear, and it is. They will support all
datatyping idioms (inline, value triple, datatype triple,
...) or let some API do that for them.

For applications that want/need the tigher constraints,
they can have it, but via two range statements rather than
one.

I sincerely and apologeticaly ask that you take just a little
bit more of your valuble time to give this approach serious
consideration. I think it can make the difference between a
good solution and a great one.

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 Wednesday, 20 February 2002 07:29:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:16 GMT