query support in fuseki

[Tim Harsch <ha...@yahoo.com>]

I noticed some code in Fuseki that will throw error if a query contains FROM/FROM NAMED clauses.  I think it makes sense given it is Sparql 1.1 SOH protocol and since you specify the dataset in your call you can't do it in the FROM/FROM NAMED clauses too.  But, does that mean that Fuseki will never deprecate Joseki since in order to query multiple data sets you would need FROM/FROM NAMED clauses in the query and only Joseki would support that?  Or will/does Fuseki support standard Sparql endpoint semantics as well?

Tim


      

vocabulary class pattern

[Frank Budinsky <fr...@ca.ibm.com>]

Hi,

I noticed that there are two different patterns being used for classes in
the jena.vocabulary package.

Class RDF, for example, creates the Property and Resource objects using
ResourceFactory static methods:

    ResourceFactory.createResource( uri + local );
    ResourceFactory.createProperty( uri, local );

Class DCTerms, on the other hand, creates a default model and uses it to
create them. For example:

    m_model.createProperty( "http://purl.org/dc/terms/accrualMethod" );

Is there a reason why these classes do it differently, and if so, is one
pattern better than the other if I want to create a similar class for my
own model?

Thanks,
Frank.

Re: query support in fuseki

[Andy Seaborne <an...@epimorphics.com>]

On 04/02/11 23:04, Tim Harsch wrote:
> I noticed some code in Fuseki that will throw error if a query
> contains FROM/FROM NAMED clauses.  I think it makes sense given it is
> Sparql 1.1 SOH protocol and since you specify the dataset in your
> call you can't do it in the FROM/FROM NAMED clauses too.  But, does
> that mean that Fuseki will never deprecate Joseki since in order to
> query multiple data sets you would need FROM/FROM NAMED clauses in
> the query and only Joseki would support that?  Or will/does Fuseki
> support standard Sparql endpoint semantics as well?

Fuseki provides the ability to publish and update datasets on the web. 
Mostly it's one dataset (and the current command line only handled one 
dataset but internally it looks up any incoming request and directs it 
to the right dataset).

That's one feature Joseki currently has that Fuseki has not expose.  Yet.

The reason you get an error if you use FROM/FROM NAMED is because it's 
publishing a dataset.  Normally FROM/FROM NAMED means load (using HTTP 
GET) the graphs named, create a dataset and query it. That's what the 
/sparql service (joseki:ProcessorSPARQL) does.  It offers a general 
purpose query service, which is not offering query over a dataset but 
enables the loading of graphs into a dataset.  Some people use 
sparql.org/sparql for this - not that I can guarantee it's up and
running.

Fuseki is running like joseki:ProcessorSPARQL_FixedDS.  This standard 
SPARQl behaviour - in fact, most other systems only offer this behaviour 
because they provide access to the data stored behind them.

It can be a bit expensive and opens up certain issues of reducing 
service to other datasets by hitting the server with work to load data. 
  By the way, Joseki has a built in 50K triple limit on any data it 
loads to reduce accidents.  There's no reason why another service 
couldn't be added to Fuseki to do that.

GRAPH is the SPARQL keyword to pick one graph in the dataset.

It would be possible to enable the other behaviour of FROM/FROM NAMED 
for TDB:

http://openjena.org/wiki/TDB/DynamicDatasets

which is useful for the effect of default graph (select a few from many, 
merge and query, except it does not actually merge the data) and GRAPH ?g.

And you can do the FROM/FROM NAMED thing with the ARQ command line tools.

	Andy