Re: Lee's feature proposal

Let me join the choir to thank Lee for his initial proposal which raised 
a lot of useful discussions IMO.

I tried to summarize the pending questions which I got out of these and 
out of my own observations at
 
http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres#My_input_for_the_Feature_discussion

and would like to go through those questions as an input to the further 
feature discussion in the f2f 1st day morning session.

More input/discussion welcome!

Axel


=======================================================================

Let me try some complement Lee's proposal by listing all those features 
up to SPARQL/OWL (which was discussed a lot and seems to be a natural 
threshold point following the Condorcet graph at 
http://plugin.org.uk/misc/votes.svg) along with some questions:


[edit] AggregateFunctions

no questions

[edit] SubQueries

no questions

[edit] Update

no questions

[edit] Negation

Question: For those arguing strongly for it? Would you be fine with 
seeing this as part of surface syntax?

Rationale: I think it is easy enough to specify, but strictly speaking, 
a redundant feature.

[edit] ServiceDescription

This seems to be widely agreed, but...

Question1: What does this involve? I recall/saw the following things 
being discussed:

     * Description of the dataset (used vocabulary, etc.)
     * Statistics on the dataset (e.g. selectivity, distribution, etc. 
to help optimizers)
     * Used entailment regime/inference

Question2: Who would see other sub-features here? Question3: (How) 
should we prioritize these sub-features?

[edit] PropertyPaths

no questions

[edit] FullText

Question: Is a surface syntax for regular expression sufficient, or at 
least could we reach consensus on treating only that?

cf. Kjetil's advocacy mail, Andy's comment on Axel's question

[edit] ProjectExpressions

Seems to be redundant with respect to Assignment.

Question1: Would Assignment add more expressivity/be harder to implement?

Question2: We have a "Don't" want for Assignment by Steve. Can you 
elaborate again on that?


[edit] BasicFederatedQueries

no questions


[edit] LimitPerResource

Seemed to be ok to the members who champoined that this is dropped if we 
have subqueries.

Question: would we would want to allow extra surface syntax if surface 
syntax was being worked on?

[edit] SurfaceSyntax

Question1: What would this involve?

Question2: How should we prioritize subfeatures?

[edit] SPARQL/OWL

It seems to me that the discussion indicates that not only one 
entailment regime is being talked about and that several people want 
also and particularly lower entailment regimes being defined/definable 
(e.g. as part of service descriptions).

Question: Is this really only about OWL or should we define several 
(gradual) entailment regimes? (e.g. RDFS, D, OWL RL, OWL QL, OWL DL, RIF?)

I am personally leaning towards calling this more general "Entailment 
Regimes for SPARQL" than specifically SPARQL/OWL given the discussion so 
far. In the last telecon an entailment regime for RIF rulesets was 
mentioned which I'd be happy to volunteer to work on. Given the prework 
done in RIF, I view the work for SPARQL/RIF equally feasible as 
SPARQL/OWL and it would be a good signal to have interoperability with both.

[edit] Assignment

Seems to be worthwhile being discussed as an alternative for 
ProjectExpressions; there are several implementations.

[edit] FunctionLibrary

Question: What is the scope? Can we narrow the scope to commonly added 
functions in existing implementations here?


[edit] AllNamedGraphs, Parameters, Composite Datasets

I didn't see a strong discussion about these but at least according to 
Condorcet they seemed to have considerable support? I guess if someone 
wants to champion/push these strongly, they should start now, otherwise, 
I would be inclined to drop these, even if I miss them for interesting 
use cases.

[edit] Parameterized Inference

While advertising supported inference (part of Service Description) was 
mentioned from several sides, the majority of the group seems to see 
parameterizing inference on the query side too tricky to deal with at 
this point. I can live with dropping this and all below.

Received on Monday, 4 May 2009 22:29:50 UTC