Re: Comments on datatypes and query

On 2002-01-31 13:24, "ext Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
wrote:

>> We seem, though, to be in agreement on that.
> 
> Yes - I think  are :-)

Cool.

>> The issue was not whether "abc" is string equal to "abc"
>> but whether (as Dan suggests) "abc" always means the same
>> thing (has consistent global semantics) in all contexts
>> regardless of datatype.
> 
> This is a trivial aside so I haven't sent it to RDF comments, which isn't a
> discussion group.
> 
> I'll take the concrete approach on this: RDQL queries current data in (my
> understanding of) current RDF meaning.  Literals are strings.
> 
> There really isn't enough RDF data or RDF systems out there to be overly
> hindered by legacy.  If "old code, old data" works, then we're OK.  "Old
> code, new data" breaks in all cases I have seen.

I agree. There seems to be the presumption that KR applications
based on RDF 1.0 where a literal is a literal is a literal are
doing things "the right way" in terms of KR queries because they
are doing things the way RDF 1.0 says.

The painful fact, is that we all are going to have to re-tool to
a certian degree to deal with values rather than literal strings.

And only by working with values that are identifyable by typing
knowledge in the RDF graph are we going to achieve global
interoperability.

> And also, the datatype
> changes will mean API changes to get an application view point of (S, P,
> (DT, value)).

Yup.
 
> Right - off to do your "take 2" tests ...

I look forward to your results/comments.

Cheers,

Patrick
 
> Andy
> 
> -----Original Message-----
> From: Patrick Stickler [mailto:patrick.stickler@nokia.com]
> Sent: 31 January 2002 08:06
> To: ext Seaborne, Andy; RDF Comments
> Subject: Re: Comments on datatypes and query
> 
> 
> On 2002-01-30 17:36, "ext Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
> wrote:
> 
>> In [1] Dan Connolly wrote:
>> 
>>> But as Sergey and I pointed out, there seem to be a lot
>>> of RDF query engines and such deployed that consider
>>> "abc" a match for "abc".
>> 
>> RDQL, the query systems in Jena and which implements SquishQL, does indeed
>> consider "abc" as a match for "abc".
> 
> The issue was not whether "abc" is string equal to "abc"
> but whether (as Dan suggests) "abc" always means the same
> thing (has consistent global semantics) in all contexts
> regardless of datatype.
> 
> If there is rdfs:range defined knowledge about the datatype
> of a literal, that must be taken into account for queries
> where the intent is a comparison of values, rather than
> just a comparison of strings.
> 
>> Patrick Stickler wrote:
>> 
>>> Of course, I would expect that a query API would be
>>> based on an abstraction of the "raw" RDF graph, which
>>> takes datatype context into account, so that a query
>>> such as above would not be based on string comparison
>>> of literals, but on comparison of TDL pairings
>>> (lexical form + datatype).
>> 
>> When RDF gets datatypes, then I would be planning on doing a new query
>> language (or changing the old one) which worked over the new, improved
>> datatyped literals.  The datatyping may not break APIs which work at the
>> details of the graph but there again, it is no longer what the application
>> writer would like (IMHO).  Now, queries would be over what the application
>> thinks in terms of and I don't think that will be the details of the graph
>> encoding for types so I would be aiming for syntactic forms at least to
>> avoid this.  
> 
> Sounds like the right way to go (that's what I plan to do ;-)
> 
>> What is hard is if there are 2+ ways to encode the same thing (in the
>> application writers frame).
> 
> This is a very important point. Usability (or even simply perception
> about ease of use) as it relates to adoption should not be underestimated.
> 
> RDF is it great need of some coherence and consistency in this regard.
> We don't want a solution that adds (needlessly) to the variability of
> expression simply to accomodate everyone's personal tastes.
> 
>> If the query system has to be aware that the
>> information could be in one of more local idioms and/or a global idiom
> then
>> it is going to be tedious; having the application writers have to be aware
>> of this is worse.  Queries will be really ugly and might mean having
> general
>> disjunction in the pattern matching which then opens up the possibility of
>> undefined variables.
> 
> Well, I agree that multiple idioms makes the job of writing a query API
> more challenging, but I don't see how we can avoid having at least two
> idioms (one for local/explicit typing and one for global/implicit typing),
> and we at least have the consolation that the queries themselves, if
> expressed in terms of the more abstract layer, need not worry about such
> multiple idiomatic expressions in the underlying graph (unless the user
> wishes to).
> 
>> The current situation, no type information, isn't so bad because it is
> clear
>> what the rules of the game are.  Datatyping would improve the robustness
> of
>> queries, avoid the occasional unexpected result, help storage and
>> efficiency.
> 
> The problem with no datatyping is that it precludes (or greatly complicates)
> system interoperability and portability of data because application
> semantics must be added into the mix in order to achieve a consistent
> interpretation of the graph. Having the intended datatyping expressed in
> RDF allows that graph to be application independent and further allows
> multiple graphs to be syndicated without as much risk of contradiction
> or ambiguity. A literals-only approach will only work well in a closed
> system environment and won't help us achieve a global semantic web
> of knowledge.
> 
> Granted, to date, folks have had to make do without literal datatyping
> expressed in RDF, but I don't think that will work if we are to move
> forward to "bigger and better things".
> 
> We seem, though, to be in agreement on that.
> 
> Cheers,
> 
> Patrick
> 
> --
>              
> Patrick Stickler              Phone: +358 50 483 9453
> Senior Research Scientist     Fax:   +358 7180 35409
> Nokia Research Center         Email: patrick.stickler@nokia.com
> 
> 

--
               
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 06:55:39 UTC