Re: Questions about the new datatyping proposal

It seems to me that this new datatyping would move all the (legacy inline
literals) from the lexical space to the value space.  Is that true?

	No. Untyped/inline literals are never members of
	the value space of a datatype. Nor are they members
	of the lexical space of any datatype. They continue
	to just *exist* with no formal definition of their meaning.

	However, typed literals, the pairing of a literal and a datatype,
	denote members of the value space of the datatype.

	At present, taking only Part 1 of the restructured 
	datatyping specification, nothing whatsoever is
	said about inline literals; only typed literals. It
	is not even suggested that inline literals are
	members of the lexical space of a datatype or
	participate in any other way with RDF datatyping.

	This agnosticism is intentional (at this stage) as
	the WG has not yet come to concensus about
	what inline literals mean; only about what explicitly
	typed literals mean.

When you say "RDF does not say anything about what an inline literal means",
doesn't that mean that the "datatype mapping" of legacy inline literals is
unknown?

	Yes. Inline literals, according to part 1, do not
	participate in datatyping. Their meaning remains
	undefined and application specific.

	RDF applications will be unnable to determine,
	based on the MT, whether the following entailment
	holds or not:
	
	IF
	Bob age "10" .
	Judy payday "10" .
	Movie title "10" .
	THEN
	Bob age ?x .
	Judy payday ?x .
	Movie title ?x .
	
	I believe that most if not all of the WG would like the 
	datatyping spec to actually say whether the above
	entailment holds or not, but we simply cannot agree
	on that issue, and the WG appears to be rather equally
	divided  (my own view is that it does not hold).

	The apparent majority preference inferrable from the 
	responses to the recent inquiry about the tidy/untidy
	debate is that most folks feel the above entailment
	should not hold, but it seems that the feedback 
	recieved was insufficiently strong to result in a
	choice being made by the WG.

	If anyone has a new and compelling argument either way, we'd 
	love to hear it.
 
... well I see a problem:

Moving (legacy inline literals) into the value space and leaving their
meaning unspecified (and unidentified by URI) means that automated agents
really have no way to identify and process them in a meaningful way.

	This is why it is not done. If we take  literals to be contextual
	names (i.e. untidy, not as global constants) then a literal by
	itself is ambiguous. 

... and a potential solution:

Why not make up a new (datatype mapping) that contains the whole lexical
space?  The URI for it (in qname format) would be something like
rdf:DatatypeUnknown .  

	This is similar to the approach taken in part 2, section C.2,
	where every literal is treated as a typed literal, and in the case
	of inline literals, the denotation of the datatype is implicit,
	and represented by a system identifier, in a similar fashion
	to how bnodes are named.

	Then, the actual datatype denoted by that system identifier
	must be determined via additional information, such as an
	rdfs:range assertion for the property.

	Applications then always know that they are dealing with *some*
	datatype value, even if the datatype is not explicitly specified
	for each occurence of a lexical form (literal).

	But, for the moment, all of part 2 is on ice until part 1 is
	finalized and fixed, and for now part 1 says nothing
	whatsoever about the meaning of inline literals.

	Cheers,

	Patrick

Received on Friday, 6 September 2002 03:35:00 UTC