Re: SPARQL1.1 query over Virtuoso repository through Jena

[Rob Vesse]

Yes I thought you guys did support them

Of course the actual user has yet to tell us any version information
(either Jena, Virtuoso or the Virtuoso Jena Provider) nor have they
provided us an error message so we¹re all really just speculating here.

Anila - Please can you confirm your versions for all components and
provide the error message you get otherwise we cannot help you further

Regards,

Rob

On 10/04/2014 16:41, "Hugh Williams"  wrote:

>Hi Andy
>
>The Virtuoso Jena Provider was updated last year to support Jena 2.10 and
>has also been tested with the latest Jena 2.11 release available for
>download.
>
>Virtuoso does support SPARQL 1.1 Property Paths as indicated at:
>
>   
> http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTri
>cksSPARQL11PropertyPaths
>
>The query is using the property path "+" unary operator which is standard
>SPARQL 1.1 I believe ?
>
>Best Regards
>Hugh Williams
>Professional Services
>OpenLink Software, Inc.  //  http://www.openlinksw.com/
>Weblog   -- http://www.openlinksw.com/blogs/
>LinkedIn -- http://www.linkedin.com/company/openlink-software/
>Twitter  -- http://twitter.com/OpenLink
>Google+  -- http://plus.google.com/100570109519069333827/
>Facebook -- http://www.facebook.com/OpenLinkSoftware
>Universal Data Access, Integration, and Management Technology Providers
>
>On 10 Apr 2014, at 18:29, Andy Seaborne  wrote:
>
>> On 10/04/14 16:12, Rob Vesse wrote:
>>> The Jena SPARQL parser is actually generated from the same grammar that
>>> was used to generate the grammar in the official specification so yes
>>>we
>>> fully support SPARQL 1.1 and have done for all releases in the past
>>> year/so.
>>> 
>>> Rob
>> 
>> Right!
>> 
>> The version of Jena used by Virtuoso in their adapter has been reported
>>to be quite old.
>> 
>> However, in this case the problem looks like it is because Virtuoso is
>>not SPARQL 1.1 compliant.  It does not support property paths.  They
>>have their own syntax.
>> 
>>  Andy
>> 
>>> 
>>> On 10/04/2014 03:43, "Hugh Williams"  wrote:
>>> 
 Hi
 
 See the following Virtuoso Jena Provider documentation link on how to
by
 the Jena/ARQ parser:
 
 
http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtJenaPro
vid
 er#Bypass%20Jena/ARQ%20parser
 
 As if the query runs against the Virtuoso SPARQL endpoint or directly
 from "isql" then you should be able to get it to run via Jena by
 "bypassing" its parser, assuming that is what is generating the yet
to be
 seen error.
 
 Having said that I would have thought the latest Jena versions are
SPARQL
 1.1 compliant ?
 
 Best Regards
 Hugh Williams
 Professional Services
 OpenLink Software, Inc.  //
http://www.openlinksw.com/
 Weblog   -- http://www.openlinksw.com/blogs/
 LinkedIn -- http://www.linkedin.com/company/openlink-software/
 Twitter  -- http://twitter.com/OpenLink
 Google+  -- http://plus.google.com/100570109519069333827/
 Facebook -- http://www.facebook.com/OpenLinkSoftware
 Universal Data Access, Integration, and Management Technology
Providers
 
 On 10 Apr 2014, at 10:18, Olivier Rossel 
wrote:
 
> I have had some problems with a very old ARQ library version I am
>stuck
> with.
> The parser was not understanding some SPARQL1.1 statements.
> 
> Andy proposed to upgrade ARQ to the latest version.
> Or to send the query directy via HTTP without using the Jena helpful
> functions.
> I took the second option.
> My code went from this:
> Query query = QueryFactory.create(queryString);
> QueryExecution qexec = QueryExecutionFactory.sparqlService(service,
> query);
> ResultSet resultSet = qexec.execSelect();
> 
> to this:
> QueryExecution qexec = new QueryEngineHTTP(service, queryString);
> ResultSet resultSet = qexec.execSelect();
> 
> 
> Hope it helps...
> 
> 
> 
> On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer 
> wrote:
> 
>> On 10/04/14 06:15, Anila Sahar Butt wrote:
>>> PREFIX csiro:
>>> PREFIX rdfs:
>>> PREFIX owl:
>>> PREFIX rdf:
>>> 
>>> SELECT ?property ?propLabel ?range ?rangeLabel
>>> WHERE {{{ rdfs:subClassOf+ ?res.
>>>?res
>>> owl:onProperty ?property.} UNION
>>>{{
>>> rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION
>>> {?property
>>> rdfs:domain }} } {{?res ?resProp
>>> ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
>>> owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}}
>>>OPTIONAL
>>> {?property rdfs:label ?propLabel.} Optional {?range rd

Re: SDB to TDB transition

[Rob Vesse]

Hi David

So the first think to point out which may make things tricky for you is
that TDB can only be accessed from a single JVM at a single time.  This is
due to the fact that  it uses memory mapped files, journaling and caching
so if you try and use it from multiple JVMs you are almost guaranteed to
corrupt your data.

However the workaround for this is to introduce Fuseki into your
architecture as your database server.  Fuseki can serve up TDB datasets
and clients then access them over HTTP.

If you use the standard APIs for remote query
(QueryExecutionFactory.sparqlService()), remote update
(UpdateExecutionFactory.createRemote()) and remote graph access
(DatasetAccessorFactory.createHTTP()) then your application can actually
be refactored to be agnostic of the backend and you can always switch out
Fuseki+TDB for another SPARQL compliant server if necessary.

With Fuseki+TDB being able to query the union graph can either be done at
the server configuration level or by specifying a magic graph URI in your
queries -  though continuing to use this feature
will make it harder to migrate off Fuseki+TDB should you ever need to
since this feature goes beyond standard SPARQL.

I don¹t see why you can¹t keep your interaction roughly the same as you
have it now you would merely need to change the underlying implementation.
 Of course if your operations are mostly coarse-grained I.e. in terms of
graphs then the DatasetAccessor API may actually cover much of what you
need which would make your implementation fairly trivial.

Hope this is enough to get you started, please feel free to ask further
questions or for clarifications as you explore this,

Cheers,

Rob

On 10/04/2014 12:09, "Lebling, David (US SSA)"
 wrote:

>I am looking at finally biting the bullet and transitioning from SDB to
>TDB. The first step is to come up with a level-of-effort estimate to see
>if this fits in our budget.
>
>We are using Jena 2.11.0 and SDB 1.4.0. We have a set of five web
>services (which can be in separate JVMs) that use SDB as an OWL storage
>device. The items  stored are named graphs. These are read, modified in
>memory (sometimes through inference, sometimes though pure Java code
>adding and removing and modifying statements), and written back out. We
>also use SPARQL queries on the union graph to find graphs of interest.
>Although currently there are a fairly small number of these named graphs,
>we want to be able to expand the system to hold a much larger number. One
>of the stumbling blocks with SDB was a bug in its multi-JVM concurrency
>code that wasn't fixed due to lack of SDB support.
>
>All interactions with the SDB database are through a single class which
>implements an interface with read, write, delete, find, etc. on named
>graphs and open and close on the database itself.
>
>Any advice on how to go about architecting and implementing a TDB version
>of the above would be appreciated. More details can be supplied if
>needed, of course.
>
>Thanks,
>
>Dave Lebling
>

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Hugh Williams]

Hi Andy

The Virtuoso Jena Provider was updated last year to support Jena 2.10 and has 
also been tested with the latest Jena 2.11 release available for download.

Virtuoso does support SPARQL 1.1 Property Paths as indicated at:


http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksSPARQL11PropertyPaths

The query is using the property path "+" unary operator which is standard 
SPARQL 1.1 I believe ?

Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc.  //  http://www.openlinksw.com/
Weblog   -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter  -- http://twitter.com/OpenLink
Google+  -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

On 10 Apr 2014, at 18:29, Andy Seaborne  wrote:

> On 10/04/14 16:12, Rob Vesse wrote:
>> The Jena SPARQL parser is actually generated from the same grammar that
>> was used to generate the grammar in the official specification so yes we
>> fully support SPARQL 1.1 and have done for all releases in the past
>> year/so.
>> 
>> Rob
> 
> Right!
> 
> The version of Jena used by Virtuoso in their adapter has been reported to be 
> quite old.
> 
> However, in this case the problem looks like it is because Virtuoso is not 
> SPARQL 1.1 compliant.  It does not support property paths.  They have their 
> own syntax.
> 
>   Andy
> 
>> 
>> On 10/04/2014 03:43, "Hugh Williams"  wrote:
>> 
>>> Hi
>>> 
>>> See the following Virtuoso Jena Provider documentation link on how to by
>>> the Jena/ARQ parser:
>>> 
>>> 
>>> http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtJenaProvid
>>> er#Bypass%20Jena/ARQ%20parser
>>> 
>>> As if the query runs against the Virtuoso SPARQL endpoint or directly
>>> from "isql" then you should be able to get it to run via Jena by
>>> "bypassing" its parser, assuming that is what is generating the yet to be
>>> seen error.
>>> 
>>> Having said that I would have thought the latest Jena versions are SPARQL
>>> 1.1 compliant ?
>>> 
>>> Best Regards
>>> Hugh Williams
>>> Professional Services
>>> OpenLink Software, Inc.  //  http://www.openlinksw.com/
>>> Weblog   -- http://www.openlinksw.com/blogs/
>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>> Twitter  -- http://twitter.com/OpenLink
>>> Google+  -- http://plus.google.com/100570109519069333827/
>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>> Universal Data Access, Integration, and Management Technology Providers
>>> 
>>> On 10 Apr 2014, at 10:18, Olivier Rossel  wrote:
>>> 
 I have had some problems with a very old ARQ library version I am stuck
 with.
 The parser was not understanding some SPARQL1.1 statements.
 
 Andy proposed to upgrade ARQ to the latest version.
 Or to send the query directy via HTTP without using the Jena helpful
 functions.
 I took the second option.
 My code went from this:
 Query query = QueryFactory.create(queryString);
 QueryExecution qexec = QueryExecutionFactory.sparqlService(service,
 query);
 ResultSet resultSet = qexec.execSelect();
 
 to this:
 QueryExecution qexec = new QueryEngineHTTP(service, queryString);
 ResultSet resultSet = qexec.execSelect();
 
 
 Hope it helps...
 
 
 
 On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer 
 wrote:
 
> On 10/04/14 06:15, Anila Sahar Butt wrote:
>> PREFIX csiro:
>> PREFIX rdfs:
>> PREFIX owl:
>> PREFIX rdf:
>> 
>> SELECT ?property ?propLabel ?range ?rangeLabel
>> WHERE {{{ rdfs:subClassOf+ ?res. ?res
>> owl:onProperty ?property.} UNION {{
>> rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION
>> {?property
>> rdfs:domain }} } {{?res ?resProp
>> ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
>> owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
>> {?property rdfs:label ?propLabel.} Optional {?range rdfs:label
>> ?rangeLabel.}}
> 
> I just tried this using the sparql.org validator (which uses jena) and
> it's fine.
> 
> What error are you getting?
> 
> Damian
> 
>>> 
>> 
>> 
>> 
>> 
> 

SDB to TDB transition

[Lebling, David (US SSA)]

I am looking at finally biting the bullet and transitioning from SDB to TDB. 
The first step is to come up with a level-of-effort estimate to see if this 
fits in our budget.

We are using Jena 2.11.0 and SDB 1.4.0. We have a set of five web services 
(which can be in separate JVMs) that use SDB as an OWL storage device. The 
items  stored are named graphs. These are read, modified in memory (sometimes 
through inference, sometimes though pure Java code adding and removing and 
modifying statements), and written back out. We also use SPARQL queries on the 
union graph to find graphs of interest. Although currently there are a fairly 
small number of these named graphs, we want to be able to expand the system to 
hold a much larger number. One of the stumbling blocks with SDB was a bug in 
its multi-JVM concurrency code that wasn't fixed due to lack of SDB support.

All interactions with the SDB database are through a single class which 
implements an interface with read, write, delete, find, etc. on named graphs 
and open and close on the database itself.

Any advice on how to go about architecting and implementing a TDB version of 
the above would be appreciated. More details can be supplied if needed, of 
course.

Thanks,

Dave Lebling

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Andy Seaborne]

On 10/04/14 16:12, Rob Vesse wrote:

The Jena SPARQL parser is actually generated from the same grammar that
was used to generate the grammar in the official specification so yes we
fully support SPARQL 1.1 and have done for all releases in the past
year/so.

Rob


Right!

The version of Jena used by Virtuoso in their adapter has been reported 
to be quite old.


However, in this case the problem looks like it is because Virtuoso is 
not SPARQL 1.1 compliant.  It does not support property paths.  They 
have their own syntax.


Andy



On 10/04/2014 03:43, "Hugh Williams"  wrote:


Hi

See the following Virtuoso Jena Provider documentation link on how to by
the Jena/ARQ parser:


http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtJenaProvid
er#Bypass%20Jena/ARQ%20parser

As if the query runs against the Virtuoso SPARQL endpoint or directly
from "isql" then you should be able to get it to run via Jena by
"bypassing" its parser, assuming that is what is generating the yet to be
seen error.

Having said that I would have thought the latest Jena versions are SPARQL
1.1 compliant ?

Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc.  //  http://www.openlinksw.com/
Weblog   -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter  -- http://twitter.com/OpenLink
Google+  -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

On 10 Apr 2014, at 10:18, Olivier Rossel  wrote:


I have had some problems with a very old ARQ library version I am stuck
with.
The parser was not understanding some SPARQL1.1 statements.

Andy proposed to upgrade ARQ to the latest version.
Or to send the query directy via HTTP without using the Jena helpful
functions.
I took the second option.
My code went from this:
Query query = QueryFactory.create(queryString);
QueryExecution qexec = QueryExecutionFactory.sparqlService(service,
query);
ResultSet resultSet = qexec.execSelect();

to this:
QueryExecution qexec = new QueryEngineHTTP(service, queryString);
ResultSet resultSet = qexec.execSelect();


Hope it helps...



On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer 
wrote:


On 10/04/14 06:15, Anila Sahar Butt wrote:

PREFIX csiro:
PREFIX rdfs:
PREFIX owl:
PREFIX rdf:

SELECT ?property ?propLabel ?range ?rangeLabel
WHERE {{{ rdfs:subClassOf+ ?res. ?res
owl:onProperty ?property.} UNION {{
rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION
{?property
rdfs:domain }} } {{?res ?resProp
?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
{?property rdfs:label ?propLabel.} Optional {?range rdfs:label
?rangeLabel.}}


I just tried this using the sparql.org validator (which uses jena) and
it's fine.

What error are you getting?

Damian

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Rob Vesse]

The Jena SPARQL parser is actually generated from the same grammar that
was used to generate the grammar in the official specification so yes we
fully support SPARQL 1.1 and have done for all releases in the past
year/so.

Rob

On 10/04/2014 03:43, "Hugh Williams"  wrote:

>Hi 
>
>See the following Virtuoso Jena Provider documentation link on how to by
>the Jena/ARQ parser:
>
>   
> http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtJenaProvid
>er#Bypass%20Jena/ARQ%20parser
>
>As if the query runs against the Virtuoso SPARQL endpoint or directly
>from "isql" then you should be able to get it to run via Jena by
>"bypassing" its parser, assuming that is what is generating the yet to be
>seen error. 
>
>Having said that I would have thought the latest Jena versions are SPARQL
>1.1 compliant ?
>
>Best Regards
>Hugh Williams
>Professional Services
>OpenLink Software, Inc.  //  http://www.openlinksw.com/
>Weblog   -- http://www.openlinksw.com/blogs/
>LinkedIn -- http://www.linkedin.com/company/openlink-software/
>Twitter  -- http://twitter.com/OpenLink
>Google+  -- http://plus.google.com/100570109519069333827/
>Facebook -- http://www.facebook.com/OpenLinkSoftware
>Universal Data Access, Integration, and Management Technology Providers
>
>On 10 Apr 2014, at 10:18, Olivier Rossel  wrote:
>
>> I have had some problems with a very old ARQ library version I am stuck
>> with.
>> The parser was not understanding some SPARQL1.1 statements.
>> 
>> Andy proposed to upgrade ARQ to the latest version.
>> Or to send the query directy via HTTP without using the Jena helpful
>> functions.
>> I took the second option.
>> My code went from this:
>> Query query = QueryFactory.create(queryString);
>> QueryExecution qexec = QueryExecutionFactory.sparqlService(service,
>>query);
>> ResultSet resultSet = qexec.execSelect();
>> 
>> to this:
>> QueryExecution qexec = new QueryEngineHTTP(service, queryString);
>> ResultSet resultSet = qexec.execSelect();
>> 
>> 
>> Hope it helps...
>> 
>> 
>> 
>> On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer 
>>wrote:
>> 
>>> On 10/04/14 06:15, Anila Sahar Butt wrote:
 PREFIX csiro:
 PREFIX rdfs:
 PREFIX owl:
 PREFIX rdf:
 
 SELECT ?property ?propLabel ?range ?rangeLabel
 WHERE {{{ rdfs:subClassOf+ ?res. ?res
 owl:onProperty ?property.} UNION {{
 rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION
{?property
 rdfs:domain }} } {{?res ?resProp
 ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
 owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
 {?property rdfs:label ?propLabel.} Optional {?range rdfs:label
 ?rangeLabel.}}
>>> 
>>> I just tried this using the sparql.org validator (which uses jena) and
>>> it's fine.
>>> 
>>> What error are you getting?
>>> 
>>> Damian
>>> 
>

Re: Comparing xsd:date/time with different time zones

[Rob Walpole]

We hit this exact problem a while ago...

Basically if no timezone is specified then it takes the max and min
possible timezone difference, i.e. +14 hours and -14 hours, and for
anything that falls within this block of time no comparison can be made.

The best solution is just to add the timezone information. However
retrospectively adding timezone information is a challenge in it's own
right! The lesson for us is to always use timezones.

Rob

Rob


On Tue, Apr 8, 2014 at 10:21 AM, Andy Seaborne  wrote:

> On 08/04/14 01:38, Holger Knublauch wrote:
>
>> Hi all,
>>
>> we noticed a change in behavior between the recent Jena versions.
>>
>
> Between which versions?
>
>
>
>> SELECT *
>> WHERE {
>>  BIND("2014-04-08T00:00:00"^^xsd:dateTime AS ?time0) .
>>  BIND("2014-04-08T00:00:00+10:00"^^xsd:dateTime AS ?time1) .
>>  BIND(xsd:date(?time0) AS ?date0) .
>>  BIND(xsd:date(?time1) AS ?date1) .
>>  BIND(?date0 > ?date1 AS ?compare)
>> }
>>
>> With Jena 2.11 ?compare is unbound, indicating that it is impossible to
>> compare times or dates that have a different time zone.
>>
>
> "2014-04-08T00:00:00"^^xsd:dateTime does not have a timezone.
>
> No timezone is not the same as different timezone.
>
>
>  Is this the expected behavior? Shouldn't it in theory figure out the
>> time zones itself (e.g. by aligning all to a universal time zone)
>> instead of failing?
>>
>
> See the XSD F&O spec for comparing dateTimes with and without timezones.
>
> 14 is a magic number.
>
>
>  What would be a work-around to do this "manually" for data that is
>> stored in mixed time zones?
>>
>
> Be careful.
>
> The problem is that the data publisher and the query engine (and indeed
> the client asking the query) may be in different timezones so defaulting a
> timezone does not make sense on the web.
>
> There is nothing special about Z.
>
> Andy
>
> PS Please use the users@jena.apache.org mailing list, not the incubator
> one.
>
>
>> Thanks
>> Holger
>>
>>
>


-- 

Rob Walpole
Email robkwalp...@gmail.com
Tel. +44 (0)7969 869881
Skype: RobertWalpolehttp://www.linkedin.com/in/robwalpole

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Hugh Williams]

Hi 

See the following Virtuoso Jena Provider documentation link on how to by the 
Jena/ARQ parser:


http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtJenaProvider#Bypass%20Jena/ARQ%20parser

As if the query runs against the Virtuoso SPARQL endpoint or directly from 
"isql" then you should be able to get it to run via Jena by "bypassing" its 
parser, assuming that is what is generating the yet to be seen error. 

Having said that I would have thought the latest Jena versions are SPARQL 1.1 
compliant ?

Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc.  //  http://www.openlinksw.com/
Weblog   -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter  -- http://twitter.com/OpenLink
Google+  -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

On 10 Apr 2014, at 10:18, Olivier Rossel  wrote:

> I have had some problems with a very old ARQ library version I am stuck
> with.
> The parser was not understanding some SPARQL1.1 statements.
> 
> Andy proposed to upgrade ARQ to the latest version.
> Or to send the query directy via HTTP without using the Jena helpful
> functions.
> I took the second option.
> My code went from this:
> Query query = QueryFactory.create(queryString);
> QueryExecution qexec = QueryExecutionFactory.sparqlService(service, query);
> ResultSet resultSet = qexec.execSelect();
> 
> to this:
> QueryExecution qexec = new QueryEngineHTTP(service, queryString);
> ResultSet resultSet = qexec.execSelect();
> 
> 
> Hope it helps...
> 
> 
> 
> On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer  wrote:
> 
>> On 10/04/14 06:15, Anila Sahar Butt wrote:
>>> PREFIX csiro:
>>> PREFIX rdfs:
>>> PREFIX owl:
>>> PREFIX rdf:
>>> 
>>> SELECT ?property ?propLabel ?range ?rangeLabel
>>> WHERE {{{ rdfs:subClassOf+ ?res. ?res
>>> owl:onProperty ?property.} UNION {{
>>> rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION {?property
>>> rdfs:domain }} } {{?res ?resProp
>>> ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
>>> owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
>>> {?property rdfs:label ?propLabel.} Optional {?range rdfs:label
>>> ?rangeLabel.}}
>> 
>> I just tried this using the sparql.org validator (which uses jena) and
>> it's fine.
>> 
>> What error are you getting?
>> 
>> Damian
>> 

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Olivier Rossel]

I have had some problems with a very old ARQ library version I am stuck
with.
The parser was not understanding some SPARQL1.1 statements.

Andy proposed to upgrade ARQ to the latest version.
Or to send the query directy via HTTP without using the Jena helpful
functions.
I took the second option.
My code went from this:
Query query = QueryFactory.create(queryString);
QueryExecution qexec = QueryExecutionFactory.sparqlService(service, query);
ResultSet resultSet = qexec.execSelect();

to this:
QueryExecution qexec = new QueryEngineHTTP(service, queryString);
ResultSet resultSet = qexec.execSelect();


Hope it helps...



On Thu, Apr 10, 2014 at 10:31 AM, Damian Steer  wrote:

> On 10/04/14 06:15, Anila Sahar Butt wrote:
> > PREFIX csiro:
> > PREFIX rdfs:
> > PREFIX owl:
> > PREFIX rdf:
> >
> > SELECT ?property ?propLabel ?range ?rangeLabel
> > WHERE {{{ rdfs:subClassOf+ ?res. ?res
> > owl:onProperty ?property.} UNION {{
> > rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION {?property
> > rdfs:domain }} } {{?res ?resProp
> > ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
> > owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
> > {?property rdfs:label ?propLabel.} Optional {?range rdfs:label
> > ?rangeLabel.}}
>
> I just tried this using the sparql.org validator (which uses jena) and
> it's fine.
>
> What error are you getting?
>
> Damian
>

Re: SPARQL1.1 query over Virtuoso repository through Jena

[Damian Steer]

On 10/04/14 06:15, Anila Sahar Butt wrote:
> PREFIX csiro:
> PREFIX rdfs:
> PREFIX owl:
> PREFIX rdf:
> 
> SELECT ?property ?propLabel ?range ?rangeLabel
> WHERE {{{ rdfs:subClassOf+ ?res. ?res
> owl:onProperty ?property.} UNION {{
> rdfs:subClassOf+ ?class. ?property rdfs:domain ?class.} UNION {?property
> rdfs:domain }} } {{?res ?resProp
> ?range.FILTER ((?resProp = owl:allValuesFrom) || (?resProp =
> owl:someValuesFrom) )} UNION {?property rdfs:range ?range.}} OPTIONAL
> {?property rdfs:label ?propLabel.} Optional {?range rdfs:label
> ?rangeLabel.}}

I just tried this using the sparql.org validator (which uses jena) and
it's fine.

What error are you getting?

Damian

Re: Inferencing on TDB

[Dave Reynolds]

riodcmd.infer is for streaming RDFS inference, not general rule processing.

The rulemap command will run general rules. It doesn't know about TDB or 
assemblers but will work from files. The rule processing is memory 
limited anyway. Having generated your closure file you can then load it 
into TDB how you wish.


Alternatively you could write a short program to do the inference direct 
from the TDB (won't be any faster) and put the results where you want them.


Dave

On 08/04/14 14:16, Harkishan Singh wrote:

Hi,

I have created TDB which stores bulky data.
Now I have some rules and I want to apply these rules on tdb.

This is my assembler file:

@prefix : .
@prefix rdf:  .
@prefix rdfs: .
@prefix tdb:  .
@prefix ja:   .
@prefix text: .
@prefix dc:   .
@prefix nfo: 
.
@prefix nie: 
.
@prefix skos: .
@prefix dita:  .



[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
tdb:GraphTDB rdfs:subClassOf ja:Model .

<#dataset>  rdf:type ja:RDFDataset ;
  ja:defaultGraph<#infModel>  .

<#infModel>  a ja:InfModel ;
   ja:baseModel<#tdbGraph>;
ja:reasoner
[ja:rule "[r1: (?bt rdf:type dc:Document) ,(?doc foaf:topic ?bt
),(?doc dc:title ?name) -> (?bt predicate ?name)]"] .

<#tdbGraph>  rdf:type tdb:GraphTDB ;
 tdb:location "DB" ;


Now I want to run the infer command (riotcmd.infer --rdfs VOCAB FILE
FILE...)which I got from this link -
http://jena.apache.org/documentation/io/

The problem is :
1)I'm not able to make out what parameters to pass in above command.
2)After applying the rules, inferred results will be merged into a tdb or
if I want to store inferred results in a separate file then what additional
configurations I have to do?


Thanks a lot! Hope you can help.