W3C home > Mailing lists > Public > www-rdf-rules@w3.org > January 2004

Some (v. late) Comments on the RDF Data Access Charter

From: Brian McBride <brian.mcbride@hp.com>
Date: Mon, 5 Jan 2004 16:33:46 -0000
To: <eric@w3.org>, <www-rdf-rules@w3.org>
Message-ID: <NHENIIFPBIIGLIEEKIDAOEACCAAA.brian.mcbride@hp.com>

I have finally found some time to take a look over the RDF data access
charter [1].  I realise these comments are very late, but am sending them in
case they might still be useful.

1.  The charter states that the principal task of the WG is to define a
protocol for subgraph selection.  One of the justifications for this WG is
that there a number of RDF query languages about and now is a good time to
standardize.  Whilst my knowledge is somewhat limited, my understanding is
that many of the existing query languages focus on variable binding result
sets rather than query subgraph extraction, which makes me wonder why this
restriction is placed in the charter.

I appreciate there is a tricky balance between specifying a job the WG can
do in a reasonable time and giving the WG design freedom, but it strikes me
that perhaps the form of results required is something the WG might decide
based on its requirements.

2.  Whilst section states that the principal task of the WG is to define a
protocol, much (all?) of the emphasis of the rest of the document is on a
query language.  As written the charter might be interpretted as implying
that the protocol and query language are tightly bound together.  I suggest
rewording to encourage the working group to adopt a modular design approach,
separating the protocol, language design and result encoding.


3. 1.1

There should either also be a Protocol requirements document or a joint
document covering both language and and protocol requirements.

4. 1.3

The idea of an abstract syntax is an excellent one.  In an analagous manner,
I suggest similar benefits acrue from defining a protocol abstraction which
can then be bound to various underlying protocol layers, a practice, adopted
I believe by the XML protocol WG.  Oh, that reminds me, section 1 should say
XML protocol, not SOAP, right?

5.  1.5 Relationship to XQuery

The relationship to XQuery is important, however, I'm uncomfortable with the
way the charter addresses this.

I suggest that the WG should be required to "account for the relationship
between RDF data access and XML Query" and the WG should be encouraged
re-use XML Query and other W3C technologies where appropriate.

I am concerned that requiring the WG to produce a translation for RDF data
access query language abstract syntax to XML Query may requiring the WG to
take on a task that is not essential to its principal task and may thus slow
down its completion of that task.

6. 1.6 Extensibility Mechanism

I suspect this is just a picky wordsmithing point.  To talk about an
extensibility mechanism is to suggest that the WG should seek a single
mechanism to support extensibility.  I think what the charter is trying to
say is that the WG is strongly encouraged to produce a design that a) allows
for extensability and b) allows multiple extensions to be adopted
simulataneously.

What the current document does not say, though perhaps implies, is that the
WG is encouraged not to try to "boil the ocean", but to limit its work
defining a 'small' design that can be extended to support additional
requirements.  The WG might be encouraged to classify its requirements into
'core' and 'extension'.

7. 1.7 Defined expressivity

I'm not sure what this is trying to say.  It says the WG will have to make
tradeoffs.  Sure.  Is the charter trying to express some guidance to the WG
about how to make those tradeoffs?

8. 1.8 Derived Graphs

Again, I'm not sure why this is here.  Yes, some RDF graphs are infinite.
This is bound to come out in the requirements.  Is there something special
about this requirement the means it needs special mention in the charter.
If so, I didn't understand the significance from the current text.

9. 2.1 RDF Schema/Owl semantics

This states that the fact that a graph is virtual (i.e. derived from
inference) does not affect the protocol.  Is this intended to state that it
should not affect the query language either, i.e. you can't say things like
"find me all the ground facts such that ..."?

10. RDF Rules

"will be useful in the later ..."

This implies that the rules WG wills start after/later than the Query WG.
Is that still the case?

"is not expected to develop such a language"

That is weak language.  "Development of a rules language is out of scope for
this WG".  Is there a clear boundary between rules and query?

"the groups should ..."

This implies the groups are operating simultaneously.

"expend minimal effort"

That feels weak.  Is there a charter requirement that query and rules should
work together or not?

Does the statement under 1.5 Relationship with XQuery also apply here.  The
WG's are strongly encouraged to support/use each others stuff, but exactly
what that means in practice will only become clear as the work progresses.

11 2.3 Cursors and Proofs.

I'm not sure what is meant by cursors here.  It could mean that the variable
binding functionality of say, Squish is out of scope, or it could be that
session state between client and server is not supported.  I've commented on
the former in section 1.  I'm not sure why the latter is ruled out of scope
by the charter, even though I'm sympathetic to it being so. I wonder whether
a general guideline of "keep it simple" and "don't boil the ocean" is
sufficient discouragement that the WG can be relied on to do the right thing
based on what it learns about requirements.

12 3. Deliverables and schedule

The deliverables are not clearly listed.

Phase 1 Deliverables:

  - protocol requirements, including what bindings will be specified in
phase 2.
  - Query language requirements
  - An account of the relationship of the Query language to XML Query
  - An account of the relationship of the Query language to RDF rules
  - revised schedule

Requirements may indicate specific non requirements and postponed
requirements.

Phase 2 Protocol Deliverables:

  - an abstract protocol specification

At least one of (depending on requirements):

  - a binding of the abstract protocol to HTTP
  - a binding of the abstract protocol to XML Protocol

Phase 2 Query language Deliverables:

  - an abstract syntax for the query language
  - at least one concrete syntax for the query language
  - semantics of the query language, i.e. a specification of the results
that should be produced for any query against any graph
  - test cases for the query langauge.  These are not expected to be a
complete conformance test suite, but are expected to illustrate key aspects
of the design, to be machine processable and to be a useful indication that
compatible implementations exist at the request for PR.
  - a list of postponed issues
  - a *small* introductory primer
  - a validator?

The WG is free to organise these deliverables into documents as it sees fit.
The WG should consider the use of mathematical methods for specifying the
semantics and should bear in mind both the benefits and the costs of the
approach its adopts.

12 4. Relationship with other W3C activities

- I18N should be mentioned here.  The WG should be strongly encouraged to
establish an internal champion for internationalization issues who should
be/come an expert in internationalization issues, liase on a regular basis
with the I18N folks and champion internationalization concerns within the
WG.

- QA might be mentioned here.  Similar to I18N, the WG might be encouraged
to establish someone to liase with the QA folks and champion QA issues
within the WG.

13. 5.1 Email communication

does the charter need to specify the mailing list used?  Is www-rdf-rules
appropriate?  What will the rules working group use?  Ah, the same one -
that might be a good idea.  This is not the natural list to look at for
query discussion.  I think the RDFCore organization worked well from my
point of view.  I'd like hear whether folks not on the WG felt we were/are
too isolated.

RDFCore generated a lot of traffic on ocasions - I'm not sure folks on the
general lists really want all that stuff in their inbox.  Similarly, wider
discussion can get pretty fierce and undiscipined too, e.g. the tag list.
I'd suggest giving the WG(s) a public list of their own for technical
discussion.

I'd suggest:

  - www-rdf-da-wg a public list for WG admin/technical discussion
  - www-rdf-da-comment a public comments list for formal communication with
the WG

14. 5.4 Face-to-Face Meetings

RDFCore didn't have enough f2f meetings.  I wonder if every three months
might be appropriate.

I'm wondering about the chair inviting observers to 'participate in decision
making'.  Is there a rationale for this.

That's it on a quick read, apart from the timescale.  The requirements will
be settled at a f2f in June, thats probably the end of June.  Can there be a
WD by the end of August, given holidays etc.  Yes, if the there is a good
enough starting point for whatever strawman is selected.  Its impossible to
accurately estimate the development time, but what we have here looks
impossibly tight to me.  The schedule from last call to REC also looks
incredible to me.  I don't think this can be done in a year and its only
fair on folks who join to give them a reasonable estimate of the commitment
they are making.

Brian

[1] http://www.w3.org/2003/10/RDF-Query-Charter
$Id: RDF-Query-Charter.html,v 1.25 2003/12/01 16:59:18 eric Exp $
Received on Monday, 5 January 2004 11:49:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:15 UTC