Re: The case for untidy literal semantics

At 11:39 25/09/2002 +0300, Patrick Stickler wrote:


>[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, 
>patrick.stickler@nokia.com]
>
>
> > Some RDF assumes string based semantics for literals.  [There ought to be a
> > reference here, perhaps something from RSS ...
>
>RSS presumes value-based semantics.
>
>C.f. http://web.resource.org/rss/1.0/modules/syndication/, e.g.

Interesting.  Do you think RSS uses value based semantics throughout?  Hmm, 
what test do we apply to tell the difference?


> > 2.  Principle of Least Change
> > ...
> > 2) As expressed, this argument does not address the tradeoff that
> > exists.  Whilst adopting untidy semantics makes it easier to specify that a
> > literal really denotes an integer, it adds a burden of requiring the
> > content producer to specify that strings were intended, where that would
> > not be necessary with tidy semantics.
>
>Yet, this has the clear benefit of the intent of the content producer
>being made explicit and clear, rather than remaining implicit or
>even unknown. It also serves to help identify conflicts between systems
>in their presumptions about interpretation, should one system assert
>e.g. xsd:string and another assert xsd:integer for the same property.
>Surely such knowledge would be emmensely beneficial and worth the effort
>of specification.
>
>--

Ok, you are suggesting a new benefit.  Rewriting to check I've understood:

Untidy semantics requires the content producer to be explicit about the 
datatype of a property value.  This will have the benefit of detecting 
errors that would otherwise not be noticed, e.g. when one system processes 
something as a string and the other as an integer.

I think I'm missing something here and explaining it right.  Comparing the 
tidy and untidy semantics in this case.

Tidy semantics:  Type of object of a property is Literal.  System A asserts 
range of property is xsd:string.  Thats a type class.  System B asserts 
range of property is xsd:integer.  Thats a type clash too.

Untidy semantics:  Type of object of a property is a Literal.  System A 
asserts range of property is xsd:string.  Systems continues just 
fine.  System B asserts range of property is xsd:integer.  System B 
continues just fine.

I guess I've got the scenario wrong.  Can you explain the one you had in mind.


>You appear to have missed one very important issue, namely,
>
>Probable Schism of the RDF Community
>--------------------------------------
>
>If tidy semantics is adopted *and* those applications which are
>already deployed which employ inline literals with value-based
>semantics (Adobe XMP, CC/PP, DC, RSS, etc.) refuse to change their
>serializations for reasons of practicality (and that is likely to
>be the case), then these applications will have conflicting and
>non-monotonic interpretations of the RDF compared to the RDF MT.

I did try to capture what I think is the technical issue here, that in 
cases like bitPerPixel, with tidy semantics a generic RDF processor will 
not be aware of the integer "nearby" to borrow DanC's phase.  Checking the 
summary:

   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0251.html

Yes, section 2, principle of least change is intended to capture that.  Not 
satisfactorily I guess.

I think the point here is that with untidy semantics it is easier to 
retrofit datatype information to existing content.  If we don't do that, 
then there is information we are not capturing in the RDF, i.e. that a 
generic RDF processor, rather than one with specific application knowledge, 
will be aware of.

If that capture the idea, I will try to rephrase to make it more clear.

Again, I'm not sure that I've got your full point though.  You use the term 
"schism" which to me is about the community dividing into warring 
camps.  Is that what you intended to suggest?  If so could you amplify a 
little.


>The RDF MT will say that a given inline literal denotes itself,
>the string, yet the application may say that it denotes something
>else -- thus, entailments that hold for the RDF MT may not hold
>for the application MT and visa versa.

What application model theory.  I can point to the model theory for 
RDF(S).  But I'm not aware of any application model theories.

>Furthermore, higher level
>or client applications which wish to interact with RDF knowledge
>expressed according to these value-based models will not be able
>to utilize generic RDF tools and inference engines because they
>will not behave correctly according to the value-based semantics.

Right.  To strengthen this point, are you aware of any concrete, pragmatic 
examples where this really matters.

Brian

Received on Wednesday, 25 September 2002 05:47:06 UTC