Re: in line literal semantics

Bravo Jeremy. 

While I would myself prefer to also have untidy semantics for
inline literals, Jeremy's proposed middle ground of adopting
untidy syntax with unspecified semantics has the significant
benefits of (a) letting us postpone the decision about tidy
vs. untidy semantics, while still (b) providing an abstract
syntax that supports either interpretation.

I wholeheartedly support this proposal, whether or not we
also still decide to consider the semantics of inline literals.

(specific comments below)


[Patrick Stickler, Nokia/Finland, (+358 50) 483 9453, patrick.stickler@nokia.com]
----- Original Message ----- 
From: "ext Jeremy Carroll" <jjc@hpl.hp.com>
To: <w3c-rdfcore-wg@w3.org>
Sent: 08 September, 2002 23:29
Subject: in line literal semantics


> 
> 
> 
> In one camp, that has been quite quiet of late, we have those who argue that 
> inline literals should be self denoting.
> 
> In another, there are those, (some of whom believe the argument has been won), 
> who argue that inline literals denote something else, which might be made 
> clear elsewhere.
> 
> Then there also a few voices, myself and Graham, at the last telecon, arguing 
> for minimalism.
> 
> We have seen the tidiness vs untidiness debate as one without a middle ground.
> 
> The point of this message is to propose it. (or rather to remind the group of 
> its existence).
> 
> Middle ground:
> ============
> >From datatyping part 1:
>   Explicit data values in the graph are self denoting.
> 
> >From Valentines day MT (VMT)
> http://www.w3.org/TR/2002/WD-rdf-mt-20020214/
>   Other literals are syntactically untidy.
>   Literal semantics depends on a function XL mapping lteral nodes to literal 
> values.
>   Nothing is said about whether XL induces a function or not on the literal 
> labels. i.e. this does not rule out tidy semantics.
> 
> Moreover, consider the crucial tidiness entailments.
> 
> <a> <foo> "literal" .
> <b> <bar> "literal".

Which I presume would actually be written

   <a> <foo> _:x"literal" .
   <b> <bar> _:y"literal" .

Right?

> this does not entail
> 
> <a> <foo> _:b .
> <b> <bar> _:b .
>
> (in the VMT)

Right.

> However, this is not because of untidy semantics, but merely because the first 
> triple by itself is not entailed.
> i.e.
> <a> <foo> "literal" .
> 
> does not VMT-entail
> 
> <a> <foo> _:b 
> 
> (bnodes don't match literals in the Valentines day MT).

The nice thing here is that we can choose either tidy or untidy
semantics merely by adding closure rules to the MT, without
any change to the concrete or abstract syntax. Sweet.

Thus, if we want tidy semantics, then we simply assert that
each non-explicitly-typed literal denotes the
unicode string portion of its label. If the graph contains
the node (_:x, "LLL"), then I((_:x, "LLL")) = I("LLL").

And if we want untidy semantics, then we assert that the
systemID portion of a non-expliticly typed literal denotes
some datatype, typically disambiguated by a rdfs:range
assertion, e.g. if the graph contains the triples

   ddd rdf:type rdfs:Datatype .
   aaa bbb (_:x, "LLL") .
   bbb rdfs:range ddd .

then I((_:x, "LLL")) = I((ddd, "LLL"))

--

Very nice indeed. And we could even pre-specify the extensions to the MT
for the tidy versus untidy interpretations, so that application developers can
have a solid basis to choose one or the other, and a place to point to that
is official, even if non-normative.

> Thus, if we choose the Valentines day MT, we are not ruling out RDF2 choosing 
> tidy semantics.
> We, are old and tired, we already have agreed enough to meet our charter. We 
> should postpone work on the semantics of inline literals for a new and fresh 
> working group.
> 
> ========
> 
> Obviously, I have been an advocate of untidiness for a while; if the grouo has 
> consensus to go with untidiness, then I clearly would be in favour.
> However, I would also be very surprised.
> 
> If any of the group cannot live with Part 2, but could accept some sort of 
> compromise of the sort outlined above, then they would get my support.

If we cannot agree on the semantics of inline literals, then 
I think that Part 1 with the above addition of untidy syntax for inline
literals, and pre-defined MT extensions for tidy versus untidy semantics
would be a far more complete and reasonable solution than Part
1 alone, as presently defined. 

Though I think we should still give strong consideration to untidy
semantics.

> Another way to go would be for us to collectively downgrade the tidiness 
> issue. My take, is that with the values in the graph, the decision for tidy 
> or untidy is much less pointed. Although I would value the debate, I believe 
> my position has changed from "cannot live with tidy" to simply a preference 
> for untidy.
> If we all can downgrade our previously strong opinions then a debate and 
> asimple majority decision would suffice.

If Part 1 were extended with untidy syntax, and the semantics of
inline literals was left agnostic (allowing applications to assert either
tidy or untidy without running foul of the MT) then I would be 
satisfied with that.

I am not, however, prepared to downgrade my position from "cannot
live with tidy semantics" as I feel that tidy semantics of inline (non-typed)
literals is fundamentally wrong.

Regards,

Patrick

Received on Monday, 9 September 2002 03:42:27 UTC