User:Axel Polleres

From SPARQL Working Group
Revision as of 11:55, 6 May 2009 by Apollere2 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Axel Polleres / DERI / Co-chair

Introduction


My input for the Feature discussion

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) along with some questions:

AggregateFunctions

no questions

SubQueries

no questions

Update

no questions

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.

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
  • supported extension functions (which are not standardized)

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

PropertyPaths

no questions

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

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?


BasicFederatedQueries

no questions


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?

SurfaceSyntax

Question1: What would this involve?

Question2: How should we prioritize subfeatures?

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.

Assignment

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


FunctionLibrary

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


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.

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.