Actually, no I am not fundamentally satisfied. I was trying to explain how the 
current situation came to be in reply to your assertion that “some idiocy” was 
responsible and in the context of your specific complaint about to text 
indexing.

In general property functions as they exist in a variety of implementations all 
try to address a limitation of the language in that we have limited ways to 
introduce new solutions into a query:

1 - Pattern matches
2 - BIND()/Project Expressions
3 - Aggregation
4 - Values

2 is limited in that you can only introduce additional columns to pre-existing 
solutions introduced by the other forms, 3 is limited in that it reduces data. 
4 only permits static data

What I would like to see in the language is a generalised mechanism to allow 
inserting extensions that expand the possible solutions e.g.

SELECT *
WHERE
{
 ?s a <http://example> .
 INVOKE <http://text-indexing>(?s, “arg1”, “arg2”) RETURNS (?o)
 ?s ?p ?o
}

However, no such extension exists currently to my knowledge nor do I have the 
free time to investigate the potential ways to implement such a solution. If no 
such extensions come into existence then there is very little chance that they 
would make their way into future standards. So I can complain about this all I 
want but it won’t change anything.

On the other hand, text indexing which is by now a widely supported extension 
will likely be a prime candidate for future standardisation

 There are other limitations in the language that have been discussed on these 
lists in the past e.g. Supporting custom aggregations. Why doesn’t the language 
supports standard deviation as a standard aggregate? Ultimately a working group 
has limited time and limited scope, not everything that everybody wants present 
in the language Will make it into the standard. That is why we have vendor 
specific extensions despite all the other interoperability problems that those 
create for myself and other users.

I would reiterate the point I often make when people ask why X cannot achieve Y:

A tool is designed for a specific set of jobs, it is not designed to solve 
every possible problem!  Don’t forget that you are a programmer and that you 
have a general-purpose programming language at your disposal.  You can use this 
to achieve Solutions to many more problems than your tool alone provides for.

Rob

On 24/04/2017 12:30, "baran...@gmail.com" <baran...@gmail.com> wrote:

    Where SPARQL is now relating to text-indexing, this is 'fundamentally' not  
    acceptable for me. And you seem to be 'fundamentally' satisfied...
    
    




Reply via email to