Re: Use PREFIXes by default

Awhile back I was looking for a way to change/add to the list of prefixes at runtime. This request dovetails nicely with what I was looking for. I got sidetracked with other issues at work before I could really get to it. As I recall most storage layers don't keep a list of namespaces separate

Re: Use PREFIXes by default

Because to me it seems like a very useful feature for Fuseki. For users it's simpler to think in terms of short properties instead of long urls, so they can submit queries right away without worrying of what is the exact url for a particular prefix. I'm not saying that this is a fundamental

Re: Use PREFIXes by default

If you are not concerned about performance, why not add those prefixes client-side? ajs6f > On Feb 25, 2018, at 4:18 PM, Laura Morales wrote: > > I have several scripts from where I submit multiple queries. I submit a query > and read the results, then submit another

Re: Use PREFIXes by default

I have several scripts from where I submit multiple queries. I submit a query and read the results, then submit another query. But I'm not really concerned about performance... my original question was simply about not having to deal with PREFIXes definition, and instead instruct Fuseki to use

Re: Use PREFIXes by default

One script == one query? Or many queries in one script? Are you using a SPARQL library? Are HTTP connections pooled and reused? All theses have a major impact on request performance. Fuseki (well, Jetty) is very good with connection management but the client has to play the game. On 25 February

Re: Use PREFIXes by default

>> What software are you using to send the requests to Fuseki? > > I just send HTTP GET requests (from Python scripts). GET/POST

Re: Use PREFIXes by default

> What software are you using to send the requests to Fuseki? I just send HTTP GET requests (from Python scripts).

Re: Fuseki: Configuration for an inferencing endpoint throws AmbiguousSpecificTypeException (HDT).

Lars, You have said you have HDT working in a different configuration. What I'm trying to understand is difference between the two. What was the configuration that did work? Andy On 24/02/18 13:18, Svensson, Lars wrote: On Saturday, February 24, 2018 10:33 AM, Andy Seaborne

Re: Use PREFIXes by default

Laura, The reason is that appending all prefixes for each query is going to add a lot of (unused) overhead for each request. What software are you using to send the requests to Fuseki? Andy On 25/02/18 18:56, Laura Morales wrote: I use some tdb stores but also hdt for larger graphs

Re: Use PREFIXes by default

I use some tdb stores but also hdt for larger graphs (simply because it's more convenient). I could add a filter before submitting to Fuseki, but in the general case it looks to me that a Fuseki configuration would be a better approach. The reason is that appending all prefixes for each query

Re: Use PREFIXes by default

This seems like something that might be well-handled by a filter or other processing element outside of Fuseki itself, which could just add a PREFIXes header to all incoming requests. Otherwise, are you using TDB? (Because I believe that it does maintain some information about prefixes used.)

ResourceImpl subclass constructors with extra arguments

Hi, we are extensively using Jena's polymorhism, by implementing classes that extend ResourceImpl, with such constructors: public SomeImpl(Node n, EnhGraph g) { super(n, g); } This works nicely for polymorphic purposes, but it also means that we cannot pass extra arguments

Use PREFIXes by default

When querying Fuseki, is it possible to have it use all prefixes by default without having to specify them all the time with "PREFIX ..."? What I have in mind is something like this: - have a list of default PREFIXes, somewhere in the Fuseki config files - send queries without any PREFIX

Re: Vocabulary for provenance

I would avoid anonymous nodes as they are just to hard to work with when trying to manage the data using SPARQL endpoints. On the other hand if you never produce a SPARQL endpoint this is not an issue. On the third hand, I always find project grow beyond what I first envisioned and SPARQL makes