W3C home > Mailing lists > Public > www-rdf-rules@w3.org > November 2001

Re: Scope

From: Geoff Chappell <geoff@sover.net>
Date: Wed, 14 Nov 2001 10:24:02 -0500
Message-ID: <003b01c16d20$646ed250$0400a8c0@GSC866>
To: "Dan Brickley" <danbri@w3.org>, "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: "Libby Miller \(E-mail\)" <Libby.Miller@bristol.ac.uk>, <www-rdf-rules@w3.org>
I'm all for it.  My only concern is that we recognize that systems of
varying capabilities might be answering the queries and we allow for it or
explicitly limit the scope of the language. Possibly this just means having
explicit vocab (for example, so 'not' never means different things to
different systems we use 'not' and 'not_known'). A system could support a
particular vocabulary item or not.

What are the likely features of the query language? which of these should it
1. query
2. assert/insert
3. retract/delete
4. functions
5. logical ops (and, or, not, not_known, exists, known)
6. aggregation functions
7. rules
8. variable quantification
9. ...

How about the features of the results language?
1. results as tabular variable bindings
2. results as triples/rdf
3. other results - i.e  messages, warning, errors

Is the expectation that implementations would alter their native syntax or
that we'd define a common, easily parsable syntax that we could all map
into? the later might be easier - especially if it means we could go light
on the human useability concerns (i.e. use an ugly syntax like
and(and(or({}... )


----- Original Message -----
From: "Dan Brickley" <danbri@w3.org>
To: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: "'Geoff Chappell'" <geoff@sover.net>; "Libby Miller (E-mail)"
<Libby.Miller@bristol.ac.uk>; <www-rdf-rules@w3.org>
Sent: Wednesday, November 14, 2001 8:57 AM
Subject: RE: Scope

> On Wed, 14 Nov 2001, Seaborne, Andy wrote:
> > Geoff,
> >
> > The style I would suggest is one of many small steps - trying to get a
> > regular flow of useful output, both so that everyone is informed and to
> > implementers try out the ideas.  We could start with requirements
> > and use case examples.  This would also draw on previous and related
> >
> > As to the scope of the work, it is what the people involved make of it.
> > would like to see a framework in which query capabilities fit - not a
> > set of funconality that every system must implement to be conformant.
> Yes, we're definitely in "what we make of it" territory. Rather than
> launch a big RDF Query (and/or Rules) formal Working Group, we've decided
> to take a different approach for the time being. The www-rdf-rules list is
> here so that implementors can find out more about each other's systems,
> specifications, working assumptions... I've a hunch that a very limited,
> bare bones RDF query language could form the basis for some early interop
> testing amongst existing systems. One lesson I'd like to learn from this
> is how the limitations of such languages relate to practical use cases,
> and where the complexity/shippability tradeoffs lie. It'll certainly be
> more fun exploring this in the context of an Interest Group than in a
> Working Group, I think. Once we've got a better sense for the options
> available, I'd like to start discussions that are more explicitly about
> chartering of a proper Working Group in this area...
> Dan
> RDF Interest Group chair
> --
> mailto:danbri@w3.org
> http://www.w3.org/People/DanBri/
Received on Wednesday, 14 November 2001 10:28:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:14 UTC