Re: heading toward datatyping telecon

>   <http://example/thingy> <eg:size>      _:size .
>   _:size                  <xsd:integer>  "12" .
>   _:size                  <eg:hexint>    "C" .
>   _:size                  <rdf:type>     <eg:integer>

Or perhaps something more generic, consistent, and which
follows the common boundary between value space and lexical
representation used by programming languages:


   <http://example/thingy> <eg:size>      _:size .
   _:size                  <rdf:value>    "12" .
   _:size                  <rdf:value>    "#xC" .
   _:size                  <rdf:type>     <eg:integer> .

Thus, we *know* that we have 2 values, because we have two
objects for the rdf:value property, and we know that they
both belong to the data type eg:integer, and we can use that
basis to determine whether they are equivalent alternate
lexical representations of the same VALUE.  Though we still
have the problem of neither "C" nor "#xC" being valid lexical
forms for xsd:integer and what that means in the RDF graph
as opposed to an XML serialzation.

Unfortunatley, it gets a little tricky when either we have 
multiple data types defined as well as unequal values:

   <http://example/thingy> <eg:size>      _:size .
   _:size                  <rdf:value>    "12" .
   _:size                  <rdf:value>    "#xC" .
   _:size                  <rdf:value>    "12.0" .
   _:size                  <rdf:type>     <eg:integer> .
   _:size                  <rdf:type>     <eg:float> .

Which values goes with which type?

It seems to me that the following is alot easier to deal with,
though it does, of course, impose the need for interpretation
which is not (yet) defined in any standardized way:

   <http://example/thingy> <eg:size> <eg:integer:12> .
   <http://example/thingy> <eg:size> <eg:integer:#o14> .
   <http://example/thingy> <eg:size> <eg:integer:#xC> .
   <http://example/thingy> <eg:size> <eg:integer:#b1100> .
   <http://example/thingy> <eg:size> <eg:float:12.0> .

This keeps the value, type, and lexical representation together
in a convenient, consistent fashion and such URVs can act as
the subjects of statements, and their equivalence can also
be defined unambiguously by statements without any need for
extending RDF or adding any special treatment in the MT (as
far as I can see). Whether the above statements constitute 5
different VALUEs or 5 representations of the same VALUE is not
the concern of RDF. All that matters to RDF is that the
knowledge necessary to determine such equivalence is present
in a consistent and retrievable fashion. No?

Note that these URVs are no different than e.g. instances of
the 'data:' URI scheme (which also is, BTW a URV and not a URL
as presently defined ;-) All are a means by which typed data 
literals can act as proper resources with a portable, explicit, and 
consistent representation.

Problems and challenges with regards to merging or equating bnodes
simply do not apply for URVs. And it leaves the interpretation of literal
values cleanly outside the scope of RDF graph interpretation. URVs
are resources. Period. Interpretation of particular resources and
their properties and characteristics are not the worry of RDF
proper, but of applications operating on RDF encoded knowledge. One
can still qualify occurrences of URVs just as for any resource,
but for most cases (which really are concerned only with associating
a type with the literal) this becomes unnecessary -- resulting in
a much less "obese" graph and more condensed serialization.

Cheers,

Patrick


PS: BTW, I'm working on several I-Ds defining the basic concepts
oulined in my X-Values monograph as well as several URI schemes
grounded in those concepts -- including a URV scheme for XML
Schema primitive and derived data types, such as illustrated
above, but which includes explicit regular expression patterns
for simple run-time validation of lexical forms. I'm hoping to have
those out in the next week or two.

--
               
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 04:10:36 UTC