W3C home > Mailing lists > Public > public-sparql-12@w3.org > April 2019

Re: RDF*/SPARQL* extension

From: Axel Polleres <axel.polleres@wu.ac.at>
Date: Mon, 1 Apr 2019 16:11:39 +0200
To: public-sparql-12@w3.org
Message-Id: <56EB928E-74D8-47FC-84C1-CAC03A360263@wu.ac.at>
(]re-send to public list)

wishlist (from the top of my head):

* reconsider postponed issues, whether which still are relevant, currently seeing two here https://www.w3.org/2009/sparql/wiki/Postponed_Issues 

* we had another list of postponed features somewhere (apologies if that had been posted already, just joined the CG over the weekend only :-)), but I don't find them re-collected at the moment, e.g.
  Full Text Search https://www.w3.org/2009/sparql/wiki/Feature:FullText

* means to do regular path queries, i.e. returnin the matching (or k-shortest) paths for a graph pattern. 

* means to query some form of reified graphs/property graphs (PGs), and agree to which RDF representation of PGs to support there, e.g. singleton properties or, resp. blanknodes in Property positions (note: allowing the latter would affect RDF, yes)

* graph algorithms, such as node centrality would also be interesting to discuss

* full-text search (postponed in SPARQL1.1)



--
Prof. Dr. Axel Polleres
Institute for Information Business, WU Vienna
url: http://www.polleres.net/  twitter: @AxelPolleres

> On 01.04.2019, at 14:11, Jörn Hees <joern.hees@dfki.de> wrote:
> 
> Hi,
> 
>> On 1 Apr 2019, at 13:44, Jerven Bolleman <jerven.bolleman@sib.swiss> wrote:
>> 
>> I second the idea of starting of with the wish lists.
> 
> i'd have 3 additions for such a wish list as well:
> - allow FROM  { CONSTRUCT ... } (so the ability to define a virtual graph in form of a construct sub-query in the FROM / FROM NAMED clause)
> - standardization of how partial results (e.g., virtuoso anytime feature in case (implicit) timeouts are reached) are communicated (probably also related to window functions)
> - datatype and language agnostic literal matches (e.g., something like a "Berlin"* matching a literal of any datatype and language. It's a common exploration case to do something like { ?s ?p ?l . FILTER(str(?l)="Berlin")) }, but most endpoints don't seem to be able to do this in reasonable time (O(1) or O(log(n)).
> 
> Best,
> Jörn
> 
> 
Received on Monday, 1 April 2019 14:12:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 1 April 2019 14:12:07 UTC