arq

UNION and intersection using SPARQL queries

由 末鹿安然 提交于 2020-01-15 07:22:06
问题 I am converting user-defined-queries into SPARQL. For example, when user says, "abc", it means give me all nodes of a given type which have some attribute named "abc". As an extension of this, if user says, "abc or (pqr and lmn)", I need to find all nodes of a given type for which some attribute is "abc or (pqr and lmn)". Following is the query I have come up with: SELECT DISTINCT ?node, ?type WHERE { { ?node a ?type . FILTER ( ?type != <sometype>) } { { ?node ?reln0 ?obj0 . FILTER ( regex

Handle more than one OWL files in a same JENA application

由 眉间皱痕 提交于 2019-12-11 07:55:52
问题 I am making an application which may require about 2-3 OWL files to work with, in order to serve different task for the same application. I am using Jena as my semantic web framework. My question is: How do we organize/setup these owl files? Should I read all the owl files in the same dataset or I should maintain different datasets for different owls. Note: I am not considering the Imported owls as it is handled by jena itself. If I use same dataset, how can I differentiate to between he

Can't PREFIX hierarchies with SPARQL

由 一笑奈何 提交于 2019-12-06 08:52:40
问题 I have a need to represent a hierarchy in my URL's like this: http://www.me.org/ -----------------root1/ -----------------------level1/ ------------------------------level2/etc I want to define PREFIX's and used them in a SPARQL query like this: PREFIX root1: <http://www.me.org/root1/> select * where { ?s ?p root1:level1/level2/etc . } limit 100 This will fail in ARQ with the following error: Encountered " "/" "/ "" at line 10, column 43. Was expecting one of: "values" ... "graph" ... ...

tbloader vs SPARQL INSERT - Why different behaviour with named graphs?

由 时光毁灭记忆、已成空白 提交于 2019-12-01 18:49:53
There is a strange behaviour in the connection of the commandline tools of ARQ, TDB and Named Graphs. If importing data via tdbloader in a named graph it can not be queried via GRAPH clause in a SPARQL SELECT query. However, this query is possible when inserting the data in the same graph with SPARQL INSERT. I have following assembler description file tdb.ttl : @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> . @prefix tdb: <http://jena.hpl.hp.com/2008/tdb#> . [] ja

tbloader vs SPARQL INSERT - Why different behaviour with named graphs?

由 心不动则不痛 提交于 2019-12-01 17:14:49
问题 There is a strange behaviour in the connection of the commandline tools of ARQ, TDB and Named Graphs. If importing data via tdbloader in a named graph it can not be queried via GRAPH clause in a SPARQL SELECT query. However, this query is possible when inserting the data in the same graph with SPARQL INSERT. I have following assembler description file tdb.ttl : @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix ja:

How to write SPARQL query that efficiently matches string literals while ignoring case

由 我们两清 提交于 2019-11-30 07:25:43
问题 I am using Jena ARQ to write a SPARQL query against a large ontology being read from Jena TDB in order to find the types associated with concepts based on rdfs label: SELECT DISTINCT ?type WHERE { ?x <http://www.w3.org/2000/01/rdf-schema#label> "aspirin" . ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type . } This works pretty well and is actually quite speedy (<1 second). Unfortunately, for some terms, I need to perform this query in a case-insensitive way. For instance, because the

How to write SPARQL query that efficiently matches string literals while ignoring case

由 回眸只為那壹抹淺笑 提交于 2019-11-29 03:33:28
I am using Jena ARQ to write a SPARQL query against a large ontology being read from Jena TDB in order to find the types associated with concepts based on rdfs label: SELECT DISTINCT ?type WHERE { ?x <http://www.w3.org/2000/01/rdf-schema#label> "aspirin" . ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type . } This works pretty well and is actually quite speedy (<1 second). Unfortunately, for some terms, I need to perform this query in a case-insensitive way. For instance, because the label "Tylenol" is in the ontology, but not "tylenol" , the following query comes up empty: SELECT
订阅 arq