Re: SPARQL Wishlist

+1 for STREAM support could be something in the context of big data, IOT or
LDF, probably
+1 for introducing turtle syntax in WHERE: I often start from existing
turtle examples when explaining how to construct the WHERE part of SPARQL
to beginners, it could be useful to move over the idea of a "matching
language", in a sense
+1 for registering UDF, which is something that actually lacks from the
general specification. It could be great to have things such as the
vendor-specific implementations registered under available custom
namespaces and being able to use them with a general purpose name. In that
perspective I like the "decoupled" approach by blazegraph introducing a
SERVICE for fulltext:
https://wiki.blazegraph.com/wiki/index.php/FullTextSearch
The standardization of full-text could be tricky, because even if we accept
lucene basic syntax as the default, it may introduce the need of adding a
way to properly handle text-analysis chains, mappings, and so on... so in
order to avoid rewrite Solr or Elasticsearch :-) the best approach would be
probably enable the call to external services. For example we could have a
standardization of the language used to send parameters to external
services, something similar to what hydra did, maybe?

the vectorization part is rather interesting from my point of view too, but
I'm not sure this is the right context?


Il giorno lun 1 apr 2019 alle ore 15:55 Jürgen Jakobitsch <
juergen.jakobitsch@semantic-web.com> ha scritto:

> hi there,
>
> as indicated by andy, we should carry on with this conversation on the
> public mailing list..
>
> i hereby restart the thread with my wishlist (i'm pretty sure there also
> will be wiki page or other means to collect suggestions in the near future)
> :-)
>
> 1. as a sucker of query optimization and the grand reducer of joins of
> whatever sort, i really, really would appreciate
>    execution sequence hints or at the very least FROM in subqueries and
> related a well defined sequence of what comes first: SERVICE or subselect.
> 2. as a sucker of "words are flowing out like endless rain" (beatles:
> across the universe) i fully support any forms of stream capabilities. rdf
> is just made
>     for streams, a query type a la STREAM ?x FROM <http..> WHERE { ...
> 3. sometimes also very little things are required: a sequence (per group
> or the whole result).. (this is for example possible with virtuoso)
> 4. vectorization on the fly would also be neat, we wanna do cool stuff
> like ML, cooccurences, linguistic statistics,... don't we?
> 5. "split"..
>    or in general "set creating" functions.. this is usually only possible
> with custom function these days, rdf4j for example requires usage of an
> extended evaluation strategy, stardog can do it with custom function,
>    as well as virtuoso with PL/SQL.. my preferred option would be "split
> by regex"
>
> mtfbwy j
>
> *Jürgen Jakobitsch*
> Senior Technical Consultant
> Semantic Web Company GmbH
> EU: +43-14021235 <+43%201%204021235>
> US: (415) 800-3776
> Mobile: +43-676-6212710 <+43%20676%206212710>
> https://www.poolparty.biz
> https://www.semantic-web.com
>
> *Download E-Book*: Introducing Semantic AI
> <https://www.poolparty.biz/machine-learning-meets-semantics/>
>