Re: Reject change to rdf:value

> Well, if that were indicated by a decimal then the 
> string "10" would do it, but if it were represented by an octal then 
> you need "12" and if you use a binary then you need "1010". There is 
> no way to say what THE value of rdf:value is for any particular 
> integer, until you specify what datatyping scheme is being used. 

No. Data type does not define lexical representation, and base is
just another issue of representation, not an inherent quality of
the value itself. I.e. (taking the lexical representations defined
for the Scheme programming language simply to illustrate):

  [ rdf:value "10";     rdf:type xsd:integer ].  (decimal)
  [ rdf:value "#o10";   rdf:type xsd:integer ].  (octal)
  [ rdf:value "#xA";    rdf:type xsd:integer ].  (hexidecimal)
  [ rdf:value "#b1010"; rdf:type xsd:integer ].  (binary)

In each case, the data type itself is the same, as is the value.
Only the lexical representation changes, and in each case, the
interpretation of that lexical representation within the context
of that data type is explicit and reliable.

Thus, while it is likely true that one cannot interpret a literal
value without knowledge of its data type, and a given VALUE (as
opposed to rdf:value) may have multiple lexical representations,
the data type itself has little if anything to do with determining
whether any two rdf:value's correspond to the same VALUE, apart
from expecting them to belong to equivalent or related data types.

The issue of whether "10" "#o10" and "#xA" are the same "thing" is
precisely the same issue as to whether "5" or "00005" are the
same "thing" or further, if "5" "00005" "5.0" "0005" or "5.0000000"
are the same "thing". It is IMO beyond the scope of RDF proper,
and should be left to the interpretation of specific systems,
based on the data type information that is provided -- and it
is imperative that regardless of typing and other qualifications
associated with a given rdf:value in the graph, that the rdf:value
itself be clearly identifiable, and not hidden behind any 
specialized properties such as eg:hexidecimal or xsd:integer, etc.

ASSERTION/PROPOSAL:

   In all cases of qualified anonymous node constructs, the value of
   the property should IMO always and without exception be the 
   object of an rdf:value property defined for that anonymous node.
   Otherwise, we turn the graph into a much more complex puzzle than
   it need be for generalized operations based solely on RDF and
   RDFS semantics.

And as an aside, a "good" lexical representation specification will
disallow semantically vacuous variants such as "00005" or "5.0000".
It is interesting that, insofar as the prose provided by XML Schema,
it defines a "good" lexical representation for data types such
as integers, disallowing such vacuous representations; however, 
no actual regular expressions defining those representations are
provided in the normative schema, and hence, no system using the 
"official" schema definitions can validate against any lexical
representation, much less such vacuous representations, without
a static, built-in knowledge of those base types -- which imparts
a very heavy implementational burden for systems which are not
XML Schema parsers/validators but wish to easily validate XML
Schema simple data types according to their lexical forms. Pity...

It is also important to note that XML Schema does *not* allow the
expression of xsd:integer in anything but base 10. Hence the examples
above such as [ rdf:value "#xA"; rdf:type xsd:integer ]. are in fact
invalid and erroneous, as "#xA" is not a valid lexical form as defined 
by XML Schema for the integer type -- presuming that the assigning of a
type xsd:integer to a literal string "#xA" is to considered equivalent
to an XML serialized representation <xsd:integer>#xZ</xsd:integer> such
that all of the constraints and properties of the data type xsd:integer
(including lexical constraints) apply. Whether or not the use of
xsd:integer as an rdf:type can transcend those lexical constraints and
represent only the abstract numerical type for 'integers', and how
that would be achieved, is a very interesting (though different) question.

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 03:21:59 UTC