I have a simple question which I suspect has no simple answer. Essentially, I want to check whether it is true that one OWL expression (#B) follows on logically from another (#A) - in other words I want to ask: is it true that #A -> #B?
The reason for this is that I'm writing a matching algorithm for an application which matches structures in a knowledge based (represented by the #KnowledgeStructure class) to a structure which describes the needs of the current application state (#StateRequirement). Both structures have properties which have string values representing OWL expressions over the state of a third kind of structure (#Model). These are: #KnowledgeStructure.PostCondition which expresses how the knowledge structure being applied to #Model will transform #Model; and #StateRequirement.GoalCondition, which expresses the #Model state that the application aims to achieve. I want to see, therefore, if the #KnowledgeStructure will satisfy the #StateRequirement by checking that the #KnowledgeStructure.PostCondition produces the desired #StateRequiremment.GoalCondition. I could express this abstractly as: (#KnowledgeStructure.Postcondition => #StateRequirement.GoalCondition) => Match(#KnowledgeStructure, #StateRequirement). Less confusingly I could express this as: ((#A -> #B) -> Match(#A, #B)) where both #A and #B are valid OWL expressions.
In the general case I would like to be able to express the following rule: "If it is true that the expression #B follows from #A, then the expression Match(#A, #B) is also true".
Essentially, my question is this: how do I pose or realise such a rule in OWL? How do I test whether one expression follows from another expression? Also, are existing reasoners sufficiently powerful to determine the relation #A -> #B between two expressions if this relation is not explicitly stated?
I'm not 100% sure that I fully understood the question, but from what I grasped I would face the situation in this way.
First of all I refer to Java because all the libraries I know are meant for this language. Secondly, I don't think that OWL on its own is able to satisfy your goal, given that it can represent rules and axioms, but it does not provide reasoning, that is, you need a reasoner, so you need to build a program that uses it, plus doing additional processing that I will sketch below:
1) You didn't mention it, but I guess you have an underlying ontology w.r.t. you need to prove your consequence relation (what you denote with symbol "->"). If the ontology is not explicit, maybe it can be extracted/composed from the textual expressions you mentioned in the question.
2) you need to use a library for ontology manipulation, I suggest OWL API from Manchester University, it is very powerful and simple, in the tutorial under section "documentation" you have an overview of the main functionalities, including the use of reasoners (the example shows Hermit, but the principle holds for any other reasoner).
3) At this point you need to check if the ontology is consistent (otherwise anything can be derived, as it often happens with false premises)
4) You add the following axiom to the ontology (you build it directly in Java, no need to serialize back, you can let the reasoner work on the in-memory representation) and check for consistency: A \sqsubseteq B, that is, using the associated interpretation: A^I \subseteq B^I, so it is equivalent to A => B (they have the same truth table).
5) At this point you can add the axiom Match(A,B), where A and B are your class expressions and Match is a Role/Relation that relates all the class expressions for which the second is a consequence of the first.
6) After a number of repetitions of these steps you may want to serialize the result and store it, and this again can be achieved quite simply using OWL API from the in-memory representation.
For some basics about Description Logics (the logic underpinning OWL ontologies) you can refer to A description logic Primer (2012), Horrocks et al. and to Foundations of Description Logics (2011), Rudolph.
I'm not a logician or a DL expert, so please verify all the information I provided and feel free to correct me :)
Related
Sparql has a notion of a "default graph" that is queried when no graph context is specified, and which (depending on the triple store) may be the union of proper graphs available in a repository, or it may be a separate, "null graph"; so far so good.
But sparql also has a keyword DEFAULT that can be specified instead of a graph name, as in
SELECT *
FROM DEFAULT
WHERE { ... }
What does this command do? I can only interpret it as an explicit way to request the same thing that would happen when there's no FROM clause at all. But is this correct? I could find no documentation about it. And what about using it in update queries, or with CLEAR, COPY, etc.? Can anyone point to documentation of the meaning and intended use of this keyword, or at least shed some light on why it exists?
When you have one or more FROM or FROM NAMED statements in a query then the dataset for the query is composed of only those graphs. Per SPARQL 1.1 Query Specification Section 13.2:
The FROM and FROM NAMED keywords allow a query to specify an RDF dataset by reference; they indicate that the dataset should include graphs that are obtained from representations of the resources identified by the given IRIs (i.e. the absolute form of the given IRI references). The dataset resulting from a number of FROM and FROM NAMED clauses is:
a default graph consisting of the RDF merge of the graphs referred to in the FROM clauses, and
a set of (IRI, graph) pairs, one from each FROM NAMED clause.
If there is no FROM clause, but there is one or more FROM NAMED clauses, then the dataset includes an empty graph for the default graph.
So basically the presence of those clauses creates a query dataset that potentially hides some/all graphs in the underlying dataset. Your query operates over this query dataset.
As noted in Andy's answer FROM DEFAULT is a proposed future extension to the SPARQL language that would allow explicitly referring to the datasets default graph (whatever that may be). Currently there's no standardised way to do this, so only queries that omit any FROM clauses can access the default graph unless your service provides some non-standard way to refer to it e.g. a custom URI for referencing the default graph.
For your specific example query:
SELECT *
FROM DEFAULT
WHERE { ... }
This would have the effect of forming a query dataset with a default graph using the services default and no named graphs visible i.e. any GRAPH ?g { } clauses would not match in this query
FROM DEFAULT is a feature that has been proposed for future work sparql-1.2/issues/43.
The grammar covers both SPARQL Query and SPARQL Update because they share a considerable about of the grammar. They have different entry points (QueryUnit and UpdateUnit).
The DEFAULT keyword appears in GraphOrDefault and GraphRefAll. Both of which are only used in SPARQL Update.
ADD, MOVE, CODE use GraphOrDefault; CLEAR and DROP use GraphRefAll.
FROM is followed by either an iri, or NAMED iri.
Omitting FROM means the implicit default graph.
Both Filter and Interpreter Design Patterns look like much similar task oriented. Filter does filtering a list for some criteria, while Interpreter is doing pretty much same for a single element.
But I wonder why Filter is Structural and Interpreter is behavioral. Anyone got an idea?
Although it is true that they are "task-oriented", these two patterns actually refer to different purposes, let's take the example of an SQLTable class.
Filter pattern can serve to filter/remove/hide, more generally affect the structure of your database but don't modify its behavior at all.
Example 1 : Once filtered, it's only a new SQLTable with less/more rows and maybe less/more columns
Interpreter pattern belongs to behavioral pattern, in the sense that it modifes the behavior of an object (often represented with the help of a structural pattern such as Composite). The difference lies in the interpretation of the structure to behave differently.
Example 2: Once interpreted as a csv-table, your SQLTable can now be exported to a PDF file
I guess your misunderstanding comes from the fact that they are both applied to a structure in order to create something else but the actual difference lies in their intent rather than their concrete implementation which are relatively close in practice
Are there any open source tools that can generate a natural language description of a given SQL query? If not, some general pointers would be appreciated.
I don't know much about NLP, so I am not sure how difficult this is, although I saw from some previous discussion that the vice versa conversion is still an active area of research. It might help to say that the SQL tables I will be handling are not arbitrary in any sense, yet mine, which means that I know exact semantics of each table and its columns.
I can devise two approaches:
SQL was intended to be "legible" to non-technical people. A naïve and simpler way would be to perform a series of replacements right on the SQL query: "SELECT" -> "display"; "X=Y" -> "when the field X equals to value Y"... in this approach, using functions may be problematic.
Use a SQL parser and use a series of templates to realize the parsed structure in a textual form: "(SELECT (SUM(X)) (FROM (Y)))" -> "(display (the summation of (X)) (in the table (Y))"...
ANTLR has a grammar of SQL you can use: https://github.com/antlr/grammars-v4/blob/master/sqlite/SQLite.g4 and there are a couple SQL parsers:
http://www.sqlparser.com/sql-parser-java.php
https://github.com/facebook/presto/tree/master/presto-parser/src/main
http://db.apache.org/derby/
Parsing is a core process for executing a SQL query, check this for more information: https://decipherinfosys.wordpress.com/2007/04/19/parsing-of-sql-statements/
There is a new project (I am part of) called JustQuery.Me which intends to do just that with NLP and google's SyntaxNet. You can go to the https://github.com/justquery-me/justqueryme page for more info. Also, sign up for the mailing list at justqueryme-development#googlegroups.com and we will notify you when we have a proof of concept ready.
I have a list of simple regular expressions:
ABC.+DE.+FHIJ.+
.+XY.+Z.+AB
.+KLM.+NO.+J.+
QRST.+UV
they all have alternating patterns of .+ and some text (I will call "words") repeated some number of times. A pattern may or may not begin or end in .+. These regular expression are all mutually exclusive. When another regex is added I want to remove any other matching regular expressions, and add one regular expression that combines the added one with all of its matches. For example, adding:
.+J.+
would match,
ABC.+DE.+FHIJ.+
.+KLM.+NO.+J.+
and thus, these would be remove and replaced with the added regular expression resulting in:
.+J.+
.+XY.+Z.+AB
QRST.+UV
I need to store these patterns either in some data structure or (preferably) in a database in an efficient manner. I first tried a tree of dictionaries, only to realize that in the case that a regex starts with a .* it has to search the entire tree for the next word, which is order O(2^n). Unfortunately, (unless I am mistaken) it appears that neither SQLite (which I am using) nor any other relational database that I have used, supports "regular expression" as a data type. My question is, is there an efficient method for storing and retrieving such simple regular expressions? If there is no canned method, is there some data structure that would be relatively efficient (say, at worst amortized polynomial time)?
Could you please explain what you are using these regular expressions for as that would make it easier to provide a better answer? In particular when I see the way you are splitting your regular expressions I'm wondering if a Trie or a Directed acyclic word graph would be a better fit.
From their you may find your answer is as simple as providing better normalization or finding an alternative no SQL db made specifically for your problem area.
I have the following case:
All boats have a boat type like shark , yatch and so on. I need to register which type of boat name and also how many feet the boat is, but this is where the problem arises. If the user types in a shark I need to validate that its between 15-30 feet, if he type in a yatch it needs to be between 30-60 for instance.
Any help on this?
<boat>
<type>shark</type>
<foot>18</foot> //validates
</boat>
<boat>
<type>shark</type>
<foot>14</foot> //fails
</boat>
<boat>
<type>AnyOtherBoat</type>
<foot>14</foot>//validates since its another type of boat than shark and yatch
</boat>
Help appriciated! Thx
Schematron ("a language for making assertions about patterns found in XML documents") might be able to do what you need. It allows specifying additional rules which cannot be expressed within a regular XML schema definition (XSD, RelaxNG).
Here are some articles to get you started:
Schematron on Wikipedia
Schematron: XML Structure Validation Language Using Patterns in Trees
Improving XML Document Validation with Schematron
To answer your question: No, you can't do that in XML Schema.
Firstly, you can't use values to select which constraints to apply (but you could for elements like <shark>)
Secondly, you can't do arithmetic tests (but you can use regex to specify the permissible strings... so you might be able to hack it.)