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

Re: FW: Datatyping Summary

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Wed, 30 Jan 2002 14:47:23 +0000
Message-Id: <5.1.0.14.0.20020130143851.03188830@0-mail-1.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>, RDF Core <w3c-rdfcore-wg@w3.org>
At 20:41 29/01/2002 +0200, Patrick Stickler wrote:
[...]

>I definitely cannot live with an unecessary mulitplicity
>of synonymous vocabularies just to accommodate RDF datatyping.

Noted

>
>
> > Issue B3:  the "duh" issue
> > ==========================
> >
> > DanC is concerened that with TDL:
> >
> >  <mary> <haircolor> "red" .
> >
> > and a rule:
> >
> >  ?x <haircolor> "red" => ?x <rdf:type> <redhead> .
> >
> > one cannot conclude
> >
> >  <mary> <rdf:type> <rdfhead> .
> >
> > since one conclude that both "red"'s denote the same thing.
> >
> > Jeremy has responded:
> >
> > From:
> >
> >  <mary> <haircolor> "red" .
> >  <haircolor> <rdfs:range> <xsd:string> .
> >
> > and the same rule one can draw the required inference.
> >
> > DanC:  Does that solve the problem?  Do you withdraw that objection?
> >
> > Jeremy/Patrick:  Do you accept that without the range constraint, DanC is
> > correct?
>
>I do not accept that this is correct.

The question was:

DanC assserts that under TDL, given

   <mary> <haircolor> "red" .

  and a rule:

   ?x <haircolor> "red" => ?x <rdf:type> <redhead> .

  one cannot conclude

   <mary> <rdf:type> <rdfhead> .

Is he correct.  Patrick responds:

   I do not accept that this is correct

and from the text that follows, I believe that Patrick means "yes, this is 
correct".
Patrick, please can you confirm.


>A literal can only have globally unique meaning if some
>application context defines it as such, but RDF must exist in
>an enviroment where knowledge is expressed independent of
>application context, therefore, even if "red" always means
>the same thing to Dan's application, it may not mean that
>same thing, or consistently some other thing, to my application.
>
>I also do not concur that S takes such a view, that a literal
>always has the same meaning. The example in section 5 of Sergey's
>document bears this out, with most of the literals denoting
>different values, based on the mappings asserted by the
>predicates of the statements.
>
>I do not accept Dan's view that literals are global constants,
>as being valid for arbitrary global interchange and syndication
>of RDF expressed knowledge. It reflects a closed system view
>of an RDF graph.
>
> > Issue B4 - TDL breaks existing code
> > ===================================
> >
> > This is similar to B2.  I've changed the example slightly from Sergey's.
> > Consider the graph:
> >
> >  _:f <rdf:type> <film> .
> >  _:f <dc:Title> "10" .
> >  <mary> <age> "10" .
> >
> > Given a query:
> >
> >  (?x <dc:Title> ?y) & (?z <age> ?y)
> >
> > existing applications will return:
> >
> >  ?x = _:f, ?y = "10", ?z = <mary>
> >
> > Under TDL, they would return null.
> >
> > Sergey:  Does this version of the issue illustrate your point?
> >
> > Jeremy/Patrick:  Do you accept this analysis; would the query return null
> > under TDL?
>
>I've provided a response to this in
>
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jan/0365.html

My reading of your response is that you agree that under TDL, the query 
would return null.  Is that correct.


> > Issue B5:  Storage Requirements
> > ===============================
> >
> > TDL requires significantly more storage to implement.
> >
> > Jeremy/Patrick:  do you accept this statement?
>
>No. There are many ways to optimize the implementation of
>a triples store, even if literal nodes are untidy. It is
>an issue of the interpretation/model being based on untidy
>graphs, not the implementation.


Noted.  Sergey, do you accept that strings can be shared in a TDL 
implementation, avoiding a significant memory bloat, and that this issue 
can be removed from the list of 'show stoppers'.

Brian
Received on Wednesday, 30 January 2002 09:48:19 EST

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