W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Additional text for SPARQL matching extensibility

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 20 Jan 2006 11:58:23 +0000
Message-ID: <43D0D05F.6040306@hp.com>
To: Bijan Parsia <bparsia@isr.umd.edu>
CC: Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

Bijan Parsia wrote:
> On Jan 19, 2006, at 2:59 PM, Pat Hayes wrote:
>>> It is also true that the current state of the deployed art, suitable 
>>> for standardization, is conjunctive abox query alone. There there is 
>>> a wealth of theory (see ian's and sergio's and enrico's (and others') 
>>> papers), several reasonably optimized implementations (Racer, Pellet, 
>>> KAON2, with Racer and KAON2 being commercial...I guess Cerebra also 
>>> does conjunctive abox query, and it is, of course, commercial, but 
>>> I'm not very familiar for it).  Oh, various subsets of OWL DL (e.g., 
>>> DL Lite) also fit this model. It would be nice to standards this 
>>> level so that we can get interoperability between the 4 query 
>>> implementation. (I imagine FaCT++ will have something soon).
>> I'm happy with that as sufficient justification for focussing on this 
>> case, but lets not call it 'OWL-DL', but something like OWL-Abox. 
>> Clearly, this case is not obtained just by doing "simple"//"OWL-DL" in 
>> the SPARQL definitions, with any wording of those definitions, so 
>> there is still some work to do or at least to check. I don't trust 
>> myself to be the judge for exactly how to couch the definitions to 
>> describe this case accurately. Can you do that?
> Sure. FUB can too :) What do we need for the current text? Or should we 
> put this in an appendix (or a WG submission?)
> Cheers,
> Bijan.

After considering what material to put in rq23 and how to record the 
discussions and conclusions in all the email, I propose that the interested 
parties prepare a separate WG note (or, alternatively, a member submission).

I will include some text that explains SPARQL at the level of simple 
entailment because the point of rq23 is to say what SPARQL/Q is, not what it 
might be.  It is confusing to have all the possible options outline when they 
don't apply to this version of SPARQL.

The only other thing I think we might consider is an appendix that expands on 
the definitions section but again I think it should stick to what this SPARQL is.

There a lot to be said for a separate document in that it can evolve 
independently of rq23 (and the rec track process).

Received on Friday, 20 January 2006 11:58:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC