Re: Draft datatypes message

On 2002-06-21 17:12, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

> 
> This is first draft of the datatypes message I agreed to produce at the f2f.
> 
> Brian
> =============================================================================
> 
> The RDFCore WG is producing a proposal for how XML Schema datatypes should
> be used in RDF.  We would like some guidance on a particular tradeoff we
> have to make.
> 
> The WG requests that you send your considered answers to
> www-rdf-comment@w3.org, along with any comments, thoughts or questions you
> may have.
> 
> INTRODUCTION TO DATATYPES
> =========================
> 
> Let's explain the basic ideas behind our approach to datatyping.  We are
> proposing two principal idioms for representing datatyped information.  The
> first looks like this:
> 
>  <Jenny> <age>          _:a .
>  _:a     <xsdr:decimal> "10" .

What is this 'xsdr:'? This should be 'xsd:decimal'.

> 
> This can be written in RDF/XML like this.
> 
>  <rdf:Description rdf:about="Jenny">
>    <foo:age xsdr:decimal="10"/>

Again, should be 'xsd:decimal'

>  </rdf:Description>
> 
> Here the b-node _:a denotes the integer 10 which can be represented in
> decimal form as "10".  The WG believes that this distinction between
> numbers, e.g. 10 and numerals (which are strings) e.g. "10" is important if
> we are to precisely define the semantics, e.g. 10 # "10".
> 
> This idiom treats an XML datatype as a mapping from a value to a lexical
> representation of the value; this mapping is represented in RDF by a property.
> 
> We believe this idiom to be quite straightforward, but not sufficient on
> its own because it is common practise to write things like:
> 
>  <jenny> <age> "10" .
> 
> where the author of this fragment of RDF means to represent the fact that
> Jenny's age is the number 10.  This is the second idiom, which is where we
> need some guidance.
> 
> 
> SOME TEST CASES
> ===============
> 
> It is here that we need some advice, because we have a choice to make in
> the way we define the formal semantics.
> 
> A few simple test cases:
> 
> Test A:
> 
>  <Jenny> <ageInYears> "10" .
>  <John>  <ageInYears> "10" .
> 
> Should an RDF processor conclude that the value of the ageInYears
> properties for Jenny and John are the same?
> 
> Test B:
> 
>  <Jenny> <ageInYears> "10" .
>  <Jenny> <testScore>  "10" .
> 
> Should an RDF processor conclude that the value of Jenny's ageInYears
> property is the same as the value of Jenny's testScore property?
> 
> Test C:
> 
>  <Jenny> <ageInYears>   "10" .
>  <Film>  <title>        "10" .
> 
> Should an RDF processor conclude that the value of Jenny's age property is
> the same as the value of the Film's title property?  If the value the
> <ageInYears> property is an integer, and the value of the <title> property
> is a string, they are not the same thing and are thus not equal.
> 
> Test D:
> 
>  <Jenny>      <ageInYears> "10" .
>  <ageInYears> <rdfs:range> <xsd:decimal> .
> 
>  <John>  <ageInYears>      _:a .
>  _:a     <xsdr:decimal>   "10" .

Again, should be xsd:decimal

> 
> Should an RDF processor conclude that Jenny and John have the same
> age?  [Note: in this example the range constraint is expressed using
> rdfs:range.  We may have to introduce a special datatyping range property,
> but that is an independent detail for now.]
> 
> It is not possible to have the answers to Test B, Test C and Test D all be
> yes.  Either B and C can be yes or D can be yes.  We have to decide which
> of these is the most important to have; (B and C) or D.

Test A can be considered true regardless whether the objects are taken
to be strings or values.

> 
> WHY THESE TEST CASES MATTER
> ===========================
> 
> The formal semantics can define the meaning of a literal in one of two ways:
> 
>  tidy) the <ageInYears> property takes a value which is a numeral, i.e. a
> string
> 
>  untidy) the <ageInYears> property takes a value which is some datatype
> value whose string  representation is "10", but without further
> information, such as
> a range constraint, we can't tell exactly what the value is, e.g. the
> string might be in octal.
> 
> If we choose the tidy option, the object of the statement is always a
> string, which means that in:
> 
>  <Jenny> <ageInYears> "10" .
>  <Film>  <title>      "10" .
> 
> the values of the two properties are the same; they are both the STRING "10".

You could add:

And no datatype value is provided to any RDF application, only the
string, and it is not specified at the RDF level what is meant by
the string "10" -- i.e. whether Jenny's age actually is the number 10
or (oddly but possibly) the string "10".

> 
> If we choose the untidy option, the value of the object object of the
> statement is unknown from this statement alone; a range constraint is
> required to determine the value from the literal string:
> 
>  <jenny>      <ageInYears> "10" .
>  <ageInYears> <rdfs:range> <xsd:decimal> .
> 
> With a range constraint, we can know that the object of the property is the
> integer 10.

Note that the use of rdfs:range in this fashion follows from normal
usage of RDF Schema semantics. I.e. this approach does not constitute
an extension to RDF or RDF Schema in order to provide for global
datatyping constraints.

> 
> CONCLUSION
> ==========
> 
> To end then, please send a message to www-rdf-comments@w3.org indicating
> whether you believe its more important to have the answer to test case B be
> yes, or test case D be yes:

You might better make the choice between C and D, as their distinction
is IMO clearer.

> 
>  Test B:
> 
>  <Jenny> <ageInYears> "10" .
>  <Jenny> <testScore>  "10" .
> 
> Test D:
> 
>  <Jenny>      <ageInYears> "10" .
>  <ageInYears> <rdfs:range> <xsd:decimal> .
> 
>  <John>  <ageInYears>      _:a .
>  _:a     <xsdr:decimal>   "10" .
> 
> 
> We would also like to know the reasons for this preference.

And the deadline for replies?

> Brian McBride
> on behalf of the RDFCore WG
> 
> 

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

Received on Sunday, 23 June 2002 07:27:45 UTC