Re: Fuseki support text/plain

[Andy Seaborne]

https://www.w3.org/TR/sparql11-protocol/#query-via-post-direct

On 24/04/17 19:25, Laura Morales wrote:

What is the reason you would like to send queries with that particular 
mimetype? Is it a question of configuring an HTTP client in your code?


It's not really about the mime type, it's about sending a plain text request where the 
whole content is interpreted as the query, without the need of query=... arguments or the 
need of encoding. I thought text/plain would work, but apparently it's not the correct 
approach. "application/sparql-query" works fine for this purpose, so I'm just 
going to use this instead of the former.

Re: Fuseki support text/plain

[Laura Morales]

> What is the reason you would like to send queries with that particular 
> mimetype? Is it a question of configuring an HTTP client in your code?

It's not really about the mime type, it's about sending a plain text request 
where the whole content is interpreted as the query, without the need of 
query=... arguments or the need of encoding. I thought text/plain would work, 
but apparently it's not the correct approach. "application/sparql-query" works 
fine for this purpose, so I'm just going to use this instead of the former.

Re: Fuseki support text/plain

[ocymum]

What is the reason you would like to send queries with that particular 
mimetype? Is it a question of configuring an HTTP client in your code?

---
A. Soroka

Laura Morales wrote on 4/24/17 2:46 AM:

text/plain is not supported by SPARQL Protocol, but you can try
application/sparql-query.

https://www.w3.org/TR/sparql11-protocol/#query-operation

On Mon, 24 Apr 2017 at 08.21, Laura Morales  wrote:


Right now when I send POST requests to Fuseki, it seems to accept
"application/x-www-form-urlencoded" requests only.


"only"?

What URL are you POSTing to?


Sorry, using "only" was probably a mistake as "application/sparql-query" seems to work 
too (it just seemed to me that I couldn't use anything but "application/x-www-form-urlencoded").
Anyway, just using a vanilla installation of Fuseki on a private server.

Re: How to make complex SPARQL queries reusable?

[Paul Tyson]

Another option is to express the query logic in standard rule notation, such as 
RIF, and translate to sparql. This approach is especially indicated if the 
sparql queries represent actual business rules.

Regards,
--Paul

> On Apr 24, 2017, at 06:22, Andy Seaborne  wrote:
> 
> Simon,
> 
> 1/ SpinRDF provides ways of defining custom functions and property functions 
> in SPARQL.
> 
> http://spinrdf.org/
> 
> There'll probably be something in the SHACL-sphere (not in the standard, but 
> in the same general area/style/framework) soon.
> 
> 2/ There are methods in ExprUtils to parse expressions in SPARQL syntax.
> 
> You could build a general helper.
> 
> That does not enable syntax replacement but does cover (?) your MyFunc 
> example.
> 
>Andy
> 
>> On 24/04/17 01:02, Simon Schäfer wrote:
>> Hello,
>> 
>> I have complex SPARQL queries, which I would like to divide into several 
>> parts (like function definitions), in order to reuse these parts among 
>> different SPARQL queries and in order to make a single SPARQL query easier 
>> to understand. What are my options to achieve this?
>> 
>> I had a look at Jenas built in functionality to support user defined 
>> function definitions. The problem with them is that it seems that they can 
>> be used only for simple functionality like calculating the max of two 
>> integers. But I have quite complex functionality, which I don't want to 
>> rewrite in Java. Example:
>> 
>> 
>> select * where {
>>  ?s a ?tpe .
>>  filter not exists {
>>?sub rdfs:subClassOf ?tpe .
>>filter (?sub != ?tpe)
>>  }
>> }
>> 
>> 
>> It would be great if that could be separated into:
>> 
>> 
>> public class MyFunc extends FunctionBase1 {
>>public NodeValue exec(NodeValue v) {
>>return NodeValue.fromSparql("filter not exists {"
>>+ "   ?sub rdfs:subClassOf ?tpe ."
>>+ "  filter (?sub != ?tpe)"
>>+ "}") ;
>>}
>> }
>> // and then later
>> FunctionRegistry.get().put("http://example.org/function#myFunc;, 
>> MyFunc.class) ;
>> 
>> 
>> and then:
>> 
>> 
>> prefix fun:
>> select * where {
>>  ?s a ?tpe .
>>  filter(fun:myFunc(?tpe))
>> }
>> 
>> 
>> Basically I'm looking for a way to call a SPARQL query from within a SPARQL 
>> query. Is that possible?
>> 
>> 

Re: Jena native store indexes

[Martynas Jusevičius]

"Should have been, could have been". It is how it is, your opinion is just
one of many and you will achieve nothing by complaining on this list. Go
create a W3C Community Group and initiate some real work to achieve the
standardisation that you think is required.

On Mon, 24 Apr 2017 at 13.30,  wrote:

>
> Hello,
>
> > You seem to fundamentally misunderstand how the standardisation process
> > works.
>
> The point is not whether i understand standardisation or not, the point is
> your argument
>
> >   At the time that SPARQL 1.1 was standardised indexing was not a
> > widely used extension so there was no impetus to standardise it.
>
> No supply, no demand. The torture creating for each property text-indexing
> out of SPARQL syntax and than beeing even not compatible to other SPARQL
> implementations yields no statistical statement whether text-indexing has
> been widely used or not.
>
> In my posting i pointed up, text-indexing should have had top priority
> starting from scratch to develope a query language for Semantic Web
> environment, you don't think so and this has nothing to do with
> 'fundamental' knowledge of a user, this has something to do setting
> different priorities.
>
> Where SPARQL is now relating to text-indexing, this is 'fundamentally' not
> acceptable for me. And you seem to be 'fundamentally' satisfied...
>
> baran
>
> *
>
>
>
>   One might imagine that a future round of standardisation
> > would choose to consider this as one candidate for a new feature in a
> > future  Version of the standard.
> >
> > Rob
> >
> > On 22/04/2017 11:02, "baran...@gmail.com"  wrote:
> >
> > ...(text search with text-indexing) cannot be offically expressed in
> > SPARQL.
> >I don't think Jena Development was responsible for this, but i assume
> > they
> > know who and i as a user want also know who is in the history of
> > SPARQL
> > development responsible for this idiocy...
> >
> >
> >
> >
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>

Re: Jena native store indexes

[baran . ha]

Hello,

You seem to fundamentally misunderstand how the standardisation process  
works.


The point is not whether i understand standardisation or not, the point is  
your argument


  At the time that SPARQL 1.1 was standardised indexing was not a  
widely used extension so there was no impetus to standardise it.


No supply, no demand. The torture creating for each property text-indexing  
out of SPARQL syntax and than beeing even not compatible to other SPARQL  
implementations yields no statistical statement whether text-indexing has  
been widely used or not.


In my posting i pointed up, text-indexing should have had top priority  
starting from scratch to develope a query language for Semantic Web  
environment, you don't think so and this has nothing to do with  
'fundamental' knowledge of a user, this has something to do setting  
different priorities.


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


baran

*



 One might imagine that a future round of standardisation
would choose to consider this as one candidate for a new feature in a  
future  Version of the standard.


Rob

On 22/04/2017 11:02, "baran...@gmail.com"  wrote:

...(text search with text-indexing) cannot be offically expressed in
SPARQL.
   I don't think Jena Development was responsible for this, but i assume  
they
know who and i as a user want also know who is in the history of  
SPARQL

development responsible for this idiocy...







--
Using Opera's mail client: http://www.opera.com/mail/

Re: How to make complex SPARQL queries reusable?

[Andy Seaborne]

Simon,

1/ SpinRDF provides ways of defining custom functions and property 
functions in SPARQL.


http://spinrdf.org/

There'll probably be something in the SHACL-sphere (not in the standard, 
but in the same general area/style/framework) soon.


2/ There are methods in ExprUtils to parse expressions in SPARQL syntax.

You could build a general helper.

That does not enable syntax replacement but does cover (?) your MyFunc 
example.


Andy

On 24/04/17 01:02, Simon Schäfer wrote:

Hello,

I have complex SPARQL queries, which I would like to divide into several parts 
(like function definitions), in order to reuse these parts among different 
SPARQL queries and in order to make a single SPARQL query easier to understand. 
What are my options to achieve this?

I had a look at Jenas built in functionality to support user defined function 
definitions. The problem with them is that it seems that they can be used only 
for simple functionality like calculating the max of two integers. But I have 
quite complex functionality, which I don't want to rewrite in Java. Example:


select * where {
  ?s a ?tpe .
  filter not exists {
?sub rdfs:subClassOf ?tpe .
filter (?sub != ?tpe)
  }
}


It would be great if that could be separated into:


public class MyFunc extends FunctionBase1 {
public NodeValue exec(NodeValue v) {
return NodeValue.fromSparql("filter not exists {"
+ "   ?sub rdfs:subClassOf ?tpe ."
+ "  filter (?sub != ?tpe)"
+ "}") ;
}
}
// and then later
FunctionRegistry.get().put("http://example.org/function#myFunc;, MyFunc.class) ;


and then:


prefix fun:
select * where {
  ?s a ?tpe .
  filter(fun:myFunc(?tpe))
}


Basically I'm looking for a way to call a SPARQL query from within a SPARQL 
query. Is that possible?

Re: Jena native store indexes

[Andy Seaborne]

On 24/04/17 10:57, Rob Vesse wrote:

You seem to fundamentally misunderstand how the standardisation
process works. The intent of a standard is never to specify every
feature that exists or that could exist but rather to specify a set
of standard functionality that will be useful to end users while also
being amenable to multiple interoperable implementations.

For a technology like text indexing where there is a huge variety of
approaches standardising would be hugely difficult. For example if
you pick a particular technology e.g. Lucene then you automatically
exclude any implementations in languages/environments where Lucene is
not usable. If you specify a behaviour then you potentially create a
huge burden for implementers in trying to make disparate underlying
Technologies produce a specific set of answers is for a specific set
of standardised test cases that may be of little relation to
real-world use cases.


Indeed, all those issues.

For SPARQL 1.1, text indexing was discussed as a possible work item 
(consult the email archives) but the task was huge. There was no 
standard text search language (unlike regex, which are defined by XQuery).


No one volunteered to do the work.

Typical WG lifecycle - reasonable number of people at the start when 
defining the work program, fewer to do the work, fewer still to complete 
the work, respond to comments, etc.


Andy



Additionally each round of standardisation takes input based upon
commonly used extensions in the real-world as input and works to
standardise those.  At the time that SPARQL 1.1 was standardised
indexing was not a widely used extension so there was no impetus to
standardise it. One might imagine that a future round of
standardisation would choose to consider this as one candidate for a
new feature in a future  Version of the standard.

Rob

On 22/04/2017 11:02, "baran...@gmail.com" 
wrote:

...(text search with text-indexing) cannot be offically expressed in
 SPARQL.

I don't think Jena Development was responsible for this, but i assume
they know who and i as a user want also know who is in the history of
SPARQL development responsible for this idiocy...

Re: Jena native store indexes

[Rob Vesse]

You seem to fundamentally misunderstand how the standardisation process works. 
The intent of a standard is never to specify every feature that exists or that 
could exist but rather to specify a set of standard functionality that will be 
useful to end users while also being amenable to multiple interoperable 
implementations. 

For a technology like text indexing where there is a huge variety of approaches 
standardising would be hugely difficult. For example if you pick a particular 
technology e.g. Lucene then you automatically exclude any implementations in 
languages/environments where Lucene is not usable. If you specify a behaviour 
then you potentially create a huge burden for implementers in trying to make 
disparate underlying Technologies produce a specific set of answers is for a 
specific set of standardised test cases that may be of little relation to 
real-world use cases.

Additionally each round of standardisation takes input based upon commonly used 
extensions in the real-world as input and works to standardise those.  At the 
time that SPARQL 1.1 was standardised indexing was not a widely used extension 
so there was no impetus to standardise it. One might imagine that a future 
round of standardisation would choose to consider this as one candidate for a 
new feature in a future  Version of the standard.

Rob

On 22/04/2017 11:02, "baran...@gmail.com"  wrote:

...(text search with text-indexing) cannot be offically expressed in  
SPARQL.

I don't think Jena Development was responsible for this, but i assume they  
know who and i as a user want also know who is in the history of SPARQL  
development responsible for this idiocy...

Re: Fuseki support text/plain

[Andy Seaborne]

On 24/04/17 09:34, Martynas Jusevičius wrote:

text/plain is not supported by SPARQL Protocol, but you can try
application/sparql-query.

https://www.w3.org/TR/sparql11-protocol/#query-operation

On Mon, 24 Apr 2017 at 08.21, Laura Morales  wrote:


Right now when I send POST requests to Fuseki, it seems to accept
"application/x-www-form-urlencoded" requests only.


"only"?

What URL are you POSTing to?

Andy


Using "text/plain"
results in this error

Error 415: Unsupported: text/plain
Fuseki - version 2.5.0 (Build date: 2017-01-31T16:47:42+)

I was wondering if there is a way to configure Fuseki to accept text/plain
too, where users can send their queries in plain text (perhaps without any
query= argument) and the whole text is simply interpreted to be the query.

Re: How to make complex SPARQL queries reusable?

[Claude Warren]

You could use federated queries to return the sub query -- this is probably
not efficient but might provide a starting point for futher investigation.

If you are doing this in code you could use the QueryBuilder (
https://jena.apache.org/documentation/extras/querybuilder/) and pass the
sub query to the outer query.

Claude

On Mon, Apr 24, 2017 at 1:02 AM, Simon Schäfer  wrote:

> Hello,
>
> I have complex SPARQL queries, which I would like to divide into several
> parts (like function definitions), in order to reuse these parts among
> different SPARQL queries and in order to make a single SPARQL query easier
> to understand. What are my options to achieve this?
>
> I had a look at Jenas built in functionality to support user defined
> function definitions. The problem with them is that it seems that they can
> be used only for simple functionality like calculating the max of two
> integers. But I have quite complex functionality, which I don't want to
> rewrite in Java. Example:
>
> 
> 
> select * where {
>   ?s a ?tpe .
>   filter not exists {
> ?sub rdfs:subClassOf ?tpe .
> filter (?sub != ?tpe)
>   }
> }
> 
> 
>
> It would be great if that could be separated into:
>
> 
> 
> public class MyFunc extends FunctionBase1 {
> public NodeValue exec(NodeValue v) {
> return NodeValue.fromSparql("filter not exists {"
> + "   ?sub rdfs:subClassOf ?tpe ."
> + "  filter (?sub != ?tpe)"
> + "}") ;
> }
> }
> // and then later
> FunctionRegistry.get().put("http://example.org/function#myFunc;,
> MyFunc.class) ;
> 
> 
>
> and then:
>
> 
> 
> prefix fun:
> select * where {
>   ?s a ?tpe .
>   filter(fun:myFunc(?tpe))
> }
> 
> 
>
> Basically I'm looking for a way to call a SPARQL query from within a
> SPARQL query. Is that possible?
>
>
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Fuseki support text/plain

[Martynas Jusevičius]

text/plain is not supported by SPARQL Protocol, but you can try
application/sparql-query.

https://www.w3.org/TR/sparql11-protocol/#query-operation

On Mon, 24 Apr 2017 at 08.21, Laura Morales  wrote:

> Right now when I send POST requests to Fuseki, it seems to accept
> "application/x-www-form-urlencoded" requests only. Using "text/plain"
> results in this error
>
> Error 415: Unsupported: text/plain
> Fuseki - version 2.5.0 (Build date: 2017-01-31T16:47:42+)
>
> I was wondering if there is a way to configure Fuseki to accept text/plain
> too, where users can send their queries in plain text (perhaps without any
> query= argument) and the whole text is simply interpreted to be the query.
>

How to make complex SPARQL queries reusable?

[Simon Schäfer]

Hello, 
 
I have complex SPARQL queries, which I would like to divide into several parts 
(like function definitions), in order to reuse these parts among different 
SPARQL queries and in order to make a single SPARQL query easier to understand. 
What are my options to achieve this? 
 
I had a look at Jenas built in functionality to support user defined function 
definitions. The problem with them is that it seems that they can be used only 
for simple functionality like calculating the max of two integers. But I have 
quite complex functionality, which I don't want to rewrite in Java. Example: 
 

 
select * where { 
  ?s a ?tpe . 
  filter not exists { 
?sub rdfs:subClassOf ?tpe . 
filter (?sub != ?tpe) 
  } 
} 

 
 
It would be great if that could be separated into: 
 

 
public class MyFunc extends FunctionBase1 { 
public NodeValue exec(NodeValue v) { 
return NodeValue.fromSparql("filter not exists {" 
+ "   ?sub rdfs:subClassOf ?tpe ." 
+ "  filter (?sub != ?tpe)" 
+ "}") ; 
} 
} 
// and then later 
FunctionRegistry.get().put("http://example.org/function#myFunc;, MyFunc.class) 
; 

 
 
and then: 
 

 
prefix fun: 
select * where { 
  ?s a ?tpe . 
  filter(fun:myFunc(?tpe)) 
} 

 
 
Basically I'm looking for a way to call a SPARQL query from within a SPARQL 
query. Is that possible? 

Re: How to make complex SPARQL queries reusable?

[Lorenz B.]

I don't think that this is possible with the current implementation
since a Function is supposed to return a single value and you'd need
something that returns a set of values resp. bindings.

Have you checked SPARQL SPIN [1]? Maybe this is something you could use.

[1] http://spinrdf.org/

> Hello,
>
> I have complex SPARQL queries, which I would like to divide into several 
> parts (like function definitions), in order to reuse these parts among 
> different SPARQL queries and in order to make a single SPARQL query easier to 
> understand. What are my options to achieve this?
>
> I had a look at Jenas built in functionality to support user defined function 
> definitions. The problem with them is that it seems that they can be used 
> only for simple functionality like calculating the max of two integers. But I 
> have quite complex functionality, which I don't want to rewrite in Java. 
> Example:
>
> 
> select * where {
>   ?s a ?tpe .
>   filter not exists {
> ?sub rdfs:subClassOf ?tpe .
> filter (?sub != ?tpe)
>   }
> }
> 
>
> It would be great if that could be separated into:
>
> 
> public class MyFunc extends FunctionBase1 {
> public NodeValue exec(NodeValue v) {
> return NodeValue.fromSparql("filter not exists {"
> + "   ?sub rdfs:subClassOf ?tpe ."
> + "  filter (?sub != ?tpe)"
> + "}") ;
> }
> }
> // and then later
> FunctionRegistry.get().put("http://example.org/function#myFunc;, 
> MyFunc.class) ;
> 
>
> and then:
>
> 
> prefix fun:
> select * where {
>   ?s a ?tpe .
>   filter(fun:myFunc(?tpe))
> }
> 
>
> Basically I'm looking for a way to call a SPARQL query from within a SPARQL 
> query. Is that possible?
>
>
-- 
Lorenz Bühmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center

How to make complex SPARQL queries reusable?

[Simon Schäfer]

Hello,

I have complex SPARQL queries, which I would like to divide into several parts 
(like function definitions), in order to reuse these parts among different 
SPARQL queries and in order to make a single SPARQL query easier to understand. 
What are my options to achieve this?

I had a look at Jenas built in functionality to support user defined function 
definitions. The problem with them is that it seems that they can be used only 
for simple functionality like calculating the max of two integers. But I have 
quite complex functionality, which I don't want to rewrite in Java. Example:


select * where {
  ?s a ?tpe .
  filter not exists {
?sub rdfs:subClassOf ?tpe .
filter (?sub != ?tpe)
  }
}


It would be great if that could be separated into:


public class MyFunc extends FunctionBase1 {
public NodeValue exec(NodeValue v) {
return NodeValue.fromSparql("filter not exists {"
+ "   ?sub rdfs:subClassOf ?tpe ."
+ "  filter (?sub != ?tpe)"
+ "}") ;
}
}
// and then later
FunctionRegistry.get().put("http://example.org/function#myFunc;, MyFunc.class) ;


and then:


prefix fun:
select * where {
  ?s a ?tpe .
  filter(fun:myFunc(?tpe))
}


Basically I'm looking for a way to call a SPARQL query from within a SPARQL 
query. Is that possible?