OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [search-ws] Relationship of CQL to SPARQL/SQL?



> I don't have any wisdom to contribute on this.  CQL is about as far away
> from SPARQL as it is from SQL.  They are completely different searching
> paradigms.

Sure. SQL is well known. SPARQL is becoming known. CQL is unknown.

> On the other hand, CQL and the Lucene Query Language are reasonably
> close.  I've not done any comprehensive analysis of the two, but I've

Yes they are both bib record query languages. (Maybe the bib record
corresponds to a named graph in SPARQL queries, i.e. a higher level
construct?)

My point, anyway, was how to position CQL within the structured query
universe? Back in Z39.50 days the transactional unit was the record. With
the Web we are now beginning to address down to the individual data item
(via a URI). Why should anybody look at CQL? Where's the elevator pitch for
CQL?

Tony


On 25/1/10 18:45, "LeVan,Ralph" <levan@oclc.org> wrote:

> I don't have any wisdom to contribute on this.  CQL is about as far away
> from SPARQL as it is from SQL.  They are completely different searching
> paradigms.
> 
> On the other hand, CQL and the Lucene Query Language are reasonably
> close.  I've not done any comprehensive analysis of the two, but I've
> been able to write some simple translators from CQL to Lucene for my SRW
> server.
> 
> Ralph
> 
>> -----Original Message-----
>> From: Hammond, Tony [mailto:t.hammond@nature.com]
>> Sent: Monday, January 25, 2010 12:15 PM
>> To: OASIS SWS TC
>> Subject: [search-ws] Relationship of CQL to SPARQL/SQL?
>> 
>> Hi:
>> 
>> One thing I wanted to bring up here was whether there should (or
> could) be
>> some kind of scoping note (either within the spec as an informational
> annex)
>> or somewhere else readily accessible (website?, paper?) that would
> relate
>> CQL to other well-known query initiatives - specifically SPARQL and
> SQL.
>> 
>> This message (dated 2008-04-10, and cc'ed below for convenience) from
>> MacKenzie Smith which quotes Rob Sanderson
>> 
>> https://simile.mit.edu/mail/ReadMsg?listName=Dev&msgId=25018
>> 
>> seems to provide a good starting point.
>> 
>> I, for one, could really do with some help in clarifying the role that
> CQL
>> has to play in searching bib records in a world that is now
> increasingly
>> atomizing to the datum level (cf. recent releases of data.gov.uk and
> earlier
>> data.gov) and is turning towards semantic solutions (SPARQL) as the ne
> plus
>> ultra having relied previously upon the relational model (SQL).
>> 
>> Are bib records really that different from data? Some kind of document
> to
>> set the context for the current work could be really helpful. Maybe
> its just
>> the level of granularity supported by bib apps that makes them
> qualitatively
>> different? And then besides bib vs data, there's also bib vs bib, e.g.
> How
>> does CQL stack up against Lucene/SOLR, etc?
>> 
>> Does that make any sense?
>> 
>> Cheers,
>> 
>> Tony
>> 
>> 
>> ===
>> Hi Kjetil,
>> 
>> I took the liberty of asking Rob Sanderson from the SRU technical
>> committee about this,
>> and here are his comments:
>> 
>> "The CQL <--> SPARQL Mapping question has come up (quite a while ago
> now)
>> and more commonly CQL <--> SQL.
>> 
>> The main challenge in any CQL <--> SPARQL mapping is the different
>> things which the languages consider atomic.  SPARQL works at the rdf
>> triple level, whereas CQL assumes that there is some record or item
>> which contains information.  Normally you would want to model items as
> a
>> [named] graph of triples, so there's some discrepancy in what the
>> queries should return.
>> 
>> In CQL <--> SQL it's a similar problem, in that the result of an SQL
>> query is a table not zero or more items, but it's easier to turn a
> table
>> into XML than a set of RDF triples.
>> 
>> Secondly, CQL doesn't have the concept of variables, as there aren't
>> relationships to follow.  So while in SPARQL you can do clever things
>> like 'find all authors who have co-authored with someone who has
> written
>> a book that has "information" in the title', in CQL the context of
> each
>> sub-query isn't carried over to the rest of the query.
>> 
>> A mapping would at least require some definition of what an 'item' (or
>> 'record') is from the matching graph. In the named graph world view
> this
>> is easier, as the trivial mapping would be record == named graph, but
> in
>> the all-triples-stand-alone view, it becomes rather arbitrary."
>> 
>> 
>> Rob is happy to give this more thought if there's interest, and he can
>> be found at
>> [email hidden]
>> 
>> MacKenzie
>> ===
>> 
>> 
>> 
> ************************************************************************
> ********
>> DISCLAIMER: This e-mail is confidential and should not be used by
> anyone who
>> is
>> not the original intended recipient. If you have received this e-mail
> in error
>> please inform the sender and delete it from your mailbox or any other
> storage
>> mechanism. Neither Macmillan Publishers Limited nor any of its agents
> accept
>> liability for any statements made which are clearly the sender's own
> and not
>> expressly made on behalf of Macmillan Publishers Limited or one of its
> agents.
>> Please note that neither Macmillan Publishers Limited nor any of its
> agents
>> accept any responsibility for viruses that may be contained in this
> e-mail or
>> its attachments and it is your responsibility to scan the e-mail and
>> attachments (if any). No contracts may be concluded on behalf of
> Macmillan
>> Publishers Limited or its agents by means of e-mail communication.
> Macmillan
>> Publishers Limited Registered in England and Wales with registered
> number
>> 785998
>> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>> 
> ************************************************************************
> ********
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> 
> 
> 


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]