Re: Any use cases for untidy literals except long range datatyping?

Patrick,

thanks for a quick feedback! A general comment: it seems that the 
examples that you give below deal with long range datatyping only. Are 
there in your opinion any *other* important use cases?

Further comments below.

Patrick.Stickler@nokia.com wrote:

> 
>>-----Original Message-----
>>From: ext Sergey Melnik [mailto:melnik@db.stanford.edu]
>>Sent: 12 August, 2002 13:19
>>To: RDF Core; pat hayes; Stickler Patrick (NRC/Tampere)
>>Subject: Any use cases for untidy literals except long range 
>>datatyping?
>>
>>
>>I'd like to restate the questions, which Jan raised recently, more 
>>explicitly.
>>
>>Much of the ongoing discussion about tidy/untidy literals amounts to 
>>arguing about different readings of a given piece of RDF/XML 
>>or NTriples 
>>syntax. From what I can tell, both tidy and untidy literals are 
>>implementable, so we have to pick one and wrap up.
>>
>>To my knowledge, untidy literals have been first suggested in the 
>>context of long range datatyping (aka implicit/global idiom). 
>>Specifically, untidy literals provide a shortcut for using a 
>>bNode with 
>>a property (two triples are essentially merged into one).
>>
>>Is this shortcut so fundamental that there is value of making 
>>it part of 
>>the spec?
>>
> 
> Yes. It mirrors common practice both in programming languages
> as in XML Schema.
> 
> Just as one may say
> 
>    int age;
>    age = 10;


Please see Grahams clarification to that point below (I think he replied 
offline, his answer is appended).


> ...
>>Is there an appealing use case for untidy literals that is not long 
>>range datatyping (aka implicit/global idiom)?
>>
> 
> Even if datatyping is not asserted for inlined, non-local typed
> literals at the RDF level, they still have untidy semantics
> at *some* level, and to impose tidy semantics at the RDF level
> is IMO misleading and will conflict with common sense when
> looking at the big picture -- at the whole stack.
> 
> Having tidy semantics at the RDF level and untidy semantics
> at the application level seems a fundamental contradiction
> that will come back to bite us (and users) again and again.
> 
> Take CC/PP as an example. Datatyping is globally asserted for
> properties (at present, by the application, since it can't
> yet be done in RDF) and the interpretation of the same literal
> string as the value of two properties with different datatyping
> is untidy, depending on the property datatype.
> 
> Now, if such literals are tidy in the RDF MT, then the MT
> is saying that those two statements "mean" one thing at
> the RDF level, but something else at the CC/PP application
> level. Now, though one might wriggle around that with all
> kinds of smoke and mirrors, I'd prefer to see the same meaning
> at both levels, with the property values being the datatype
> values.


The above example does not address the question raised in the subject of 
this email ;) Still a comment: in the latest proposal, there are no 
"levels" of interpretation etc. Typed literals have a fixed 
interpretation with consistent meaning...


>>Are we closing off any important extensibility paths if we go 
>>for tidy 
>>literals?
>>
> 
> If literals (non-datatyped literals) are tidy, then if later
> we allow literals to be subjects, they are far, far less
> interesting than if they are denoting the datatype value
> which they (contextually) represent.
> 
> Patrick


I don't understand. If, later on, a URI scheme (or a bNode-based 
mechanism) for RDF datatyping is introduced, it would be possible to use 
resources/bNodes as subjects. Such resources/bNodes would denote 
literals. Could you rephrase your concern?


Sergey




Graham Klyne wrote:

 > At 02:46 PM 8/11/02 +0200, Sergey Melnik wrote:
 >
 >> Mike Dean wrote:
 >>
 >>> Sergey,
 >>> Below is my example of why I see Java (and C++) as employing
 >>> global implicit typing.  I can use the same literal
 >>> (constant) value with a variety of numeric types, and don't
 >>> have to change it if the type changes among the numeric
 >>> types.
 >>>         Mike
 >>> lass globalimplicit
 >>> {
 >>>     public static void main(String args[])
 >>>     {
 >>>         short s;
 >>>         int i;
 >>>         float f;
 >>>         double d;
 >>>         s = 5;
 >>>         i = 5;
 >>>         f = 5;
 >>>         d = 5;
 >>>     }
 >>> }
 >>
 >
 > Mike,
 >
 > I beg to disagree:  what Java offers is (limited) implicit type
 > coercion, not implicit typing of literals.  In every case, above, the 5
 > represents an integer typed value.  Exactly the same result would be
 > obtained with the following code:
 >
 >     public static void main(String args[])
 >     {
 >         static int five = 5 ;
 >         short s;
 >         int i;
 >         float f;
 >         double d;
 >         s = five;
 >         i = five;
 >         f = five;
 >         d = five;
 >     }
 >
 > #g
 >
 >
 > -------------------
 > Graham Klyne
 > <GK@NineByNine.org>

Received on Monday, 12 August 2002 08:02:16 UTC