FW: Datatyping Summary

On 2002-01-28 23:58, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

> 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.
> 
> Does anyone in the WG consider this feature of S, on its own, to be a
> "can't live with" issue with S?

To be honest, I can't imagine that *anyone* would want to
live with this.

What you are proposing is to have *two* vocabularies for
every present vocabulary -- one for each idiom. So
now we need DC for idiom S-A and DC' for idiom S-B,
e.g. dcA:title and dcB:title.

Not to mention the statements that must be made, and
taken into account during queries, that equate the
two synonymous vocabularies.

I definitely cannot live with an unecessary mulitplicity
of synonymous vocabularies just to accommodate RDF datatyping.
 
  
> 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.

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

> 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.



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 Tuesday, 29 January 2002 13:40:07 UTC