- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 5 Nov 2001 16:59:25 +0200
- To: w3c-rdfcore-wg@w3.org
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