Axel Polleres / DERI / Co-chair
- 1 My input for the Feature discussion
- 1.1 AggregateFunctions
- 1.2 SubQueries
- 1.3 Update
- 1.4 Negation
- 1.5 ServiceDescription
- 1.6 PropertyPaths
- 1.7 FullText
- 1.8 ProjectExpressions
- 1.9 BasicFederatedQueries
- 1.10 LimitPerResource
- 1.11 SurfaceSyntax
- 1.12 SPARQL/OWL
- 1.13 Assignment
- 1.14 FunctionLibrary
- 1.15 AllNamedGraphs, Parameters, Composite Datasets
- 1.16 Parameterized Inference
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:
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.
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?
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
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?
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?
Question1: What would this involve?
Question2: How should we prioritize subfeatures?
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.
Seems to be worthwhile being discussed as an alternative for ProjectExpressions; there are several implementations.
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.
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.