I am new in Sparql. I have a car ontology in OWL format. I am trying to write a query that takes names of two nodes from me and shows all the existing paths between them.
For example in the following picture:
example of my ontology's graph,
if the input nodes are G and E, the path between them can be
G c b e,
G c a d b e,
G c a thing b e,
G h I e
I have used apache Jena to connect to my ontology from Eclipse. Now I need to write the query mentioned above. Is there any example that can help me to write the query?
This not a use case where SPARQL shines. Although SPARQL uses graphs as a metaphor, it is not really ideal for implementing classical graph algorithms.
In some cases, it may be easiest to implement things using multiple, iterative queries.
In other cases, it may be easier to use SPARQL to construct a subgraph containing the relevant individuals and property assertions, then uses that as input to one of the usual algorithms.
Note that the problem of finding all paths between two nodes is NP-hard , so reducing the number of nodes that need to be considered is a good thing. You may want to instead look for the top k shortest paths - the results of the ESWC 2016 challenge on this topic are now available ; unfortunately the papers aren't currently self-archived or open access.
Depending on the implementation of the triple store, and the structure of the graph, it may be feasible to find all the triples involved in some path between a and b by looking for every c such that a owl:topObjectProperty+ ?c and ?c owl:topObjectProperty+ b.
It is also possible that this kind of query may cause the server to melt, or your DBA to tie you to a chair and do evil things with UPS parts.
Some systems provide extensions that make implementing such algorithms easier- for example AllegroGraph has non-standard support for first class paths.
I think the best way to do that is to implement an algorithm for it! I don't think this task could be completed using SPARQL or some querying method. I have implemented the following algorithm in Java and Jena to find all the directed paths connecting a set of nodes in an OWL ontology. You can use your two required nodes as your input.
Given a graph G= (V, E) that is:
directed,
acyclic,
non-weighted,
may have more than one edge between two vertices (thus, source and destination are not enough to determine an edge).
And given a set of vertices, let's call them vSet; that contains a vertex vRoot; we need to find ALL paths pSet between vSet elements respecting the following:
any vertex that appears as a source for some path in pSet must be reachable from vRoot.
any path in pSet must has its source and destination from vSet, and must not contain any other vertex of vSet.
The following algorithm is similar to BFS, that starts from vRoot (according to 1 above), grow each of the current paths with one edge per an iteration until it reaches another vertex v1 of vSet; then store this reaching path and start growing new set of paths starting from v1.
Here is the pseudo code:
output = ∅;
maxLengthPaths = ∅;
1. add all edges that vRoot is there source to maxLengthPaths
2. while size(maxlengthpaths) != ∅ do
(a) paths := ∅;
(b) extendedPaths := ∅;
(c) foreach path p in maxLengthPaths do
i. if (destination of p in vSet)
1. add p to output
2. for each edge e that destination of p is its source
A. add e to extendedPaths
ii. else
1. add p to paths
iii. for path p1 in paths
1. for each edge that destination of p1 is its source
A. extend p1 by a edge and add it to extendedPaths
(d) maxLengthPaths = extendedPaths
Related
I'm new to OCL and currently trying to figure out how to do invariants.
I attached a picture with the diagramm I'm working on.
https://imgur.com/1ucZq5w
The invariants that I'm trying to resolve are :
a) A player has 0 or 2 cards in hand.
Context Player
inv i1: self.card->size()=0 or self.card->size()=2
b) A player, who has not played any rounds, can't have more Game Capital than the maximal Buy-In of the table.
Context Player
inv i2: self.numberOfRounds=0 implies (self.gameCapital < self.Table.maxBuyIn)
c) At every table can be only players that belong to different users
Context Player
inv i3: Player.UserAccount.allInstances().userID->isUnique()
I'm not sure if 'allInstances()' is supposed to go after Player or after PlayerAccount.
And I don't know what I'm supposed to do with the 'At every table' part of the text.
There are two more points that I really don't know how to do.
d) In the deck are 52 cards, which differ from eachother through color or value
e) The inputs of all players that still have cards in the hand are equal when bidDone True.
Can you please tell me if what I've done until now is correct and maybe some advice or solution for d) and e)?
Any help is appreciated!
Seems plausible, but I would recommend sensible names, since a validation tool will tend to report that e.g Constraint Player::i2 is not satisfied for ...
b) looks to have a < / <= bug
c) allInstances takes a type source so "Player." is wrong. allInstances is generally very inefficient to execute so should only be used as a last resort. In your case it is clearly wrong since your scope is "at every Table". You should be using context Table and then reasoning about the players at the table.
d) if you rephrase "differ from" as "is unique with respect to", you can perhaps see how you could use a Tuple of color+value as the basis for uniqueness.
e) no idea what an input is, but it just seems like a cascade of implies clauses.
I found the discussion at https://groups.google.com/forum/#!topic/orient-database/Y0QJiXk7d1I to be very useful to help me set up a strict schema with edges in it. This is my code
val fileLink = schema.createClass(DefinedInS.label, g.getEdgeBaseType())
fileLink.setStrictMode(true)
fileLink.createProperty("out", OType.LINK, fqnSymbol).setNotNull(true)
fileLink.createProperty("in", OType.LINK, fileCheck).setNotNull(true)
fqnSymbol.createProperty("out_" + DefinedInS.label, OType.LINKBAG).setNotNull(true)
fileCheck.createProperty("in_" + DefinedInS.label, OType.LINKBAG).setNotNull(true)
but I am confused why I need the last two lines at all, aren't they redundant (or at least implied by the fileLink properties?). Could somebody please explain why they are needed?
In addition, for this example I want exactly one link from a fqnSymbol to a fileCheck but this seems to required that LINKBAG is used (it fails if I use LINK). Is that something I should be allowed to do?
Futhermore, is there any performance benefit to be gained from adding an index on the edge? My usecase is such that I will always have a fqnSymbol at hand when I want to lookup a fileCheck.
I raised https://github.com/orientechnologies/orientdb/issues/5494 to request better documentation in this area.
When one creates an edge (that is, an instance of E), the points of connection are stored at both endpoints (the vertices):
(vertex) -> [edge] -> (vertex)
It's my understanding that if the edge is an immediate instance of E, then those endpoints are properties named out_ and in_. (Similarly, if they are immediate instances of some subclass, say EE, of E, then they would be named out_EE and in_EE.) Often these details don't matter (e.g. outE() collects all outgoing edges), but sometimes they do (as when defining constraints on properties).
Regarding the multiplicity constraint:
I want exactly one link from a fqnSymbol to a fileCheck ...
This constraint can be enforced (at least to a degree) using MIN and MAX:
alter property fqnSymbol.out_ MIN 1;
alter property fqnSymbol.out_ MAX 1;
(Fortunately, the MIN and MAX constraints won't prevent an fqnSymbol vertex from being created in the first place :-)
Tighter enforcement may require writing hooks or triggers.
A "lens" and a "partial lens" seem rather similar in name and in concept. How do they differ? In what circumstances do I need to use one or the other?
Tagging Scala and Haskell, but I'd welcome explanations related to any functional language that has a lens library.
To describe partial lenses—which I will henceforth call, according to the Haskell lens nomenclature, prisms (excepting that they're not! See the comment by Ørjan)—I'd like to begin by taking a different look at lenses themselves.
A lens Lens s a indicates that given an s we can "focus" on a subcomponent of s at type a, viewing it, replacing it, and (if we use the lens family variation Lens s t a b) even changing its type.
One way to look at this is that Lens s a witnesses an isomorphism, an equivalence, between s and the tuple type (r, a) for some unknown type r.
Lens s a ====== exists r . s ~ (r, a)
This gives us what we need since we can pull the a out, replace it, and then run things back through the equivalence backward to get a new s with out updated a.
Now let's take a minute to refresh our high school algebra via algebraic data types. Two key operations in ADTs are multiplication and summation. We write the type a * b when we have a type consisting of items which have both an a and a b and we write a + b when we have a type consisting of items which are either a or b.
In Haskell we write a * b as (a, b), the tuple type. We write a + b as Either a b, the either type.
Products represent bundling data together, sums represent bundling options together. Products can represent the idea of having many things only one of which you'd like to choose (at a time) whereas sums represent the idea of failure because you were hoping to take one option (on the left side, say) but instead had to settle for the other one (along the right).
Finally, sums and products are categorical duals. They fit together and having one without the other, as most PLs do, puts you in an awkward place.
So let's take a look at what happens when we dualize (part of) our lens formulation above.
exists r . s ~ (r + a)
This is a declaration that s is either a type a or some other thing r. We've got a lens-like thing that embodies the notion of option (and of failure) deep at it's core.
This is exactly a prism (or partial lens)
Prism s a ====== exists r . s ~ (r + a)
exists r . s ~ Either r a
So how does this work concerning some simple examples?
Well, consider the prism which "unconses" a list:
uncons :: Prism [a] (a, [a])
it's equivalent to this
head :: exists r . [a] ~ (r + (a, [a]))
and it's relatively obvious what r entails here: total failure since we have an empty list!
To substantiate the type a ~ b we need to write a way to transform an a into a b and a b into an a such that they invert one another. Let's write that in order to describe our prism via the mythological function
prism :: (s ~ exists r . Either r a) -> Prism s a
uncons = prism (iso fwd bck) where
fwd [] = Left () -- failure!
fwd (a:as) = Right (a, as)
bck (Left ()) = []
bck (Right (a, as)) = a:as
This demonstrates how to use this equivalence (at least in principle) to create prisms and also suggests that they ought to feel really natural whenever we're working with sum-like types such as lists.
A lens is a "functional reference" that allows you to extract and/or update a generalized "field" in a larger value. For an ordinary, non-partial lens that field is always required to be there, for any value of the containing type. This presents a problem if you want to look at something like a "field" which might not always be there. For example, in the case of "the nth element of a list" (as listed in the Scalaz documentation #ChrisMartin pasted), the list might be too short.
Thus, a "partial lens" generalizes a lens to the case where a field may or may not always be present in a larger value.
There are at least three things in the Haskell lens library that you could think of as "partial lenses", none of which corresponds exactly to the Scala version:
An ordinary Lens whose "field" is a Maybe type.
A Prism, as described by #J.Abrahamson.
A Traversal.
They all have their uses, but the first two are too restricted to include all cases, while Traversals are "too general". Of the three, only Traversals support the "nth element of list" example.
For the "Lens giving a Maybe-wrapped value" version, what breaks is the lens laws: to have a proper lens, you should be able to set it to Nothing to remove the optional field, then set it back to what it was, and then get back the same value. This works fine for a Map say (and Control.Lens.At.at gives such a lens for Map-like containers), but not for a list, where deleting e.g. the 0th element cannot avoid disturbing the later ones.
A Prism is in a sense a generalization of a constructor (approximately case class in Scala) rather than a field. As such the "field" it gives when present should contain all the information to regenerate the whole structure (which you can do with the review function.)
A Traversal can do "nth element of a list" just fine, in fact there are at least two different functions ix and element that both work for this (but generalize slightly differently to other containers).
Thanks to the typeclass magic of lens, any Prism or Lens automatically works as a Traversal, while a Lens giving a Maybe-wrapped optional field can be turned into a Traversal of a plain optional field by composing with traverse.
However, a Traversal is in some sense too general, because it is not restricted to a single field: A Traversal can have any number of "target" fields. E.g.
elements odd
is a Traversal that will happily go through all the odd-indexed elements of a list, updating and/or extracting information from them all.
In theory, you could define a fourth variant (the "affine traversals" #J.Abrahamson mentions) that I think might correspond more closely to Scala's version, but due to a technical reason outside the lens library itself they would not fit well with the rest of the library - you would have to explicitly convert such a "partial lens" to use some of the Traversal operations with it.
Also, it would not buy you much over ordinary Traversals, since there's e.g. a simple operator (^?) to extract just the first element traversed.
(As far as I can see, the technical reason is that the Pointed typeclass which would be needed to define an "affine traversal" is not a superclass of Applicative, which ordinary Traversals use.)
Scalaz documentation
Below are the scaladocs for Scalaz's LensFamily and PLensFamily, with emphasis added on the diffs.
Lens:
A Lens Family, offering a purely functional means to access and retrieve a field transitioning from type B1 to type B2 in a record simultaneously transitioning from type A1 to type A2. scalaz.Lens is a convenient alias for when A1 =:= A2, and B1 =:= B2.
The term "field" should not be interpreted restrictively to mean a member of a class. For example, a lens family can address membership of a Set.
Partial lens:
Partial Lens Families, offering a purely functional means to access and retrieve an optional field transitioning from type B1 to type B2 in a record that is simultaneously transitioning from type A1 to type A2. scalaz.PLens is a convenient alias for when A1 =:= A2, and B1 =:= B2.
The term "field" should not be interpreted restrictively to mean a member of a class. For example, a partial lens family can address the nth element of a List.
Notation
For those unfamiliar with scalaz, we should point out the symbolic type aliases:
type #>[A, B] = Lens[A, B]
type #?>[A, B] = PLens[A, B]
In infix notation, this means the type of a lens that retrieves a field of type B from a record of type A is expressed as A #> B, and a partial lens as A #?> B.
Argonaut
Argonaut (a JSON library) provides a lot of examples of partial lenses, because the schemaless nature of JSON means that attempting to retrieve something from an arbitrary JSON value always has the possibility of failure. Here are a few examples of lens-constructing functions from Argonaut:
def jArrayPL: Json #?> JsonArray — Retrieves a value only if the JSON value is an array
def jStringPL: Json #?> JsonString — Retrieves a value only if the JSON value is a string
def jsonObjectPL(f: JsonField): JsonObject #?> Json — Retrieves a value only if the JSON object has the field f
def jsonArrayPL(n: Int): JsonArray #?> Json — Retrieves a value only if the JSON array has an element at index n
This is a problem that's been nagging at me for some time, and I wonder if anyone here can help.
I have a PLT Redex model of a language called lambdaLVar that is more or less a garden-variety untyped lambda calculus, but extended with a store containing "lattice variables", or LVars. An LVar is a variable whose value can only increase over time, where the meaning of "increase" is given by a partially ordered set (aka a lattice) that the user of the language specifies. Therefore lambdaLVar is really a family of languages -- instantiate it with one lattice and you get one language; with a different lattice, and you get another. You can take a look at the code here; the important stuff is in lambdaLVar.rkt.
In the on-paper definition of lambdaLVar, the language definition is parameterized by that user-specified lattice. For a long time, I've wanted to do the same kind of parameterization in the Redex model, but so far, I haven't been able to figure out how. Part of the trouble is that the grammar of the language depends on how the user instantiates the lattice: elements of the lattice become terminals in the grammar. I don't know how to express a grammar in Redex that is abstract over the lattice.
In the meantime, I tried to make lambdaLVar.rkt as modular as I could. The language defined in that file is specialized to a particular lattice: natural numbers with max as the least-upper-bound (lub) operation. (Or, equivalently, natural numbers ordered by <=. It's a very boring lattice.) The only parts of the code that are specific to that lattice are the line (define lub-op max) near the top, and natural appearing in the grammar. (There's a lub metafunction that is defined in terms of the user-specified lub-op function. The latter is just a Racket function, so lub has to escape out to Racket to call lub-op.)
Barring the ability to actually specify lambdaLVar in a way that is abstract over the choice of lattice, it seems like I ought to be able to write a version of lambdaLVar with the most bare-bones of lattices -- just Bot and Top elements, where Bot <= Top -- and then use define-extended-language to add more stuff. For instance, I could define a language called lambdaLVar-nats that is specialized to the naturals lattice I described:
;; Grammar for elements of a lattice of natural numbers.
(define-extended-language lambdaLVar-nats
lambdaLVar
(StoreVal .... ;; Extend the original language
natural))
;; All we have to specify is the lub operation; leq is implicitly <=
(define-metafunction/extension lub lambdaLVar-nats
lub-nats : d d -> d
[(lub-nats d_1 d_2) ,(max (term d_1) (term d_2))])
Then, to replace the two reduction relations slow-rr and fast-rr that I had for lambdaLVar, I could define a couple of wrappers:
(define nats-slow-rr
(extend-reduction-relation slow-rr
lambdaLVar-nats))
(define nats-fast-rr
(extend-reduction-relation fast-rr
lambdaLVar-nats))
My understanding from the documentation on extend-reduction-relation is that it should reinterpret the rules in slow-rr and fast-rr, but using lambdaLVar-nats. Putting all this together, I tried running the test suite that I had with one of the new, extended reduction relations:
> (program-test-suite nats-slow-rr)
The first thing I get is a contract violation complaint: small-step-base: input (((l 3)) new) at position 1 does not match its contract. The contract line of small-step-base is just #:contract (small-step-base Config Config), where Config is a grammar nonterminal that has a new meaning if reinterpreted under lambdaLVar-nats than it did under lambdaLVar, because of the specific lattice stuff. As an experiment, I got rid of the contracts onsmall-step-base and small-step-slow.
I was then able to actually run my 19 test programs, but 10 of them fail. Perhaps unsurprisingly, all the ones that fail are programs that use natural-number-valued LVars in some way. (The rest are "pure" programs that don't interact with the store of LVars at all.) So, the tests that fail are exactly the ones that use the extended grammar.
So I kept following the rabbit hole, and it seems like Redex wants me to extend all of the existing judgment forms and metafunctions to be associated with lambdaLVar-nats rather than lambdaLVar. That makes sense, and it seems to work OK for judgment forms as far as I can tell, but with metafunctions I get into trouble: I want the new metafunction to overload the old one of the same name (because existing judgment forms are using it) and there doesn't seem to be a way to do that. If I have to rename the metafunctions, it defeats the purpose, because I'll have to write whole new judgment forms anyway. I suppose that what I want is a sort of late binding of metafunction calls!
My question in a nutshell: Is there any way in Redex to parameterize the definition of a language in the way I want, or to extend the definition of a language in a way that will do what I want? Will I end up just having to write Redex-generating macros?
Thanks for reading!
I asked the Racket users mailing list; the thread begins here. To summarize the resulting discussion: In Redex as it stands today, the answer is no, there is no way to parameterize a language definition in the way I want. However, it should be possible in a future version of Redex with a module system, which is in the works right now.
It also doesn't work to try to use Redex's existing extension forms (define-extended-language, extend-reduction-relation, and so on) in the way I tried to do here, because -- as I discovered -- the original metafunctions do not get transitively reinterpreted to use the extended languages. But a module system would apparently help with this, too, because it would allow you to package up metafunctions, judgment-forms, and reduction relations together and simultaneously extend them (see the discussion here).
So, for now, the answer is, indeed, to write a Redex-generating macro. Something like this works:
(define-syntax-rule (define-lambdaLVar-language name lub-op lattice-values ...)
(begin
;; Entire original Redex model goes here, with `natural` replaced with
;; `lattice-values ...`, and instances of `...` replaced with `(... ...)`
))
And then you can instantiate particular lattices with, e.g.,:
(define-lambdaLVar-language lambdaLVar-nat max natural)
I hope Redex does get modules soon, but in the meantime, this seems to work well.
Consider the example below without any assumption about language or file types. I have:
M_old : [A,B,C]
M_new : [A,B,X]
and now I would like to create:
M_result : [A,B,C,X]
which is basically the union of M_old and M_new. Are there any compare/diff/merge tool that supports this kind of operation - that can take M_old and M_new and produce M_result based on the above instances?
I have had success with computing (using a simple diff/merge tool) M_result when:
M_old : [A,B,C]
M_new : [A,B,C,X]
since all elements in M_old is contained in M_new. But I don't see how this possible when some of the elements in M_old is not present in M_new.
So in more general terms does a "merge" operation only support union under special conditions as described above?
If you don't care about the exact order of the resulting list, you can compute M_result by appending every element in M_old that is not in M_new to M_new, or, alternatively, by concatenating M_new and M_old and then removing duplicate elements (These yield the exact same result if neither input list contains any duplicate elements to begin with).
correct merge tools will propose you the solution that you want amongst other solutions, this is what our tool ECMerge does.
(I presume you have an ancestor: M_ancestor: [A,B])
your problem here is that there are not enough data to determine that is expected when there is a replacement (should the merge result be ',C' then ',X', ',X' then ',C' or only one or the other).
(I presume you have an ancestor: M_ancestor: [A,B,C])
the other case when the change is an insertion of ',X' (M_old : [A,B,C] versus M_new : [A,B,C,X]) is generally resolved by adding ',X' as there is no particular choice. if the ancestor is [A,B] only then there is still a question: should the merger consider adding ',C' or ',C,X' ? this is not obvious then as the version with only ',C' might have taken into account the knowledge of ',C,X' from outside the SCC system and already deleted the ',X'.
even 'clever' merger cannot do divination :)