Re: datatyping unstaked

On 2002-06-14 16:05, "ext Dan Connolly" <connolly@w3.org> wrote:

> 
> On Thu, 2002-06-13 at 22:04, patrick hayes wrote:
> [...]
>> Still, there is no free lunch, and it does require
>> making some changes to the current RDF docs, particularly the MT, and
>> maybe some of the test cases.
> 
> That made me nervous...
> 
> And indeed,
> 
>> For example, the above graph does NOT entail
>> 
>> <ex:Jenny> <ex:age> _:x .
>> _:f <dc:title> _:x .
>> _:f <rdf:type> <ex:movie> .
> 
> That kills it, for me.
> 
> That's the characteristic
> I actually need about literals. It's no fun
> saying they denote themselves if you can't
> existentially generalize them.
> 
> i.e. this is just another form of untidy literals.

That was my take. Though I strongly feel that untidy
literals are necessary, and how the majority of the
RDF community interprets literals in their applications
(even if you do not).

Would it be sufficient for you, Dan, to be able to
base comparisons on literal string equivalence, even
if those literal nodes might denote different values?
(though that would seem dangerous to me)

Why is it imperative for you that literals have globally
consistent meaning as do URIs? And if so, why then use
literals at all? If you need globally consistent identifiers,
why don't you simply use URIrefs?

It seems that you are trying to force a quality onto
literals (globally consistent meaning) that the majority
of RDF users do not consider to be inherent in literals.

CC/PP employs untidy literal semantics. Many DC users
assume untidy literal semantics. Even the M&S examples
suggest untidy literal semantics.

Tidy literals appear to be contrary to common interpretation
and usage, so why do we insist on them.

Untidy literals, IMO, are the way forward for RDF
datatyping.

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 Sunday, 16 June 2002 09:43:45 UTC