Re: TDL conflicts with the "duh!" requirement

On 2002-01-25 18:27, "ext Dan Connolly" <connolly@w3.org> wrote:

> Brace yourself for mind-bogglinly deep
> formal argument:
> 
> premise:
> <http://www.w3.org/> dc:title "W3C".
> conclusion:
> <http://www.w3.org/> dc:title "W3C".
> 
> That's it.*
> 
> "Duh!" you say. Indeed.
> 
> This is the "duh!" requirement: any formal
> system in which formuala F doesn't entail
> itself does not meet the "duh!" requirement.
> 
> TDL[TDL] does not meet the "duh!" requirement.
> (the TDL proponents will please correct
> me if I have misunderstood, but I'm pretty
> sure, based on the clarification of TDL
> I just got in the telcon, that it does not.)
> Therefore I find it totally unacceptable.
> 
> All of the work that SWAD does on RDF
> rules relies on the "duh!" requirement.
> 
> we write stuff like:
> 
> :Fred :hairColor "red".
> 
> { ?x :hairColor "red" }
> log:implies { ?x a :RedHead }.
> 
> and we expect our system to conclude
> 
> :Fred a :RedHead.
> 
> In the TDL proposal, I cannot do this,
> because I am not licensed to infer
> that the "red" in the first line and
> the "red" in the head
> of the rule denote the same thing
> in all interpretations.

And you say that S does license such an
inference? I don't see how it can anymore
than TDL could.

Your implication has to be as precise as
your datatyping, if your RDF is to be
portable.

If you have no RDF defined typing whatsoever, then you
have no means to differentiate any variant
interpretations of a literal value, thus
they all *have* to denote the same thing
and there exists an implicit datatype of
sorts corresponding to the set of all values
asserted for a given property where the
lexical forms simply map to themselves. I.e
the value space and lexical space are identical
and the members are the literals themselves.
But that's not the same as saying they are all
strings (or xsd:string) as once you introduce
any local typing for a literal, or global
typing for the property, that implied typing
disappears. The value is not both a string
and whatever the other datatype is. It's
just that in the total absence of typing,
values are just literals, and literals,
being lexical forms, can be distinguished
for string-equality.

If, however, you allow typing on your values,
and typing can result in different interpretations
per the type, i.e. the literal value can
denote different things, then your implications
must also be specific as to the datatype context
in which the type is to be interpreted.

It is no different than

 :Bilbo :age "111".
 
 { ?x :age "111" }
 log:implies { ?x a :EleventyOner }.

Yet, your implication is based on the implicit
presumption that values are in decimal notation.

Yet, surprise, surprise, I asserted Bilbo's
age in binary!

If you really want to capture the implication,
you must also specify the datatype which ensures
the expected interpretation of the lexical form.

Thus, the view that all strings always denote the
same value, regardless of datatyping context is
too simplistic. It may work in environments
where everyone "understands" what everyone else
means, but is too imprecise to base real comparisons
(or implications) on. This is the primary weakness
of ontologies such as DC or PRISM in that you
have no idea what you're actually going to get
as some property value, as they are all strings
(or non-typed literals). Your system logic may
be based on e.g. dates, but if you can't be sure
of the interpretation, then you can't be sure of
the results.

Thus, in your above example, your implication that
Fred is a redhead only is valid because there is
agreement and consistency that is external to both
the asserted knowledge and the implication. And
that agreement constitutes a datatype.

TDL neither helps that nor breaks that. It does,
however (as does S) allow your knowledge to be
expressed with greater precision.

> I'm pretty sure TDL undermines all
> the other rules and query systems out
> there (squish, RQL, etc.). I'm pretty
> sure it undermines common use of
> triplesMatching() APIs. All these
> things assume that "abc" denotes
> the same thing in all interpretations.

Then both TDL *and* S will break
such applications.

> I believe this argument is just an elaboration
> of why Sergey finds "untidy literals" in
> TDL graphs unacceptable.

I don't follow how tidy or untidy literals has anything
to do with this. The only attraction to tidy literals
is reduction of graph real estate. As far as I can tell,
the S proposal does not assert that the interpretation of
all identical literals is the same, only that a string
is a string is a string so if you are still able to provide
for the contextualized (and likely different) interpretations
of that string independent of the node for which it is a
label, why not just use the same node for that string.

Merging of literal labeled nodes in S does not assert the
same resource equality as merging of URI labeled nodes,
i.e. a literal labeled node does not denote a value such
that node equality can serve as a proxy for value equality
(right, Sergey?)

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, 28 January 2002 05:56:57 UTC