Discussion:
Fuseki support other query languages
Laura Morales
2017-03-04 10:42:07 UTC
Permalink
SPARQL is rather cumbersome and counter-intuitive to work with... I was wondering whether it would be possible to support in Fuseki some other more friendly query language, such as graphql or gremlin.
b***@gmail.com
2017-03-04 12:32:09 UTC
Permalink
I think it was a false estimation to allure SQL folks for Semantic Web
with SPARQL.

> SPARQL is rather cumbersome and counter-intuitive to work with...

and that was one of the important reasons, why they ignored SPARQL. There
are also other reasons. But the most important one is: No revolution
basing on the help of the past.

> I was wondering whether it would be possible to support in Fuseki some
> other more friendly query language, such as graphql or gremlin.

I don't know much about graphql...
I don't know much about gremlin...

But i know that it would have been much better trying to develope a new
query language starting from scratch and supporting intuitively usage of a
simple RDFS-design. Also for better performance...

But about ten years ago, confrontated with SPARQL, i also thought, very
good idea, i have 2-3 years experience with SQL and i have an open door to
Semantic Web revolution...

thanks, baran
--
Using Opera's mail client: http://www.opera.com/mail/
Laura Morales
2017-03-04 12:40:49 UTC
Permalink
This message is very confusing.
I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?


> Sent: Saturday, March 04, 2017 at 1:32 PM
> From: ***@gmail.com
> To: ***@jena.apache.org
> Subject: Re: Fuseki support other query languages
>
>
> I think it was a false estimation to allure SQL folks for Semantic Web
> with SPARQL.
>
> > SPARQL is rather cumbersome and counter-intuitive to work with...
>
> and that was one of the important reasons, why they ignored SPARQL. There
> are also other reasons. But the most important one is: No revolution
> basing on the help of the past.
>
> > I was wondering whether it would be possible to support in Fuseki some
> > other more friendly query language, such as graphql or gremlin.
>
> I don't know much about graphql...
> I don't know much about gremlin...
>
> But i know that it would have been much better trying to develope a new
> query language starting from scratch and supporting intuitively usage of a
> simple RDFS-design. Also for better performance...
>
> But about ten years ago, confrontated with SPARQL, i also thought, very
> good idea, i have 2-3 years experience with SQL and i have an open door to
> Semantic Web revolution...
>
> thanks, baran
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
A. Soroka
2017-03-04 12:45:15 UTC
Permalink
Certainly it would be _possible_ to write an extension for Fuseki that would do such a thing. It is not in any obvious way part of the current remit for the Jena project. Are you interested in undertaking that work?

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 7:40 AM, Laura Morales <***@mail.com> wrote:
>
> This message is very confusing.
> I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?
>
>
>> Sent: Saturday, March 04, 2017 at 1:32 PM
>> From: ***@gmail.com
>> To: ***@jena.apache.org
>> Subject: Re: Fuseki support other query languages
>>
>>
>> I think it was a false estimation to allure SQL folks for Semantic Web
>> with SPARQL.
>>
>>> SPARQL is rather cumbersome and counter-intuitive to work with...
>>
>> and that was one of the important reasons, why they ignored SPARQL. There
>> are also other reasons. But the most important one is: No revolution
>> basing on the help of the past.
>>
>>> I was wondering whether it would be possible to support in Fuseki some
>>> other more friendly query language, such as graphql or gremlin.
>>
>> I don't know much about graphql...
>> I don't know much about gremlin...
>>
>> But i know that it would have been much better trying to develope a new
>> query language starting from scratch and supporting intuitively usage of a
>> simple RDFS-design. Also for better performance...
>>
>> But about ten years ago, confrontated with SPARQL, i also thought, very
>> good idea, i have 2-3 years experience with SQL and i have an open door to
>> Semantic Web revolution...
>>
>> thanks, baran
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
John A. Fereira
2017-03-04 13:08:38 UTC
Permalink
As a software developer I am frequent asked if I can do something like this. My answer is usually something like "yes" but with a followup question that "Should we do this?" Presumably there is some sort of use case for which extending fuseki to support other query languages might solve. Perhaps describing that use case would lead to an answer which describes how using jena or something that uses jena can solve that use case.

Have you seen Elda? http://epimorphics.github.io/elda/current/index.html



-----Original Message-----
From: A. Soroka [mailto:***@virginia.edu]
Sent: Saturday, March 4, 2017 7:45 AM
To: ***@jena.apache.org
Subject: Re: Fuseki support other query languages

Certainly it would be _possible_ to write an extension for Fuseki that would do such a thing. It is not in any obvious way part of the current remit for the Jena project. Are you interested in undertaking that work?

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 7:40 AM, Laura Morales <***@mail.com> wrote:
>
> This message is very confusing.
> I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?
>
>
>> Sent: Saturday, March 04, 2017 at 1:32 PM
>> From: ***@gmail.com
>> To: ***@jena.apache.org
>> Subject: Re: Fuseki support other query languages
>>
>>
>> I think it was a false estimation to allure SQL folks for Semantic
>> Web with SPARQL.
>>
>>> SPARQL is rather cumbersome and counter-intuitive to work with...
>>
>> and that was one of the important reasons, why they ignored SPARQL.
>> There are also other reasons. But the most important one is: No
>> revolution basing on the help of the past.
>>
>>> I was wondering whether it would be possible to support in Fuseki
>>> some other more friendly query language, such as graphql or gremlin.
>>
>> I don't know much about graphql...
>> I don't know much about gremlin...
>>
>> But i know that it would have been much better trying to develope a
>> new query language starting from scratch and supporting intuitively
>> usage of a simple RDFS-design. Also for better performance...
>>
>> But about ten years ago, confrontated with SPARQL, i also thought,
>> very good idea, i have 2-3 years experience with SQL and i have an
>> open door to Semantic Web revolution...
>>
>> thanks, baran
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
Andy Seaborne
2017-03-04 13:32:51 UTC
Permalink
Well, GraphQL isn't a query language for graphs :-) You'll notice that
the website does not say "graph". Really, it's a "data access language"
and good at doing that.

You could say the Turtle+variables part of SPARQL is the same theme as
GraphQL. (e.g. no filters). There are languages in the style of GraphQL
that do have expressions.

It is import to separate syntax from the execution model. You could
have a better syntax and compile to the SPARQL Algebra. Or a better
syntax for a subset of SPARQL like BGP+Filter, compile it client-side
and execute remotely.

Andy

On 04/03/17 13:08, John A. Fereira wrote:
> As a software developer I am frequent asked if I can do something like this. My answer is usually something like "yes" but with a followup question that "Should we do this?" Presumably there is some sort of use case for which extending fuseki to support other query languages might solve. Perhaps describing that use case would lead to an answer which describes how using jena or something that uses jena can solve that use case.
>
> Have you seen Elda? http://epimorphics.github.io/elda/current/index.html
>
>
>
> -----Original Message-----
> From: A. Soroka [mailto:***@virginia.edu]
> Sent: Saturday, March 4, 2017 7:45 AM
> To: ***@jena.apache.org
> Subject: Re: Fuseki support other query languages
>
> Certainly it would be _possible_ to write an extension for Fuseki that would do such a thing. It is not in any obvious way part of the current remit for the Jena project. Are you interested in undertaking that work?
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Mar 4, 2017, at 7:40 AM, Laura Morales <***@mail.com> wrote:
>>
>> This message is very confusing.
>> I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?
>>
>>
>>> Sent: Saturday, March 04, 2017 at 1:32 PM
>>> From: ***@gmail.com
>>> To: ***@jena.apache.org
>>> Subject: Re: Fuseki support other query languages
>>>
>>>
>>> I think it was a false estimation to allure SQL folks for Semantic
>>> Web with SPARQL.
>>>
>>>> SPARQL is rather cumbersome and counter-intuitive to work with...
>>>
>>> and that was one of the important reasons, why they ignored SPARQL.
>>> There are also other reasons. But the most important one is: No
>>> revolution basing on the help of the past.
>>>
>>>> I was wondering whether it would be possible to support in Fuseki
>>>> some other more friendly query language, such as graphql or gremlin.
>>>
>>> I don't know much about graphql...
>>> I don't know much about gremlin...
>>>
>>> But i know that it would have been much better trying to develope a
>>> new query language starting from scratch and supporting intuitively
>>> usage of a simple RDFS-design. Also for better performance...
>>>
>>> But about ten years ago, confrontated with SPARQL, i also thought,
>>> very good idea, i have 2-3 years experience with SQL and i have an
>>> open door to Semantic Web revolution...
>>>
>>> thanks, baran
>>> --
>>> Using Opera's mail client: http://www.opera.com/mail/
>>>
>
Laura Morales
2017-03-04 13:49:22 UTC
Permalink
> Presumably there is some sort of use case for which extending fuseki to support other query languages might solve. Perhaps describing that use case would lead to an answer which describes how using jena or something that uses jena can solve that use case.


well I don't have a specific use case in mind, I just find SPARQL very counter-intuitive and difficult to reason with


> Have you seen Elda? http://epimorphics.github.io/elda/current/index.html


nope, never before. Now I'm even more confused about the purposes of Fuseki/Elda/LDP
A. Soroka
2017-03-04 13:59:33 UTC
Permalink
> well I don't have a specific use case in mind, I just find SPARQL very counter-intuitive and difficult to reason with
...
> nope, never before. Now I'm even more confused about the purposes of Fuseki/Elda/LDP

Then you will probably want to settle on a particular use case through which to investigate these tools. Asking about the generic use of a tool is often less helpful than planning to accomplish a concrete end and trying that tool in that context.

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 8:49 AM, Laura Morales <***@mail.com> wrote:
>
>> Presumably there is some sort of use case for which extending fuseki to support other query languages might solve. Perhaps describing that use case would lead to an answer which describes how using jena or something that uses jena can solve that use case.
>
>
> well I don't have a specific use case in mind, I just find SPARQL very counter-intuitive and difficult to reason with
>
>
>> Have you seen Elda? http://epimorphics.github.io/elda/current/index.html
>
>
> nope, never before. Now I'm even more confused about the purposes of Fuseki/Elda/LDP
Chris Dollin
2017-03-05 15:24:03 UTC
Permalink
On 04/03/17 13:49, Laura Morales wrote:

> well I don't have a specific use case in mind,
> I just find SPARQL very counter-intuitive and difficult to reason with

Could you be more specific about these intuitions and difficulties?

Chris
Laura Morales
2017-03-05 16:37:25 UTC
Permalink
> Could you be more specific about these intuitions and difficulties?

with other query languages such as gremlin you start from a vertex (or set of vertices), and follow links (predicates). This is very intuitive, because it resemble the picture of a graph that I have in mind. For example, I can start from the vertex "Bruce Springsteen" and follow its out-links "some_namespace:song". Very easy to understand and work with. SPARQL, at least to me, seems to be way more intricate, messy, verbose, and ultimately difficult to understand. Just look at this query (copied from wikidata examples) for a query as simple as "Children of Genghis Khan".... I barely understand how to read it to be honest

#Children of Genghis Khan
#added before 2016-10
#defaultView:Graph

PREFIX gas: <http://www.bigdata.com/rdf/gas#>

SELECT ?item ?itemLabel ?pic ?linkTo
WHERE
{
SERVICE gas:service {
gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
gas:in wd:Q720 ;
gas:traversalDirection "Forward" ;
gas:out ?item ;
gas:out1 ?depth ;
gas:maxIterations 4 ;
gas:linkType wdt:P40 .
}
OPTIONAL { ?item wdt:P40 ?linkTo }
OPTIONAL { ?item wdt:P18 ?pic }
SERVICE wikibase:label {bd:serviceParam wikibase:language "en" }
}
A. Soroka
2017-03-05 16:44:55 UTC
Permalink
That is in no way a normal SPARQL query. I don't know where in particular you got it, but it is an example of Blazegraph/BigData's "GAS" API. It's not an example of idiomatic SPARQL at all.

https://wiki.blazegraph.com/wiki/index.php/RDF_GAS_API

That is a specialist extension API for one product's particular capability.

You can refer to any number of good tutorials for how to write normal SPARQL. Jena itself maintains one:

https://jena.apache.org/tutorials/sparql.html


---
A. Soroka
The University of Virginia Library

> On Mar 5, 2017, at 11:37 AM, Laura Morales <***@mail.com> wrote:
>
>> Could you be more specific about these intuitions and difficulties?
>
> with other query languages such as gremlin you start from a vertex (or set of vertices), and follow links (predicates). This is very intuitive, because it resemble the picture of a graph that I have in mind. For example, I can start from the vertex "Bruce Springsteen" and follow its out-links "some_namespace:song". Very easy to understand and work with. SPARQL, at least to me, seems to be way more intricate, messy, verbose, and ultimately difficult to understand. Just look at this query (copied from wikidata examples) for a query as simple as "Children of Genghis Khan".... I barely understand how to read it to be honest
>
> #Children of Genghis Khan
> #added before 2016-10
> #defaultView:Graph
>
> PREFIX gas: <http://www.bigdata.com/rdf/gas#>
>
> SELECT ?item ?itemLabel ?pic ?linkTo
> WHERE
> {
> SERVICE gas:service {
> gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
> gas:in wd:Q720 ;
> gas:traversalDirection "Forward" ;
> gas:out ?item ;
> gas:out1 ?depth ;
> gas:maxIterations 4 ;
> gas:linkType wdt:P40 .
> }
> OPTIONAL { ?item wdt:P40 ?linkTo }
> OPTIONAL { ?item wdt:P18 ?pic }
> SERVICE wikibase:label {bd:serviceParam wikibase:language "en" }
> }
Laura Morales
2017-03-05 17:20:29 UTC
Permalink
> I don't know where in particular you got it

https://query.wikidata.org
Andy Seaborne
2017-03-05 17:31:44 UTC
Permalink
Using SERVICE to inject pragma into the query is not exact standard ...
nor exactly spec-compliant :-)

I think that is trying to do something like a traversal of 1 to 4 in
depth and get a picture: {0,4} includes the start.

Standard SPARQL has arbitrary length traversal and can't limit the depth.

WHERE {
wd:Q720 wdt:P40* ?child .
OPTIONAL { ?child wdt:P18 ?pic }
}



ARQ supports an extension - it's a feature that didn't make into the
final SPARQL 1.1 spec (parse with syntax "ARQ", the default in Fuseki):
this isn't necessary exactly the same:

SELECT ?child ?pic
WHERE {
wd:Q720 wdt:P40{0,4} ?child .
OPTIONAL { ?child wdt:P18 ?pic }
}

The other problem is the opaque wdt vocabulary - that's not a SPARQL
issue, that's the vocab and data.

Andy

(https://query.wikidata.org is a BlazeGraph installation)

On 05/03/17 16:44, A. Soroka wrote:
> That is in no way a normal SPARQL query. I don't know where in particular you got it, but it is an example of Blazegraph/BigData's "GAS" API. It's not an example of idiomatic SPARQL at all.
>
> https://wiki.blazegraph.com/wiki/index.php/RDF_GAS_API
>
> That is a specialist extension API for one product's particular capability.
>
> You can refer to any number of good tutorials for how to write normal SPARQL. Jena itself maintains one:
>
> https://jena.apache.org/tutorials/sparql.html
>
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Mar 5, 2017, at 11:37 AM, Laura Morales <***@mail.com> wrote:
>>
>>> Could you be more specific about these intuitions and difficulties?
>>
>> with other query languages such as gremlin you start from a vertex (or set of vertices), and follow links (predicates). This is very intuitive, because it resemble the picture of a graph that I have in mind. For example, I can start from the vertex "Bruce Springsteen" and follow its out-links "some_namespace:song". Very easy to understand and work with. SPARQL, at least to me, seems to be way more intricate, messy, verbose, and ultimately difficult to understand. Just look at this query (copied from wikidata examples) for a query as simple as "Children of Genghis Khan".... I barely understand how to read it to be honest
>>
>> #Children of Genghis Khan
>> #added before 2016-10
>> #defaultView:Graph
>>
>> PREFIX gas: <http://www.bigdata.com/rdf/gas#>
>>
>> SELECT ?item ?itemLabel ?pic ?linkTo
>> WHERE
>> {
>> SERVICE gas:service {
>> gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
>> gas:in wd:Q720 ;
>> gas:traversalDirection "Forward" ;
>> gas:out ?item ;
>> gas:out1 ?depth ;
>> gas:maxIterations 4 ;
>> gas:linkType wdt:P40 .
>> }
>> OPTIONAL { ?item wdt:P40 ?linkTo }
>> OPTIONAL { ?item wdt:P18 ?pic }
>> SERVICE wikibase:label {bd:serviceParam wikibase:language "en" }
>> }
>
b***@gmail.com
2017-03-07 20:25:47 UTC
Permalink
On Sun, 05 Mar 2017 16:24:03 +0100, Chris Dollin
<***@epimorphics.com> wrote:

> On 04/03/17 13:49, Laura Morales wrote:
>
>> well I don't have a specific use case in mind,
>> I just find SPARQL very counter-intuitive and difficult to reason with
>
> Could you be more specific about these intuitions and difficulties?
>
> Chris

Forget SPARQL, i mean generally spoken: This was the most outstanding
question from Jena Develepement to a user posting since about 15 years,
sounds still a bit ironical, yes, but i belong to the patient users...

baran


--
Using Opera's mail client: http://www.opera.com/mail/
Laura Morales
2017-03-08 07:39:17 UTC
Permalink
> > On 04/03/17 13:49, Laura Morales wrote:
> >
> >> well I don't have a specific use case in mind,
> >> I just find SPARQL very counter-intuitive and difficult to reason with
> >
> > Could you be more specific about these intuitions and difficulties?
> >
> > Chris
>
> Forget SPARQL, i mean generally spoken: This was the most outstanding
> question from Jena Develepement to a user posting since about 15 years,
> sounds still a bit ironical, yes, but i belong to the patient users...
>
> baran


???

I don't think I understand what you're trying to say...
Laura Morales
2017-03-04 13:44:10 UTC
Permalink
> Certainly it would be _possible_ to write an extension for Fuseki that would do such a thing. It is not in any obvious way part of the current remit for the Jena project. Are you interested in undertaking that work?

I would if I knew how to do it, but I wouldn't even know how to approach such a thing... I'm just interested to use a graph database, but I find SPARQL very cumbersome... hence why I asked if there were any chance that a more friendly query language could be supported.
A. Soroka
2017-03-04 13:47:51 UTC
Permalink
There are plenty of graph databases that provide the other languages you mentioned. Is there some reason why you want to use Jena? Perhaps, as John Fereira asked, you will describe your use case.

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 8:44 AM, Laura Morales <***@mail.com> wrote:
>
>> Certainly it would be _possible_ to write an extension for Fuseki that would do such a thing. It is not in any obvious way part of the current remit for the Jena project. Are you interested in undertaking that work?
>
> I would if I knew how to do it, but I wouldn't even know how to approach such a thing... I'm just interested to use a graph database, but I find SPARQL very cumbersome... hence why I asked if there were any chance that a more friendly query language could be supported.
Laura Morales
2017-03-04 14:00:40 UTC
Permalink
> There are plenty of graph databases that provide the other languages you mentioned. Is there some reason why you want to use Jena? Perhaps, as John Fereira asked, you will describe your use case.

Because as far as I can tell, Jena/Fuseki is the *only* free/libre graph database. All other options are either non-free or with troubling, bullshit dual licenses. And I don't care of any of those non-free options because if I'm going to spend time and money learning a new piece of software, I'd rather support a free/libre one than a proprietary one.
If there are other free alternatives to Jena/Fuseki I'd be very interested to know, because I can't find any.
A. Soroka
2017-03-04 14:09:54 UTC
Permalink
I'm at a loss as to how you gathered that impression.

RDF4J (formerly known as Sesame, Eclipse license)
Apache Giraph (Apache license)
Neo4j (GPLv3 license)
Apache Spark GraphX (Apache license)
Blazegraph (GPL license)
Titan (Apache license)

Many, many more.

All of these have strengths and weakness, idiosyncrasies and unique features. I _strongly_ suggest you decide on some concrete project to attempt first. I think you will find navigating this space easier and more profitable with a goal in mind.

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 9:00 AM, Laura Morales <***@mail.com> wrote:
>
>> There are plenty of graph databases that provide the other languages you mentioned. Is there some reason why you want to use Jena? Perhaps, as John Fereira asked, you will describe your use case.
>
> Because as far as I can tell, Jena/Fuseki is the *only* free/libre graph database. All other options are either non-free or with troubling, bullshit dual licenses. And I don't care of any of those non-free options because if I'm going to spend time and money learning a new piece of software, I'd rather support a free/libre one than a proprietary one.
> If there are other free alternatives to Jena/Fuseki I'd be very interested to know, because I can't find any.
Andy Seaborne
2017-03-04 14:24:48 UTC
Permalink
> Titan (Apache license)

has become JanusGraph at the Linux Foundation (Apache 2 license).

Andy
Laura Morales
2017-03-04 14:43:57 UTC
Permalink
> RDF4J (formerly known as Sesame, Eclipse license)

"RDF4J (formerly known as Sesame) is an open source Java framework for processing RDF data."
I'm not looking at a framework, I'm only interested in the database component. Like, say, MySQL, PostgreSQL, etc... That's why I'm interested in Fuseki and not Jena.

> Apache Giraph (Apache license)

Is this "like Fuseki, but for larger graphs"?

> Neo4j (GPLv3 license)
> Blazegraph (GPL license)

I don't want to support companies that uses the "community edition"/"enterprise edition" model, especially when the open source version is only offered as a bait to sell other non-free software on top of their "enterprise edition"

> Apache Spark GraphX (Apache license)

If I'm correct Apache Spark is a framework for cluster computing, which is probably a very particular use case far beyond that mere use of a graph database for a relatively small project that don't require clusters

> Titan (Apache license)

Dead

> I think you will find navigating this space easier and more profitable with a goal in mind.

My goal is simply to learn more about graph databases, so I want to install and use one. I've installed Fuseki, but I found SPARQL to be overly complex compared to other query languages.
A. Soroka
2017-03-04 14:46:25 UTC
Permalink
Fuseki is not a database. It is a SPARQL server. Jena TDB is the usual database used with Fuseki. Using Fuseki without Jena is nonsensical. Fuseki is totally based on Jena.

https://jena.apache.org/documentation/index.html

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 9:43 AM, Laura Morales <***@mail.com> wrote:
>
> I'm not looking at a framework, I'm only interested in the database component. Like, say, MySQL, PostgreSQL, etc... That's why I'm interested in Fuseki and not Jena.
Laura Morales
2017-03-04 15:10:56 UTC
Permalink
OK if I get this right, TDB is the actual database storing all triples/n-quads, and Fuseki is a layer on top of it whose purpose is to parse SPARQL queries and retrieve triples from TDB.

Right?


> Fuseki is not a database. It is a SPARQL server. Jena TDB is the usual database used with Fuseki. Using Fuseki without Jena is nonsensical. Fuseki is totally based on Jena.
>
> https://jena.apache.org/documentation/index.html
A. Soroka
2017-03-04 15:13:13 UTC
Permalink
In between TDB and Fuseki is ARQ, which is Jena's SPARQL implementation.

https://jena.apache.org/documentation/query/index.html

ARQ can be used with a variety of backends, including in-memory systems and on-disk databases like TDB. Fuseki is mostly responsible for HTTP management and handing queries and updates to ARQ. It is ARQ that talks to TDB.

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 10:10 AM, Laura Morales <***@mail.com> wrote:
>
> OK if I get this right, TDB is the actual database storing all triples/n-quads, and Fuseki is a layer on top of it whose purpose is to parse SPARQL queries and retrieve triples from TDB.
>
> Right?
>
>
>> Fuseki is not a database. It is a SPARQL server. Jena TDB is the usual database used with Fuseki. Using Fuseki without Jena is nonsensical. Fuseki is totally based on Jena.
>>
>> https://jena.apache.org/documentation/index.html
Andy Seaborne
2017-03-04 15:26:39 UTC
Permalink
"Fuseki" as in the distribution "apache-jena-fuseki" is the bundling of
database (in memory and on disk), query engine and HTTP server as well
as text indexing.

"Fuseki" as in the Jena module, is the server part.

We tend to use the same word in different views - external and internal.

Andy

On 04/03/17 15:13, A. Soroka wrote:
> In between TDB and Fuseki is ARQ, which is Jena's SPARQL implementation.
>
> https://jena.apache.org/documentation/query/index.html
>
> ARQ can be used with a variety of backends, including in-memory systems and on-disk databases like TDB. Fuseki is mostly responsible for HTTP management and handing queries and updates to ARQ. It is ARQ that talks to TDB.
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Mar 4, 2017, at 10:10 AM, Laura Morales <***@mail.com> wrote:
>>
>> OK if I get this right, TDB is the actual database storing all triples/n-quads, and Fuseki is a layer on top of it whose purpose is to parse SPARQL queries and retrieve triples from TDB.
>>
>> Right?
>>
>>
>>> Fuseki is not a database. It is a SPARQL server. Jena TDB is the usual database used with Fuseki. Using Fuseki without Jena is nonsensical. Fuseki is totally based on Jena.
>>>
>>> https://jena.apache.org/documentation/index.html
>
b***@gmail.com
2017-03-05 10:46:59 UTC
Permalink
On Sat, 04 Mar 2017 16:10:56 +0100, Laura Morales <***@mail.com>
wrote:

> OK if I get this right, TDB is the actual database storing all
> triples/n-quads, and Fuseki is a layer on top of it whose purpose is to
> parse SPARQL queries and retrieve triples from TDB.
>
> Right?

YES,

and if you are not working on a Semantic Web app with a database basing on
triples you don't need Fuseki because of 'other' query languages...

baran

--
Using Opera's mail client: http://www.opera.com/mail/
John A. Fereira
2017-03-04 22:07:59 UTC
Permalink
It also works equally as well with Jena SDB (with a SQL database (e.g. MySQL) on the back end). We've been using Fuseki with SDB in production for five years or so.

-----Original Message-----
From: A. Soroka [mailto:***@virginia.edu]
Sent: Saturday, March 4, 2017 9:46 AM
To: ***@jena.apache.org
Subject: Re: Fuseki support other query languages

Fuseki is not a database. It is a SPARQL server. Jena TDB is the usual database used with Fuseki. Using Fuseki without Jena is nonsensical. Fuseki is totally based on Jena.

https://jena.apache.org/documentation/index.html

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 9:43 AM, Laura Morales <***@mail.com> wrote:
>
> I'm not looking at a framework, I'm only interested in the database component. Like, say, MySQL, PostgreSQL, etc... That's why I'm interested in Fuseki and not Jena.
Martynas Jusevičius
2017-03-04 15:32:07 UTC
Permalink
> My goal is simply to learn more about graph databases, so I want to install and use one. I've installed Fuseki, but I found SPARQL to be overly complex compared to other query languages.

It's a little like wanting to use RDBMS but finding SQL overly
complex. Sure, there is probably some query approach, but you will
constantly face challenges to try to get it to work. Same for XML and
XPath, etc.

SPARQL is an industry standard, deal with it. Trying to avoid it will
lead to a more complex setup than trying to learn and use it. And no
way it's more complex than SQL.
Adrian Walker
2017-03-04 16:25:55 UTC
Permalink
HI All,

Here's a little case study in going from a spec to a SPARQL query, and
separately to SQL.

HTH, -- Adrian

Adrian Walker
Reengineering LLC
San Jose, CA, USA
860 830 2085
www.executable-english.com


---------------------SPECIFICATION---------------------

I have a graph where resources have a number of controlled properties.
Call them A thorough F. Some resources may have one property other may
have all 6.

I have a resource with a with properties A, B, and C.

I want to find all resources in the graph where the resource has matching
values but does not have any non specified properties.

So
x with A, B, and C will match
y with A and C will match
z with A, B, C and D will not match
w with A and D will not match.

Any idea how to construct a query that will do this?




------------------------- SPARQL QUERY---------------------

Okay, let me try. I think I've done something similar actually - and ran
into performance problems with those queries using the latest Jena
releases. But that's a different story...

SELECT ?r
WHERE {
# we have a specific resource for which we are looking for matches
BIND(:inputresource AS ?a)

# the input resource has one or more properties
?a :p ?val .
# the matching resource should have at least one of those properties
?r :p ?val .

# but the targeted resource shouldn't have any property that the input
resource doesn't have
FILTER NOT EXISTS {
?r :p ?val2 .
FILTER NOT EXISTS {
?a :p ?val2 .
}
}
}

I think one or both of the FILTER NOT EXISTS may be changed to a MINUS as
well.




---------------------EXECUTABLE ENGLISH --> SQL--------------

some-resource has the property some-property
not : that-resource has a non-matching property
--------------------------------------------------------------
that-resource having that-property matches


some-resource has the property some-property
that-resource has a non-matching property
-------------------------------------------------------------------
that-resource having that-property does not match


some-resource has the property some-property
that-property is a non matching one
---------------------------------------------------------------
that-resource has a non-matching property


this-resource has the property this-property
=================================
x A
x B
x C
y A
y C
z A
z B
z C
z D
w A
w D


this-property is a non matching one
===========================
D

Here is SQL _generated_ from the above.

select tt1.RES , tt1.PROP from
mysql.matchT1 tt1 where tt1.RES not in
(select tt2.RES from mysql.matchT1 tt2 , mysql.matchT2
where mysql.matchT2.PROP = tt2.PROP and tt1.RES = tt2.RES )





On Sat, Mar 4, 2017 at 7:32 AM, Martynas Jusevičius <***@graphity.org>
wrote:

> > My goal is simply to learn more about graph databases, so I want to
> install and use one. I've installed Fuseki, but I found SPARQL to be overly
> complex compared to other query languages.
>
> It's a little like wanting to use RDBMS but finding SQL overly
> complex. Sure, there is probably some query approach, but you will
> constantly face challenges to try to get it to work. Same for XML and
> XPath, etc.
>
> SPARQL is an industry standard, deal with it. Trying to avoid it will
> lead to a more complex setup than trying to learn and use it. And no
> way it's more complex than SQL.
>
Andy Seaborne
2017-03-04 14:22:26 UTC
Permalink
On 04/03/17 14:00, Laura Morales wrote:
>> There are plenty of graph databases that provide the other
>> languages you mentioned. Is there some reason why you want to use
>> Jena? Perhaps, as John Fereira asked, you will describe your use
>> case.
>
> Because as far as I can tell, Jena/Fuseki is the *only* free/libre
> graph database. All other options are either non-free or with
> troubling, bullshit dual licenses. And I don't care of any of those
> non-free options because if I'm going to spend time and money
> learning a new piece of software, I'd rather support a free/libre one
> than a proprietary one. If there are other free alternatives to
> Jena/Fuseki I'd be very interested to know, because I can't find
> any.
>

We hope Fuseki is useful. (Contributions welcome! and if anyone finds
they needs hooks in the main system please github issue/JIRA/email/...)

In the RDF space:

Apache Rya (uses Apache Accumulo) and Apache Marmotta provide RDF databases.

For Property Graphs:

Apache TinkerPop (you have to find a persistence layer IIRC), and for
analytics, Apache Spark/GraphX, Apache Giraph, and others.

Andy
Laura Morales
2017-03-04 14:51:30 UTC
Permalink
> In the RDF space:
> ...
> For Property Graphs:
>
> Apache TinkerPop (you have to find a persistence layer IIRC), and for
> analytics, Apache Spark/GraphX, Apache Giraph, and others.
>
> Andy
>

what's the difference between these two areas? Does it mean that GraphX/Giraph are only good to analyze large graph and draw statistics, whereas I should use others like Fuseki/Marmotta if I want to build an application (in the same way that I'd normally use PostgreSQL)?
Andy Seaborne
2017-03-04 15:21:07 UTC
Permalink
On 04/03/17 14:51, Laura Morales wrote:
>> In the RDF space:
>> ...
>> For Property Graphs:
>>
>> Apache TinkerPop (you have to find a persistence layer IIRC), and for
>> analytics, Apache Spark/GraphX, Apache Giraph, and others.
>>
>> Andy
>>
>
> what's the difference between these two areas? Does it mean that
> GraphX/Giraph are only good to analyze large graph and draw statistics,
> whereas I should use others like Fuseki/Marmotta if I want to build an
> application (in the same way that I'd normally use PostgreSQL)?

Roughly - yes.

A lot of the activity (and hence investment) in the property graph space
is around analytics.

It's not a black/white divide. There are some pretty big RDF
installations (many billions of triples, these tend not to be web
accessible) doing analytics finding patterns in the data.

RDF emphasizes information modelling
Publishing data / separation of app and data
Knowledge graphs
Standard interchange formats

Property Graph emphasizes
Data capture
Graph analytic algorithms
Processing

Andy
Andy Seaborne
2017-03-04 13:49:34 UTC
Permalink
On 04/03/17 12:45, A. Soroka wrote:

> It is not in any obvious way part of the current remit for the Jena
> project.

Why not?!

Isn't LDP for RDF just another service over the data?

Andy

>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Mar 4, 2017, at 7:40 AM, Laura Morales <***@mail.com> wrote:
>>
>> This message is very confusing.
>> I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?
>>
>>
>>> Sent: Saturday, March 04, 2017 at 1:32 PM
>>> From: ***@gmail.com
>>> To: ***@jena.apache.org
>>> Subject: Re: Fuseki support other query languages
>>>
>>>
>>> I think it was a false estimation to allure SQL folks for Semantic Web
>>> with SPARQL.
>>>
>>>> SPARQL is rather cumbersome and counter-intuitive to work with...
>>>
>>> and that was one of the important reasons, why they ignored SPARQL. There
>>> are also other reasons. But the most important one is: No revolution
>>> basing on the help of the past.
>>>
>>>> I was wondering whether it would be possible to support in Fuseki some
>>>> other more friendly query language, such as graphql or gremlin.
>>>
>>> I don't know much about graphql...
>>> I don't know much about gremlin...
>>>
>>> But i know that it would have been much better trying to develope a new
>>> query language starting from scratch and supporting intuitively usage of a
>>> simple RDFS-design. Also for better performance...
>>>
>>> But about ten years ago, confrontated with SPARQL, i also thought, very
>>> good idea, i have 2-3 years experience with SQL and i have an open door to
>>> Semantic Web revolution...
>>>
>>> thanks, baran
>>> --
>>> Using Opera's mail client: http://www.opera.com/mail/
>>>
>
A. Soroka
2017-03-04 13:51:55 UTC
Permalink
Yes, and I'm increasingly convinced (pretty totally convinced at this point) that an LDP piece for Fuseki would be a bad idea. I'm not going to pursue it.

---
A. Soroka
The University of Virginia Library

> On Mar 4, 2017, at 8:49 AM, Andy Seaborne <***@apache.org> wrote:
>
> On 04/03/17 12:45, A. Soroka wrote:
>
> > It is not in any obvious way part of the current remit for the Jena
> > project.
>
> Why not?!
>
> Isn't LDP for RDF just another service over the data?
>
> Andy
>
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Mar 4, 2017, at 7:40 AM, Laura Morales <***@mail.com> wrote:
>>>
>>> This message is very confusing.
>>> I was asking whether it would be possible to add another (more friendly) query language to Fuseki, or not?
>>>
>>>
>>>> Sent: Saturday, March 04, 2017 at 1:32 PM
>>>> From: ***@gmail.com
>>>> To: ***@jena.apache.org
>>>> Subject: Re: Fuseki support other query languages
>>>>
>>>>
>>>> I think it was a false estimation to allure SQL folks for Semantic Web
>>>> with SPARQL.
>>>>
>>>>> SPARQL is rather cumbersome and counter-intuitive to work with...
>>>>
>>>> and that was one of the important reasons, why they ignored SPARQL. There
>>>> are also other reasons. But the most important one is: No revolution
>>>> basing on the help of the past.
>>>>
>>>>> I was wondering whether it would be possible to support in Fuseki some
>>>>> other more friendly query language, such as graphql or gremlin.
>>>>
>>>> I don't know much about graphql...
>>>> I don't know much about gremlin...
>>>>
>>>> But i know that it would have been much better trying to develope a new
>>>> query language starting from scratch and supporting intuitively usage of a
>>>> simple RDFS-design. Also for better performance...
>>>>
>>>> But about ten years ago, confrontated with SPARQL, i also thought, very
>>>> good idea, i have 2-3 years experience with SQL and i have an open door to
>>>> Semantic Web revolution...
>>>>
>>>> thanks, baran
>>>> --
>>>> Using Opera's mail client: http://www.opera.com/mail/
>>>>
>>
Loading...