Re: SeRQL an RDF rule language: scoping Rules vs Query in W3C work

I agree with Jeen's points below.

To add my own 2 cents, I'd also like to see query and rules solutions
for RDF expressed *in* RDF. This allows one to combine into a single
request graph any combination of queries, auxilliary data, and inference
rules to be applied in conjunction to the knowledge managed by the
server.

C.f. http://sw.nokia.com/rdfq/RDFQ.html

It also alleviates the need to learn/parse/support yet another syntax,
and allows one to reason about queries and rules just like any other
knowledge expressed in RDF.

With regards to query and rules solutions, the RDF community really
should eat its own dog food.

I also think it is important to separate the needs of knowledge
discovery from those of knowledge management and knowledge manipulation.
The latter typically need special knowledge about server internals
(specific models, tables, databases, files, etc.) which precludes
easy access by arbitrary agents. Certainly such internal knowledge
is necessary for management and manipulation, and RDF APIs will need
to provide a far richer set of functionality than is needed for
discovery, but whatever standards emerge, they should require
special server-specific knowledge to support basic discovery.

Cheers,

Patrick


On 2003-11-04 13:07, "ext Jeen Broekstra" <jeen@aduna.biz> wrote:

> 
> Dan Brickley wrote:
> 
>> Within W3C, we're looking into phase 2 of the Semantic Web
>> activity.
>> 
>> In terms of possible new technology areas, 'Rules' and 'Query'
>> are two topics for recommendation-track work.
>> 
>> So I'm looking at
>> http://sesame.aidministrator.nl/publications/users/ch05s06.html
>> with some interest. The CONSTRUCT mechanism appears to provide a
>> bridge between the world of RDF query systems and RDF-based rule
>> systems.
>> 
>> CONSTRUCT {Artist} <rdf:type> {<art:Painter>}; <art:hasPainted>
>> {Painting} FROM {Artist} <rdf:type> {<art:Artist>};
>> <art:hasCreated> {Painting} <rdf:type> {<art:Painting>}
>> 
>> 
>> In this light, do folks on these lists think it is sustainable to
>>  maintain that there's an interesting distinction still to be
>> made between work on RDF 'query' languages vs 'rules' languages.
> 
> Allow me to make some broad, sweeping statements :)
> 
> My gut reaction is that although the technologies are very similar,
> the use cases are different. This may reflect on requirements for
> ease of use, expressiveness and syntax.
> 
> We are ourselves not really fixed on a particular QL syntax, but in
> developing SeRQL we have deliberately tried to take away some of the
> pains developers were having with the RQL syntax (which was
> sometimes difficult for users to understand) and have taken special
> care to come up with a syntax that was easy to use, extensible and
> expressive (as well as easy to implement a parser for). Syntax is
> not a trivial issue from a usability perspective, and this may well
> be the main distinguishing factor between a rule language and a
> query language.
> 
>> Can folks here imagine a workable W3C RDF Query WG constrained
>> not to get into Rules WG territory, but to maximise compatibility
>> with a (future? parallel) Working Group on Rule languages for
>> RDF? Or are the two technology areas too close?
> 
> It would be hard to envisage a usable (expressive enough) RDF query
> language that does not at least partially intrude on rules
> territory: after all, a query is generally speaking just a rule
> without a head. In requirements for expressivity, operations, and
> tranformation possiblities I would imagine that any W3C-endorsed
> query language would support a subset of the operations a rule
> language supports. I say subset because, IMHO, things like validity
> constraints and negative conclusions ("given X and Y, Z must be
> false") are outside the scope of a query language (I'm sure at least
> some of you disagree here, though ;)).
> 
> The question to my mind is whether a common syntax format can be
> found that satisfies the two user communities (and note that this is
> a simplification: there is no single QL user community but many
> different agendas - as reflected by the plethora of QL proposals out
> there - and I imagine the same is true for rules).
> 
> In my opinion, a good place to start investigating the
> viability/usefulness of seperate specs is not so much looking at the
> technology, but looking at use cases. Wouldn't it be a good idea to
> collect use cases for both queries and rules (and document the
> requirements they pose on expressivity and syntax), and then see how
> great the overlap is from that perspective?
> 
> Just my two cents,
> 
> Jeen

Received on Tuesday, 4 November 2003 06:45:02 UTC