Re: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP

Graham Klyne wrote:
> CONCLUSIONS
> -----------
> I draw the following conclusions:
> 
> (a) given a literal string, there needs to be some way to decide how it 
> should be interpreted as a literal value.
> 
> (b) applications should be able to perform basic RDF handling without 
> knowing how to interpret the literal strings.
> 
> (c) there is an existing base of RDF usage in which interpretation of a 
> literal string depends upon knowledge of and about a property that 
> references it.
> 
> (d) if we are to support existing RDF applications, interpretation of 
> literal strings cannot be confined to a single defined scheme of data 
> typing and interpretation.  Flexibility to accommodate things like 
> prf:display is needed.
> 
> (e) insistence on having complete information about data typing and 
> representation embedded in
> any single piece of RDF is not an option.  In some cases, full knowledge 
> may be embedded in a specific application that processes the 
> RDF.  (Yes:  such information will not be accessible to generic RDF 
> processors.  Tough luck.  We can encourage future RDF application
designers 
> to do better -- that was my goal in specifying preferred simple attribute 
> types for CC/PP, based on my CONNEG work.)

It appears to me that we have two separate issues here:

1. The association of data type to literal.
2. The prescriptive/descriptive nature of data types.

To date, the first issue has provided two means: the first, which
is perhaps a bit more official, is to define an rfds:range for a
property. This is descriptive if no local type is defined for the
literal, otherwise it can be interpreted as prescriptive. The second
is to use a typed anonymous node (bNode) having rdf:value defining
the literal and rdf:type defining the data type. Again, in the
absence of an rdfs:range defined for the property, this is merely
descriptive, but if a range is defined, provides the basis for
further validation.

In either case, the association of a data type with a literal also
may define the lexical constraints for that literal, and hence even
if the type classification is descriptive insofar as property
semantics are concerned, is can be prescriptive insofar as lexical
form is concerned.

I agree with what Graham seems to be proposing here, that these two
means of associating data types to literals be preserved and that
the "solution" achieved by the wg be a clarification of how
various combinations of local versus range type definitions are
to be interpreted and the role that lexical constraints may play in
validation of literals.

We should not mandate an particular data type scheme, nor deprecate
either of the above mentioned means of associating type with literals,
but focus on providing consistent and clear instructions to 
applications about how to interpret such type information. And above
all, we should try to achieve a generic representation of literals
in the graph by which applications can find them without recourse
to specialized ontologies beyond RDF and RDFS.

Eh?

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 5 November 2001 09:59:37 UTC