my ontology about social network. And we have simple SWRL rules two people(?p1,?p2) workInOrg Org(?org) => colleagueOf(?p1,?p2) and if thier colleague, one people workInOrg => the other person also works in that Org. I also build OWL Axioms but it cant take affect on Graphdb. Another try is that i wrote a custom rule, but Graphdb only allow to choose one Rule (In my case "owrl2-rl") and my custom rule only take affect when combining on this rule OWL2-RL. Is there a way to use combine rules and write rule effienctly?
SHACL validation is good. Does graphdb has OWL constraint validation ??? (ex: domain-range validation ?)
Thanks.
Damyan's comment above provides the answer
One can do this also with OWL2 RL and property chains (see https://www.w3.org/TR/owl2-profiles/#OWL_2_RL in https://www.w3.org/TR/owl2-profiles/#OWL_2_RL). This would not require custom rules, but inference will be a bit slower
This is how it can work:
:worksIn owl:inverseOf :employerOf
:colleagueOf owl:propertyChainAxiom ( :worksIn :employerOf ) .
:worksIn owl:propertyChainAxiom ( :colleagueOf :worksIn ) .
Related
I have a reasonable implementation of Jena over MongoDB by providing impls for Graph and DatasetGraph. SPARQL queries are converted into the appropriate query expressions in MongoDB and material, at least on triple-match-by-triple-match basis, is vended in a high performance way. This is not a surprise; indexes do what they're supposed to do. Graph is wrapped with an RDFS reasoner Model and all is fine.
I am interested in now exploring ways to optimize filtering push-down into MongoDB. For example, this SPARQL:
?s a:attested "2017-06-01T00:00:00Z"^^xsd:dateTime .
results in this setup of a MongoDB find expression:
{ "P" : "a:attested", "O" : { "$date" : 1496275200000 } }
And all is good. But this SPARQL:
?s a:attested ?theDate .
FILTER (?theDate = "2017-06-01T00:00:00Z"^^xsd:dateTime)
causes ARQ to pass only the predicate to Graph::find():
{ "P" : "a:attested" }
and a whole lot of things are pulled from the DB and the filtering is done in ARQ itself. The FILTER expression above is obviously not needed for a simple equality but it proves the point.
The TDB documentation says that "... TDB uses the OpExecutor extension point of ARQ." But the link for OpExecutor goes to a To-Do.
Can anyone point at any examples of anything where something can be hooked or otherwise accessed around the time ARQ calls Graph::ExtendedIterator<Triple> find(Triple m)? It is at this point that my implementation jumps in to craft the query, and if I can ask if filters exist, then I can "improve" the restriction on the query. At this time, it is not so important that I deal with stopping the filtering from happening again in ARQ itself.
I'm using TopBraid Composer Free Edition (5.1.3) to create ontologies including SPIN constraints. I then load the resulting RDF files into RDF4J (2.0.1) and use RDF4J Workbench for testing.
I'm working on SPIN constraints. Here's an example to check for non-negative signal rates that I've added to the CRO2:SignalRate class:
CONSTRUCT {
?this soo:hasConstraintViolation _:b0 .
_:b0 a spin:ConstraintViolation .
_:b0 rdfs:label "Non-Positive SignalRate" .
_:b0 spin:violationRoot ?this .
_:b0 spin:violationPath Nuvio:hasDataValue .
_:b0 spin:violationLevel spin:Warning .
}
WHERE {
?this Nuvio:hasDataValue ?signalRate .
FILTER (?signalRate <= 0.0) .
}
So, I'm testing this constraint in RDF4J workbench using the following SPARQL update query:
PREFIX inst: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Sharing/Instantiations#>
PREFIX Nuvio: <http://cogradio.org/ont/Nuvio.owl#>
PREFIX CRO2: <http://cogradio.org/ont/CRO2.owl#>
INSERT DATA {
inst:aSignalRate_test a CRO2:SignalRate ;
Nuvio:hasDataValue "-10"^^xsd:long .
}
This test instant violates the constraint shown above. If I omit the spin:violationLevel triple and allow this to default to a spin:Error, then I get an error message from the query and the test instance is not asserted, as expected. When executed as shown, the constraint violation is a spin:Warning, so the inst:aSignalRate_test individual is created with data value -10.0. My question is, where do the assertions in the constraint's CONSTRUCT clause go? I believe they're being asserted since the change in the spin:violationLevel impacts behavior. Note that I've tried to tie into the blank node with my own soo:hasConstraintViolation property, but this doesn't work. Are the CONSTRUCT triples asserted in some other context/graph? I'm just using the default/graph for everything.
I'm looking for the expected triples both using RDF4J Workbench's Explore and using SPARQL queries. For example, the following query returns nothing after I assert my errant CRO2:SignalRate:
PREFIX spin: <http://spinrdf.org/spin#>
SELECT DISTINCT *
WHERE {
?s spin:violationRoot ?o .
}
This behavior is consistent between asserting in TopBraid Composer FE and RDF4J Workbench.
My goal is to find and use the diagnostic messages asserted in case of SPIN constraint violations, preferably by using SPARQL queries to find such diagnostics. Seems reasonable. I'm missing something.
Thanks.
The short answer: you can't.
SPIN constraints are intended to detect violations and report them. In RDF4J, that reporting mechanism is the log.
The relevant part of the SPIN spec (http://spinrdf.org/spin.html#spin-constraints) :
[...] if an ASK constraint evaluates to true for one
instance, then the instance violates the condition. Optionally,
CONSTRUCT queries can create instances of a spin:ConstraintViolation
class that provide details on a specific violation.
Note that there is no requirement on the reasoner to do anything with the data that a CONSTRUCT-based constraint produces - it's merely for optional "additional information".
It's perhaps worth seeing if we could add an enhancement to the reasoner to report such triples back in one form or another, but in the current system, only SPIN rules (using DELETE/INSERT etc) modify the database.
So, following #JeenBroekstra comments and my response comment above, I've switched to using constuctors so that the error information remains as visible artifacts. I've created several of my own subproperties of the spin:constructor in order to keep things ordered. I've also specified the execution order of these constructors so that these checks run ahead of other rules that might be tripped up (e.g. by a negative signal rate).
Advantages of this approach:
The error detail artifacts (e.g. spin:violationRoot) remain visible in the triple store. This is very important in my application which involves machine-to-machine.
All the compliance checks are done, so an individual with multiple problems lists all problems as separate hasConstraintViolation properties, not just the first violation to block instantiation.
Disadvantages of this approach:
The errant individual is still instantiated.
This is not standard behavior, so tools geared to look for constraint artifacts in the logs probably won't find them.
Here's a screen shot of an example rule implemented as a subproperty of spin:constructor:
I have an ontology with different type of events.
Therefore I have three classes: A, B, C and a helper class Temp.
I want the reasoner to create a new individual as a subclass of C for every pair of individuals a (rdf:typeOf A) and b (rdf:typeOf B) found. This new Individuals should contain informations about a and b.
In the past I used a jena reasoner with an own rule file to get this result, but now I want to switch over to a standard OWL DL reasoner.
My initial idea is to link a und b such as:
a onto:hasB b
And ad give a the Type Temp with the following restriction for Temp:
hasbB some B
Now I want to create a new individual of type C with a restriction for Temp:
hasC some C
And over this new indivual I can access the informations of a and b.
My Problems are:
How can I get the reasoner to connect a and b?
I don't think the creation of C will work, since its a restriction for Temp, which will never be assigned as a type because of this restriction.
Or am I completly wrong with my approach?
Edit:
To clarify my goal with a better exmple:
I have an ontology with different type of events.
My goal is to connect certain individuals (events) which belong together by forming a new individual (event) describing this relation with the help of a reasoner.
E.g.:
I read an event (individual) which describes an "Alarm" (type) into the ontology.
I read an event (individual) which discribes a "PowerOutage" (type) into the ontology.
These Individuals aren't related at all at this moment.
Now I want a reasoner to create a new event (individual) with the type "PowerManipulation". In fact I want an individual with the type "PowerManipulation" created for every pair (which isn't connected, yet) of individuals with the type "PowerOutage" and "Alarm" found. These new individuals should have references (properties) to the individual which caused their creation (an "Alarm" and a "PowerOutage").
Ontology before the reasoning:
(alarm1 rdf:type "Alarm")
(out1 rdf:type "PowerOutage")
What I want the ontology to look like after the reasoning
(alarm1 rdf:type "Alarm")
(out1 rdf:type "PowerOutage")
(man1 rdf:type "PowerManipulation")
(man1 ont:hasRealtadInd alarm1)
(man1 ont:hasRealtedInd out1)
Priviously I used Jena rules and the Jena reasoner to accomplish this task.
But I want to switch over to a standard OWL DL reasoner.
Is it possible to accomplish this task with basic restrictions?
Or do I need SWRL rules, or SPIN (see Williams answer below)?
You can do this with SPIN constructors quite easily and SPIN inserts.
http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/#spin-rules-construct
http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/#spin-rules-update
SPIN and OWL can live happily together. Take a look at the groovy library that has extensions for both:
https://github.com/williamgreenly/lescot
Example below:
def model = new GroovyRdfModel()
model.add(""" some turtle data """)
model.add(""" some OWL rules """)
model.add(""" some SPIN rules """)
def inferredModelByOWLReasoning = model.owl()
def inferredModelBySPINRules = model.spin()
For my current project I need to load a dataset and different ontologies and expose everything as linked data using Fuseki with TDB and Pubby. Pubby will take a data set from a single location and create URIs based on that location, therefore if we need multiple different locations (as in the case with 2–3 separate ontologies), that would be easy to do with Pubby by adding another data set.
The concept of dataset seems to also apply to Fuseki.
Essentially I will need to expose three types of URIs:
www.mywebsite.com/project/data
www.mywebsite.com/project/data/structure
www.mywebsite.com/project/ontology
In order to create such URIs with Pubby 0.3.3. you will have to specify lines like these:
conf:dataset [
conf:sparqlEndpoint <sparql_endpoint_url_ONE>;
conf:sparqlDefaultGraph <sparql_default_graph_name_ONE>;
conf:datasetBase <http://mywebsite.com/project/>;
conf:datasetURIPattern "(data)/.*";
(...)
]
Each data set specified in Pubby will take its data from a certain URL (typically a SPARQL endpoint).
For ontologies you will have a dataset that uses the second a datasetURIPattern like this one:
conf:dataset [
conf:sparqlEndpoint <sparql_endpoint_url_TWO>;
conf:sparqlDefaultGraph <sparql_default_graph_name_TWO>;
conf:datasetBase <http://mywebsite.com/project/>;
conf:datasetURIPattern "(ontology)/.*";
(...)
]
As you can see the differences would be at the following: conf:sparqlEndpoint (the SPARQL endpoint), conf:sparqlDefaultGraph (the default Graph), conf:datasetURIPattern (needed for creating the actual URIs with Pubby).
It is not however clear to me how can I have separate URIs for the data sets when using Fuseki. When using Sesame, for example, I just create two different repositories and this trick works like charm when publishing data with Pubby. Not immediately clear with
The examples from the official Fuseki documentation present a single dataset (read-only or not, etc), but none of them seem to present such a scenario. There is no immediate example where there is a clear separation between the TBox and the ABox, even though this is a fundamental principle of Linked Data (see Keeping ABox and TBox Split).
As far as I understand this should be possible, but how? Also is it correct that the TBox and ABox can be reunited under a single SPARQL endpoint later by using (tdb:unionDefaultGraph true ;).
The dataset concept is not unique to Jena Fuseki; it's quite central in SPARQL. A dataset is a collection of named graphs and a default graph. The prefix of a URI has nothing to do with where triples about it are stored (whether in a named graph or in the default graph).
It sounds like you want to keep your ABox triples in one named graph and your TBox triples in another. Then, if the default graph is the union of the named graphs, you'll see the contents of both in the default graph. You can do that in Fuseki.
Summary
Thank you in advance for helping me write a CONSTRUCT/WHERE statement that can be declared as a SPIN Rule in TopBraid Composer Free Edition and used.
I am trying to embed a SPARQL CONSTRUCT/WHERE statement in a spin:rule declaration and then execute it. I am returning zero inferences to Statements 1 or 2 below. I am using Java 7, and Eclipse 4.3., and TopBraid Composer Free Edition. I have been successful running Statement 3 as a SPIN Constructor Declaration in the classes form (Statement 3). I have been successful running Statement 4 in the SPARQL query editor (interpreter) I have cross-posted to the user forum.
Details
Fact 1: I have not been able to run Statement 1 as a SPIN Rule.
----Statement 1---
CONSTRUCT {
?this owl:hasKey ?x .
}
WHERE {
BIND (spif:generateUUID() AS ?x) .
}
Fact 2: I have not been able to run Statement 2 as a SPIN Rule.
----Statement 2----
CONSTRUCT {
?this owl:hasKey ?x .
}
WHERE {
?this rdfs:subClassOf node:entity .
BIND (spif:generateUUID() AS ?x) .
}
--No Error Message--
Fact 3: However I have been successful with Statement 3 in the constructor field of the classes form.
----Statement 3----
CONSTRUCT {
?this owl:hasKey ?x .
}
WHERE {
BIND (spif:generateUUID() AS ?x) .
}
Success: When a new instance is created a new triple indicating a key is created.
Fact 4: I have been successful with Statement 4 in the SPARQL query editor which is analogous.
----Statement 4----
CONSTRUCT {
?s owl:hasKey ?x .
}
WHERE {
?s rdf:type node:word_use
BIND (spif:generateUUID() AS ?x) .
}
Success: When statement is run all current instances get keys.
Fact 5: I do not have any SPARQL Rules libraries checked in the Ontology Profile form.
Fact 6: I have imported the following two libraries.
<http://spinrdf.org/spin> from local file TopBraid/SPIN/spin.ttl.
<http://spinrdf.org/sp> from local file TopBraid/SPIN/sp.ttl
Fact 7: The namespaces in the file are:
Base URI (Location) - http://example.org/
Default Namespace - http://example.org/
But the Base URI keeps getting reset to:
http://www.semanticweb.org/owl/owlapi/turtle
ace_lexicon - http://attempto.ifi.uzh.ch/ace_lexicon#
arc - http://example.org/arc#
arg - http://spinrdf.org/arg#
concept - http://example.org/concept#
node - http://www.example.org/node#
owl - http://www.w3.org/2002/07/owl#
rdf - http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs - http://www.w3.org/2001/01/rdf-schema#
skos - http://www.w3.org/2004/02/skos/core#
sp - http://spinrdf.org/sp#
spif - http://spinrdf.org/spif#
spin - http://spinrdf.org/spin#
spl - http://spinrdf.org/spl#
word_sense - http://example.org/word_sense#
word_term - http://example.org/word_term#
word_use - http://example.org/word_use#
Fact 8: The class that I am using has the following assertions.
Name - node:unclassified_concept
SubClassOf - node:entity
Fact 9: An instance of the node:unclassified_concept class is described below.
URI - http://example.org/concept#regardless_of1
rdfs:comment - without attention to
rdfs:isDefinedBy - <http://en.wiktionary.org/wiki/regardless_of>
rdfs:label - regardless of
Fact 10: I have been successful using Jena Generic Rules reasoning as well as the OWL_MEM_RULE_INF OntModelSpec, reading/writing, base models, inf models, and ont models.
Context
The context of my problem is the following. I am building and iteratively executing an ontology and rule set using Java and Jena to prove the concept of OWL/RDF representing, considering, and responding to non-trivial type-written English. The sentence I am using is non-trivial (41 words, three clauses, etc.). The current ontology has 1422 assertions when not run against any OWL/RDF rules (transitivity, etc.). I am using TopBraid Composer when possible to complement Jena programming to make sure I am compliant with conventions and standards.
This post outlines the solution to the problem I posted. I was able to come to this solution via a person who responds to their user forum. https://groups.google.com/forum/#!forum/topbraid-users
The CONSTRUCT/WHERE statement (after revision) I wanted to run was:
CONSTRUCT {
?this owl:hasKey ?x .
}
WHERE {
?this rdf:type node:unclassified_concept .
BIND (spif:generateUUID() AS ?x) .
}
However, if I placed this statement in the spin:rule field of the classes form in TBC and pressed the icon for inferencing, I would receive no inferences and much time would be spent churning by the inferencer.
The solution was to create a subproperty of spin:rule that had spin:rulePropertyMaxIterationCount set to 1 (to avoid infinite loops generated by running the built-in function -- in my case spin:generateUUID().)
Then I needed to "pull" or place that new subproperty (which I named "runOnce") into the classes form that I was trying to create a dependent-upon-a-built-in CONSTRUCT/WHERE rule for.
Finally, in the classes form I needed to select add blank row on the new subproperty RunOnce, and then enter my original CONSTRUCT/WHERE statement there.
Then I ran inferencing and the class used the rule.
In short, if you want to embed a rule in a class in TBC, and that rule uses a builtin function, you need to
-Create a subproperty of spin:rule that has rulePropertyMaxIterationCount
set to 1.
-Include this subproperty in the classes form.
-Embed your CONSTRUCT/WHERE statement that uses the built-in within that
subproperty on the classes form by selecting insert blank line and
copying/pasting it in there.
Note the TBC supported SPIN built-in functions is a smaller set than I believe is in the SPIN API documentation. The list of TBC supported built-ins is here in the TBC product.
Help>
Help Contents>
TopBraid Composer>
Application Development Tools>
SPARQL Motion Scripts>
SPARQL Motion Functions Reference
Hope this helps someone.