Filter points within a polygon - indexing

i have a problem with GeoSparql.
I set a quadratic polygon and points that are in a database.
I want to return the polygon and the points that are in it, using
the GeoSparql function sfContains and sfWithin functions but they return 0 results.
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix geosp: <http://www.opengis.net/ont/geosparql#>
prefix geo-ont: <http://www.opengis.net/ont/sf#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
?polygon geosp:asWKT ?polygonCoordinates.
?polygon rdf:type geo-ont:Polygon
?point geosp:asWKT ?pointCoordinates .
?point rdf:type geo-ont:Point .
# FILTER(geof:sfContains(?polygonCoordinates, ?pointCoordinates)) .
# FILTER(geof:sfWithin(?pointCoordinates, ?polygonCoordinates)) .
# FILTER(geof:sfWithin(?pointCoordinates,"Polygon((41.2858646433522 24.571734341826, 41.5858646433522 24.771734341826 ,41.2858646433522 24.571734341826))"^^geosp:asWKT))
Maybe I'm not building a proper geospatial index.
Please give a hint how to solve the problem or explanation where it could be.
Thanks in advance.
Stanko

Related

Construct loop in SPARQL

The following SPARQL query
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix skos: <http://www.w3.org/2004/02/skos/core#>
prefix msc: <http://msc.org/resources/MSC/msc2020/>
construct {?s skos:broader msc:00-XX . }
where
{
?s a skos:Concept ; skos:notation ?notation.
filter regex (?notation, "00-\d\d")
}
searches all notations 00-01, 00-02, etc. and constructs a relation to the top level class 00-XX. However, this is only the first of 63 top level classes altogether, so I would like to "loop" over all top level classes automatically. On top, I would like to adapt this to other patterns. Is there a way to do this with SPARQL? If not, what would you recommend instead?
In the meantime we found a solution without SPARQL.
The SPARQL CONSTRUCT query was supposed to create a skos:broader relation between a skos:Concept with a notation like "00-01" (and all other concepts with 00-\d\d notation) and its proper subordinate concept, which for 00-01 is the skos:Concept with the notation 00-XX.
The data originate from a table and Open Refine is much faster in creating the skos:broader statements than using the SPARQL query proposed above and adjusting it to other notation patterns.
We use GREL's value.replace on the cells with the notations to create a new column:
value.replace(/-\d\d/, "-XX").replace(/\d\d>/, "xx>")
The two replacements give us the notation of the original notation's superordinate concept in one step. The second replace already adapts to the other patterns mentioned in the question (e.g. 00A01).
With the original notation and the value in the new column, we can easily create the skos:broader triples by concatenating text and the values from both columns. These can then be exported from OpenRefine and just be copy-pasted to our SKOS vocabulary.
Here is a SPARQL answer based on the query in the question. Using filters and regex (as suggested in the comment by Yahalnaut as a reply to UninforomedUser above) is needed. Creating a skos:broader relation based on two concept's notations requires them to hava an identical sequence of digits before the - . The comparison should only between the first part of the notations, so each 00- should match another 00-but not a 01-. As asked, the solution below only considers topConcepts of the Vocabulary as potential objects for skos:broader. The concepts should also not relate to themselves, therefore the last filter. This should then be adoptable to other patterns as well. Depending on the number of Concepts and the memory available for the query, this may last a while or even stop before finished. It eliminates lot of the effort though.
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix skos: <http://www.w3.org/2004/02/skos/core#>
prefix msc: <http://msc.org/resources/MSC/msc2020/>
construct {?s skos:broader ?y . }
where {
?s a skos:Concept ; skos:notation ?notation.
?y skos:topConceptOf msc: ; skos:notation ?not2.
bind (REPLACE (?not2 , "-XX" , "") as ?1)
bind (REPLACE (?notation , "-\d\d", "" ) as ?2 )
filter (?1 = ?2)
filter (?not2 != ?notation)
}

skos broader and narrow inverse not working

I have setup GraphDB SE trial version and trying out inference functionality with OWL2-RL ruleset. I have built a simple SKOS knowledge with a single broader relationship. Some how, when I try to query for narrower relationship am not getting any results. Am I going wrong in the usage ?
Insertion:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
INSERT DATA {
ex:mammals rdf:type skos:Concept;
skos:prefLabel "mammals"#en;
ex:animals rdf:type skos:Concept;
skos:prefLabel "animals"#en;
skos:broader ex:mammals .
}
Query:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
select * where {
?s skos:narrower ?o .
}
In the query result I don't see any response. Shouldn't it return below result -
ex:mammals skos:narrower ex:animals
I just came across this question and the OP is correct: Although the official SKOS reference explicitly states that skos:broader and skos:narrower are inverse, the actual RDF implementation does not include this statement. However, properties skos:broaderTransitive and skos:narrowerTransitive are declared as inverse.
And, although not relevant to the original question, the implementation does not state properties skos:topConceptOf and skos:hasTopConcept as inverse either.

DBPedia-France (fr.dpbedia.org/sparql) query giving different result from a call to another

I'm calling on http://fr.dbpedia.org/sparql
the following SPARQL query:
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select distinct ?lcs where {
{
?lcs ^(rdf:type/rdfs:subClassOf*) <http://fr.dbpedia.org/resource/Honoré_Daumier> ,
<http://fr.dbpedia.org/resource/Auguste_Rodin>;
a owl:Class .
filter not exists {
?llcs ^(rdf:type/rdfs:subClassOf*) <http://fr.dbpedia.org/resource/Honoré_Daumier> ,
<http://fr.dbpedia.org/resource/Auguste_Rodin>;
a owl:Class ;
rdfs:subClassOf+ ?lcs .
}
}
}
On some call I've http://dbpedia.org/ontology/Person as result, on others call I'm getting http://dbpedia.org/ontology/Person and http://dbpedia.org/ontology/Agent and with others the previous answers plus http://www.w3.org/2002/07/owl#Thing
without nothing to know that a response isn't complete. How can I use the result, if it is a little randomized
The main reason for your query not working as expected is that the data the data is i) split into separate graphs and ii) not all graphs were added to the default graph.
To keep it short, the instance data is contained inside the graph http://fr.dbpedia.org whereas the schema triples will be accessible via http://dbpedia.org graph only. Sometimes, if no graph is given, then the union of some graphs is used as the default graph which will be the dataset at query time. Unfortunately, this doesn't hold for the French DBpedia endpoint, only the instance data graph will be used.
You can check this with
DESCRIBE <http://dbpedia.org/ontology/Person>
which is empty when using either no graph explicitly or the graph http://fr.dbpedia.org, but non-empty for graph http://dbpedia.org.
The way to define the default graph is using the keyword FROM. For your query, it should therefore be
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select distinct ?lcs
from <http://fr.dbpedia.org>
from <http://dbpedia.org>
where {
?lcs ^(rdf:type/rdfs:subClassOf*) <http://fr.dbpedia.org/resource/Honoré_Daumier> ,
<http://fr.dbpedia.org/resource/Auguste_Rodin>;
a owl:Class .
filter not exists {
?llcs ^(rdf:type/rdfs:subClassOf*) <http://fr.dbpedia.org/resource/Honoré_Daumier> ,
<http://fr.dbpedia.org/resource/Auguste_Rodin>;
a owl:Class ;
rdfs:subClassOf+ ?lcs .
}
}
Note, while this seems to return the correct result, you should also consider the comment from #TallTed regarding possible differences among language chapters (e.g. English vs French Wikipedia as source), release dumps (2016 vs 2018 or even the DBpedia Live) as well as Virtuoso versions used as backend.

SPARQL: using function bif:st_distance and bif:st_points do not work outside SERVICE

I'm trying to write a SPARQL request, where I want to query country names from my own dataset, use the dbpedia resource to retrieve the countrie's latitude and longitude and then calculate the distance among them with the bif:st_distance function. The latitude and longitude I want to use are floats, so I have to convert them to points with bif:st_point first, since the function takes points only.
On my local machine I'm running a apache jena-fuseki server with my dataset loaded. I tried the following:
PREFIX rate: <http://MYNAME.bplaced.net/rating/index.ttl#>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX bif: <bif:>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX afn: <http://jena.apache.org/ARQ/function#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?from ?to ?latituded ?longituded ?latitudeo ?longitudeo ?distance WHERE{
{SELECT ?from ?to (AVG(?latd) as ?latituded)
(AVG(?longd) as ?longituded)
(AVG(?lato) as ?latitudeo)
(AVG(?longo) as ?longitudeo) WHERE {
?rating rate:from dbr:Germany.
?rating rate:year "1965"^^xsd:gYear.
?rating rate:from ?from.
?rating rate:to ?to.
SERVICE <http://dbpedia.org/sparql>{
?from geo:lat ?latd.
?from geo:long ?longd.
?to geo:lat ?lato.
?to geo:long ?longo.
}
} GROUP BY ?from ?to
}
BIND(bif:st_distance(
bif:st_point(?latituded,?longituded),
bif:st_point(?latitudeo,?longitudeo)
)AS ?distance).
}
This leaves me with this result:
The query result
As you can see: The distance column remains empty. I am sure it has something to do with whether or not the BIND statement is located within the SERVICE. Might some values be invisible to the BIND?
What am I doing wrong or what can I do differently to solve this?
Thanks in advance!
The spatial functions in the bif namespace are specific to Virtuoso, the software used by DBpedia. Therefore they will only work in the SERVICE clause where the query is executed on the Virtuoso server. So either use these functions in the SERVICE clause or take a look at the Jena spatial functions.

SPARQL query and reasoning to get similar indviduals from two different ontologies

The first ontology has the following:
Issue Ontology members(classes):
<http://www.issueonto.com/ontologies/issues#issues>
<http://www.issueonto.com/ontologies/issues#products>
Predicate/Properties:
<http://www.issueonto.com/ontologies/issues#hasIssues>
Triple store for this ontology (raw data), I show it here in Turtle format:
#prefix : <http://www.issueonto.com/ontologies/issues#> .
#prefix owl: <http://www.w3.org/2002/07/owl#> .
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
#prefix xml: <http://www.w3.org/XML/1998/namespace> .
#prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
#prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
#base <http://www.issueonto.com/ontologies/issues> .
:Fido rdf:type :products ,
owl:NamedIndividual ;
:productName "FidoProdCEO_12"^^xsd:string ;
:hasIssues :issue_1239 .
### http://www.issueonto.com/ontologies/issues#issue_1239
:issue_1239 rdf:type :issues ,
owl:NamedIndividual ;
:issueName "FeatureIssue"^^xsd:string .
The Second ontology has the following:
Project Ontology members (classes):
<http://www.projectexample.com/ontology/project#GroupProject>
<http://www.projectexample.com/ontology/project#Project>
<http://www.projectexample.com/ontology/project#ProjectVersion>
Predicate/Properties:
<http://www.projectexample.com/ontology/project#belongsTo>
<http://www.projectexample.com/ontology/project#dependsOn>
Triple store for the ontology (raw data), I show it here in Turtle format:
#prefix : <http://www.projectexample.com/ontology/project#> .
#prefix owl: <http://www.w3.org/2002/07/owl#> .
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
#prefix xml: <http://www.w3.org/XML/1998/namespace> .
#prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
#prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
#base <http://www.projectexample.com/ontology/project> .
### http://www.projectexample.com/ontology/project#Apple
:Apple rdf:type :ProjectVersion ,
owl:NamedIndividual ;
:hasProjectName "AppleTowandOne"^^xsd:string ;
:belongsTo :RedBlueCompany .
### http://www.projectexample.com/ontology/project#Fido
:Fido rdf:type :ProjectVersion ,
owl:NamedIndividual ;
:hasProjectName "FidoProdCEO"^^xsd:string ;
:dependsOn :Apple .
### http://www.projectexample.com/ontology/project#RedBlueCompany
:RedBlueCompany rdf:type :GroupProject ,
owl:NamedIndividual ;
:groupName "RedGroupCompant lmt"^^xsd:string .
Question
1- I would like to say, project:projectversion from ontology project same as issues:product from ontology issues, is that possible and how?
2- if question (1) is yes, how could I infer the similar individuals from the shared concepts, i.e, if we say projectversion is same as product it does not mean all the individuals are similar, in the example, i would like to automatically infer the individual issues:Fido type of issue:products is same as the individual prject:Fido type of project:projectversion. From that inferred fact, i would infer automatically that project:Fido issue:hasissue issues:issues_1239. Finally, I would like to run SPARQL query as follow:
SELECT ?product ?issue FROM <namegraph>
WHERE{
?product issues:hasIssues ?issue.
}
The results that I should get as follow:
?product ?issue
--------------------------------------------------------------------------
<http://www.projectexample.com/ontology/project#Fido> <http://www.issueonto.com/ontologies/issues#issue_1239>
<http://www.issueonto.com/ontologies/issues#Fido> <http://www.issueonto.com/ontologies/issues#issue_1239>
I would like to say, project:projectversion from ontology project same
as issues:product from ontology issues, is that possible and how?
All you need is the triple
project:projectversion owl:equivalentClass issues:product
I don't know how you're combining these ontologies; whether you're just loading the data from both into a triple store, or creating a third ontology that imports both and loading that (along with its imports) into a triple store, but somewhere you need that axiom. For a "merging" ontology like this, I'd usually create a third ontology that imports both (but leaving them unchanged) and add the axiom to that third ontology.
2- if question (1) is yes, how could I infer the similar individuals
from the shared concepts, i.e, if we say projectversion is same as
product it does not mean all the individuals are similar, in the
example, i would like to automatically infer the individual
issues:Fido type of issue:products is same as the individual
prject:Fido type of project:projectversion. From that inferred fact, i
would infer automatically that project:Fido issue:hasissue
issues:issues_1239.
You still have told us what criteria you would use to decide that issues:Fido and project:Fido are the same individual. The only apparent similarity that they have is the strings "FidoProdCEO_12" and "FidoProdCEO". Is that what the decision is supposed to be based on? If so, then you could do something like the following. I've created a minimal amount of data for convenience:
#prefix o1: <urn:ex:ont1#> .
#prefix o2: <urn:ex:ont2#> .
#prefix owl: <http://www.w3.org/2002/07/owl#> .
o1:A a o1:Product ;
o1:productName "ProductA_1234" ;
o1:hasIssue o1:issue42 .
o2:B a o2:ProjectVersion ;
o2:projectName "ProductA" .
o1:Product owl:equivalentClass o2:ProjectVersion .
prefix o1: <urn:ex:ont1#>
prefix o2: <urn:ex:ont2#>
prefix owl: <http://www.w3.org/2002/07/owl#>
select ?product ?issue where {
#-- A *product* is something that's an instance of
#-- o1:Product or another class that's equivalent
#-- to it.
?product a/(owl:equivalentClass|^owl:equivalentClass)* o1:Product
#-- The issues of a product are any of its
#-- o1:hasIssue values, or the o1:hasIssue
#-- value of any product that has a name
#-- beginning with its o2:projectName.
{ ?product o1:hasIssue ?issue }
union
{ ?product o2:projectName ?projectName .
?_product o1:productName ?productName ;
o1:hasIssue ?issue .
filter strstarts(?productName,?projectName)
}
}
------------------------
| product | issue |
========================
| o2:B | o1:issue42 |
| o1:A | o1:issue42 |
------------------------
Of course, the fact that you still end up having to examine projectName and productName values means that the equivalent class axiom isn't actually buying you all that much (at least in terms of this query). That is, it would be sufficient to just ask for "products (and projects with matching names) and their issues." That is, you get the same results from this query, which is just the second part of the first query:
prefix o1: <urn:ex:ont1#>
prefix o2: <urn:ex:ont2#>
prefix owl: <http://www.w3.org/2002/07/owl#>
select ?product ?issue where {
{ ?product o1:hasIssue ?issue }
union
{ ?product o2:projectName ?projectName .
?_product o1:productName ?productName ;
o1:hasIssue ?issue .
filter strstarts(?productName,?projectName)
}
}
The solution here is an owl:equivalentClass relation. To make this work you have to perform the following tasks:
Create and RDF document into which you place the owl:equivalentClass relation -- alternatively you can use SPARQL 1.1 INSERT to place the relation into a Virtuoso hosted Named Graph
Create an Inference Rule that functions as a Context-Lense when viewing the data in Virtuoso -- be it via SPARQL Query Results of an Entity Description Page etc.
Command (issued via SQL CommandLine of Conductor UI) for associating a Named Graph with an Inference Rule:
RDFS_RULE_SET ('{rule-name}', '{named-graph-uri-or-rdf-document-url}');
Links:
Sample file (note SQL part is commented out re., Rules and Named Graph association)
Live Example -- showcasing owl:equivalentClass reasoning via Schema.org, FOAF, and GoodRelations ontologies.