Re: Lee's feature proposal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some comments:

> 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. 

I agree with your rationale, it could be specified using OPTIONAL, !BOUND and a
couple of new variables. However, this might be a bit complicated to subsume
under surface syntax.

> 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)

Yes!

>     * Used entailment regime/inference 
> 
> Question2: Who would see other sub-features here? Question3: (How) should we prioritize these sub-features? 

Every feature we define should get a URI.

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

No, as fulltext search should be allowed to bind variables.

> Seems to be redundant with respect to Assignment.
> 
> Question1: Would Assignment add more expressivity/be harder to implement? 

Assignment can lead to some problems, e.g.
LET a = b+1. LET b=a+1.
I am quite sure, one can get around such problems with a proper definition.
Particularly in the above example, there is no grounding of assignments in BGPs.

However, I think assignment make queries more readable than ProjectExpressions +
ScalarExpressionsInConstruct + ScalarExpressionsInTriplePatterns.

Cheers,
Simon

Axel Polleres schrieb:
> 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.
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoAQoIACgkQQ0Lz1fXAQeN9RgCcDn6q7VbdsFBRGx7Osk70IS90
POkAn1NyF7lYOocfrOmfrm76e0fazYvX
=rGb8
-----END PGP SIGNATURE-----

Received on Tuesday, 5 May 2009 13:44:18 UTC