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

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

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 10 Sep 2002 12:00:20 +0300
Message-ID: <003d01c258a8$7e6455d0$294516ac@NOE.Nokia.com>
To: "Jeremy Carroll" <jjc@hpl.hp.com>, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
Cc: <w3c-rdfcore-wg@w3.org>

[Patrick Stickler, Nokia/Finland, (+358 50) 483 9453, patrick.stickler@nokia.com]

----- Original Message ----- 
From: "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
To: "Jeremy Carroll" <jjc@hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>
Sent: 09 September, 2002 13:44
Subject: Re: in line literal semantics (and some thoughts on CC/PP)

> 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

I would rather see the migration path for CC/PP and similar, where
the semantics of lexical forms is mandated by fixed property types,
to work via long range typing mechanisms.

I.e., to reflect in RDF what the intended semantics of CC/PP already
is, that every value of pix-x is an integer. Thus:

   <rdf:Description rdf:about="#pix-x">
      <rdfs:range rdf:resource="&xsd;integer"/>

For ontologies that have strong typing, such as CC/PP, and BTW every
ontology I am aware of in use internally in Nokia, having to specify
the type for every occurrence of a value is (a) grossly redundant,
and (b) hides the fact that the datatype is fixed by property and
that one cannot or should not specify some other type locally.

If RDF cannot officially reflect such long range datatyping semantics,
then at the very least, applications should be free to augment the
RDF MT with such applications specific semantics, which should be
supported by the RDF MT by remaining silent about the meaning of
untyped inline literals.


Received on Tuesday, 10 September 2002 05:00:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:00 UTC