W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

Re: Datatyping Summary V2

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 31 Jan 2002 10:57:13 +0200
To: ext Brian McBride <bwm@hplb.hpl.hp.com>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B87ED389.CCD8%patrick.stickler@nokia.com>
On 2002-01-30 21:41, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

> An updated summary of the datatyping issues, as I currently understand them.
> 
> Issue B1:
> =========
> In S, if one wants to use both idiom A and idiom B, e.g.
> 
> <mary> <age> "10" .
> <age> <rdfs:range> <xsd:integer.lex> .
> 
> and
> 
> <mary> <ageD> _:a .
> _:a <xsd:integer.map> "10" .
> 
> two properties have to be used, <age> and <ageD>, in this example.
> I believe there is a agreement that this is a difference between the
> two proposals.  Indeed, it may be said that the main aim of TDL is
> to avoid requiring different properties for these different idioms.
> 
> Can't Live With:  PatrickS

I think it would be useful for the group to make explicit what
the ramifications of this are -- which should make it clear (I
hope) why I cannot live with it.

In order to use both S-A and S-B in the same knowledge base, or
syndicate knowledge using either idiom into a merged knowledge
base, we would have to have *two* variants of every metadata
vocabulary: DC, PRISM, ONIX, MARC, vCard, etc.

I.e. dcA:title and dcB:title and then relate the two together
so that queries asking for dc:title would obtain knowledge
expressed in either idiom.

Ouch. Yuck. Blech. Insert your favorite expletive here _____ ;-)

I just can't see the RDF community at large buying into such
a scenario.

And it is imperative that we support both global and local
typing for literals, so the alternative -- choose only S-A
or S-B is equally unacceptable.


> Issue B4 - TDL breaks existing code
> ===================================
> 
> This is similar to B3. I've changed the example slightly from Sergey's.
> Under TDL, consider the graph:
> 
>  _:f <rdf:type> <film> .
>  _:f <dc:Title> (_, "10") .
>  <mary> <age>   (_, "10").
> 
> Does this entail:
> 
>  _:x <dc:Title> ?y .
>  _:z <age>      ?y .
> 
> I believe there is agreement that it does not under the current TDL model
> theory.

No. This is not correct. We just don't seem to be connecting
on this one Brian. It is an issue of whether the query is based
on string equality or value equality -- whether datatyping is
taken into consideration. If we treat the parenthesized versions
as TDL pairings (which I think is your intent) and use that
as an indication of whether the query is string or value based
then I think the results should become clear.

Let me try to expand it to all significant cases:

--

Case 1: (value comparison, no datatyping specified)

_:f <rdf:type> <film> .
_:f <dc:Title> (_, "10") .
<mary> <age>   (_, "10").

DOES entail

_:x <dc:Title> ?y .
_:z <age>      ?y .

(though probably should flag some warnings since
 the query is expecting datatypes as that is the
 basis for value comparison)

--

Case 2: (string comparison, datatyping ignored)

_:f <rdf:type> <film> .
_:f <dc:Title> "10" .
<mary> <age>   "10".

DOES entail

_:x <dc:Title> ?y .
_:z <age>      ?y .

--

Case 3: (value comparison, datatyping defined)

_:f <rdf:type> <film> .
_:f <dc:Title> (xsd:string, "10") .
<mary> <age>   (xsd:integer, "10").

does NOT entail

_:x <dc:Title> ?y .
_:z <age>      ?y .

--

Case 4: (value comparison, datatyping partially defined)

_:f <rdf:type> <film> .
_:f <dc:Title> (_, "10") .
<mary> <age>   (xsd:integer, "10").

does NOT entail

_:x <dc:Title> ?y .
_:z <age>      ?y .

(and as with case 1 should probably flag a warning
 due to the unspecified typing)


Is that clearer now?

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 Thursday, 31 January 2002 03:56:20 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:44:04 EDT