Re: SEP - Some technical areas

On Oct 27, 2019, at 3:58 AM, Andy Seaborne <andy@apache.org> wrote:
> 
> == Functions
> 
> #6    Function call - algorithms and indexes.
> #64   Named arguments for SPARQL functions
> #20   Dynamic function invocation
> 
> If the function area is defined, access to e.g. graph analytics algorithms, or specialized indexing has a common basis.

I came to similar conclusions on the most likely starting points for SEP work. In particular, I think there's a lot of value to be had by working on syntax and semantics for functions (or function-like operators) that can return multiple values:

#6  Keyword for functions that can produce multiple bindings

(This could be impacted by any proposed update to the data model to better support lists.)

Having the ability to produce multiple bindings from a function call would directly impact/enables these issues:

#10  Generalize SERVICE for non-SPARQL endpoints
#14  better string split
#40  Standardize free text search of RDF data
#46  SPARQL-friendly lists


There's also quite a bit of focus on improvements to functions, the function library, and extensibility of functions/aggregates:

[function call syntax]
#20  Dynamic function invocation
#64  Named argument for SPARQL functions
#66  Allow optional function arguments to be unbound

[new functions]
#32  Arithmetic operators for durations, dates, and times
#55  Support for XPath and XQuery Functions and Operators 3.1
#85  String matching using wildcards
#97  Should the XPath 3.1 functions be inbuild or included in the grammar?

I'm not sure how granular we want SEPs to be (particularly in relation to additions to the functions library), but I think each of the three areas above could be a good starting place for proposals.


> Two areas that seem to have wide appeal.
> 
> == Property Paths
> 
> #101  Property paths
> #99   Predicates in property paths
> #65   Allow use of variables in property paths
> 
> == Protocol and Result Sets
> 
> #51   Paging and partial result errors.
> #49   Paging and cursors
> #7    Async queries.


Agreed that there seems to be a lot of interest/issues relating to the Protocol (with some overlap with Query and Service Description). I think all of the issues below touch on Protocol. However, I'm not sure I see a lot of overlap between them so they might not be ideal to *start* the SEP process.

#7  Asynchronous SPARQL
#27  A minimal protocol for all services
#28  Extended the protocol for errors in federated queries
#29  Extended the protocol in order to building IRIs' autocompletion, via keywords/text research
#30   Protocol to access the logs of SPARQL queries
#49  Database Cursors / keyset pagination
#51  standardized communication of partial results
#57  Query Parameterization
#61  Standard graph name for example queries
#70  Ability to use default PREFIX values
#79  Mandatory support for RDF formats for DESCRIBE and CONSTRUCT 11
#80  Mandatory support for RDF formats for Graph Store HTTP Protocol 3
#83  Multi-request transaction support in the SPARQL protocol
#84  WebSocket SPARQL Protocol
#91  Extend SPARQL Protocol to allow limit and offset as query string parameters


thanks,
.greg

Received on Thursday, 7 November 2019 22:49:58 UTC