W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2002

Re: in line literal semantics (and some thoughts on CC/PP)

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Mon, 09 Sep 2002 11:44:03 +0100
Message-Id: <5.1.0.14.2.20020909111013.046a4ba0@127.0.0.1>
To: Jeremy Carroll <jjc@hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org

I agree with Jeremy in the following points:

(1) At this point, we should aim for the minimum specification that we can 
all agree is needed

(2) I have a slight preference for untyped literals being untidy, but that 
preference is somewhat lessened by the availability of explicitly typed 
literals (rationale:  the use of explicit typing pushes many of the 
consistency checking issues to being some form, of simple 
schema-consistency computation;  for the few remaining cases where 
long-range typing really is required, the introduction of explicit bNodes 
is not such a burden [my interpretation of an observation of Brian's]).

(3) I find very attractive the option of leaving semantics very weak for 
untyped literals (in this revision of the spec).

But...

There is one point I think should be considered, though not necessarily as 
part of the specification:  there are existing applications that use 
untyped literals -- if we leave their semantics very weak, then there is a 
probable impediment to participation in a "full-strength" semantic web.  I 
think it might be helpful to outline possible migration paths for these 
applications.

Consider CC/PP, which currently recommends constructs like:

   <rdf:Description about='HardwarePlatform'>
      <ccpp-client:pix-x>1024</ccpp-client:pix-x>
   </rdf:Description>

intended to interpreted in conjunction with this schema:

   <ccpp:Attribute rdf:about='http://www.w3.org/2000/07/04-ccpp-client#pix-x'>
     <rdfs:label>Pixel display width</rdfs:label>
     <rdfs:domain rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
     <rdfs:range 
rdf:resource='http://www.w3.org/2001/XMLSchema-datatypes#integer'/>
     <rdfs:comment>
       For raster displays, the width of the display in pixels.
     </rdfs:comment>
   </ccpp:Attribute>

and

   <rdfs:Class rdf:about='http://www.w3.org/2001/XMLSchema-datatypes#integer'>
     <rdfs:label xml:lang="en">Integer value</rdfs:label>
     <rdfs:subClassOf 
rdf:resource='http://www.w3.org/2000/01/rdf-schema#Literal'/>
     <rdfs:comment xml:lang="en">
       This class is used to represent any CC/PP attribute value that
       is an integer number.
     </rdfs:comment>
     <rdfs:seeAlso rdf:resource=
         'http://www.w3.org/TR/xmlschema-2/xmlschema-2.html#integer'/>
   </rdfs:Class>

A weak semantics for untyped literals would mean that RDF alone does not 
define all of the meaning here that would be gleaned by a specific CC/PP 
application, namely that the value of property 'pix-x' is an integer.  The 
RDF meaning would not be wrong, but it would be incomplete.  A more 
complete meaning would be available by specifying something like:

   <rdf:Description about='HardwarePlatform'>
      <ccpp-client:pix-x 
rdf:dattype='http://www.w3.org/2001/XMLSchema-datatypes#integer'>1024</ccpp-client:pix-x>
   </rdf:Description>

but this would not be compatible with present-day UAPROF and CC/PP 
specifications.

The migration path is to point out that the current UAPROF/CCPP is valid 
(if complete) RDF, and to recommend that future versions recognize an 
explicit datatype attribute.

#g
--

At 10:29 PM 9/8/02 +0200, Jeremy Carroll wrote:



>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".
>
>this does not entail
>
><a> <foo> _:b .
><b> <bar> _:b .
>
>(in the VMT)
>
>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).
>
>
>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.
>
>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.
>
>Jeremy

-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Monday, 9 September 2002 08:47:04 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:50:57 EDT