Re: TDL conflicts with the "duh!" requirement

On Mon, 2002-01-28 at 04:57, Patrick Stickler wrote:
> On 2002-01-25 18:27, "ext Dan Connolly" <connolly@w3.org> wrote:
[...]
> > 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?

Yes.

> I don't see how it can anymore
> than TDL could.

Perhaps I misunderstood TDL. But S certainly
does license that inference.

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

quite.

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

Umm... I think I understand that; and I
think I agree.

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

I don't introduce "local typing for a literal".

I'm not sure what you mean by "local typing"
(is that covered in the desiderata somewhere?
Did I neglect to do some reading?)

I think you mean: the ability to talk about
things closely related to a literal syntactically-near
to the literal. I can do that just fine in S:

	<BunchOfBannanas>
	  <quantity s-a:decimal="30"/>
	</BunchOfBannanas>

> or global
> typing for the property, that implied typing
> disappears.

I'm not sure what you mean by "global typing".
I think perhaps you mean the ability to state
the range of a property once and use it many times.

I can do that just fine in S:

	<rdf:Property about="#quantityS">
	  <rdfs:range rdf:resource="...s-b#decimal"/>
	</rdf:Property>


	<BunchOfBannanas>
	  <quantityS>30</quantityS>
	</BunchOfBannanas>


It's true that S-A works better locally, and S-B works
better globally, and you have to choose one or support
both or whatever. This is an issue with S. But I find
it acceptable.


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

I can't make sense of that.

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

No, it's based on a design choice that whatever "111"
denotes, it denotes that same thing in all interpretations.

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

If you actually want the ability for "111" to denote one
thing in the ':Bilbo :age "111".' fact and another
in the rule, then you want a system that fails
the "duh!" requirement; i.e. a system that I find
unacceptable.


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

Nope. All I need to say is that "111" denotes
the same thing in all interpretation and
the inference follows.

> Thus, the view that all strings always denote the
> same value, regardless of datatyping context is
> too simplistic.

I disagree.

> It may work in environments
> where everyone "understands" what everyone else
> means, but is too imprecise to base real comparisons
> (or implications) on.

No, it is not.

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

I agree that there is some sloppiness in DC
and PRISM; in my experience, it's quite straightforwar
to refine/fix them with S.

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

Yes, the scalar datatype.

> TDL neither helps that nor breaks that.

I believe it does break it; I may be misunderstanding
TDL, but you clarified above that you want "111" to
be able to mean one thing in one place and something
else in another place. If that's the way TDL works,
then TDL breaks it.


> It does,
> however (as does S) allow your knowledge to be
> expressed with greater precision.

Nope.

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

Nope.

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

No, the attraction is that it licenses the relevant inferences.

> As far as I can tell,
> the S proposal does not assert that the interpretation of
> all identical literals is the same,

no? Hm... perhaps it's implicit.
http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0131/01-RDF_Datatyping.htm

I believe it is intended, though. Sergey, care to clarify?

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

I don't know how to make sense of that.

> Merging of literal labeled nodes in S does not assert the
> same resource equality as merging of URI labeled nodes,

yes, it does.

> i.e. a literal labeled node does not denote a value such
> that node equality can serve as a proxy for value equality

I don't know how to make sense of that.

> (right, Sergey?)
> 
> Patrick

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 28 January 2002 08:29:27 UTC