How can I traverse a graph from a node until a node of type X and no further?
The assumption is that eventually all paths lead to X.
I tried this query but it still give me paths which continue past entities of type X
traverse * from #32:3
WHILE not($current instanceof 'X')
Any advice?
Please try this:
traverse * from #32:3 WHILE $current.#class <> 'X'
This is not polymorphic, so it works only for instances of type X, not its subclasses.
Note that using * wildcard means traversing all edges of any type. Is this what you want? It's always better to specify the direction and/or the edge label(s) to have better performance.
Related
I need to know how many values there is in an enumerated type in my verification environment. E.g.:
type my_type: [a, b, c, d];
I there a way to check on the fly that there 4 different values in the my_type?
Thank you for your help
There's an all_values(...) pseudo-routine that returns all possible values of a scalar type. You can use this to get the number of enum literals:
assert all_values(my_type).size() == 4;
Besides what Tudor suggested, another way is to use set_of_values() pseudo-routine that returns a set (rather than a list) of all values:
set_of_values(my_type).uint_size()
In a way, using set_of_values() is better because all_values() creates a new list, which usually consumes more memory than a set.
uint_size() returns the size of the set as uint. There is also size() but it returns int(bits: *), so it's good enough to use uint_size() in this case, because there can never be more than MAX_UINT items in an enumerated type.
also - set_of_values() return 'set', which you can inquire for the type smallest/largest value, and its range.
For example:
var x := set_of_values(my_type).uint_max();
keep y == set_of_values(my_type).uint_max().as_a(my_type).as_a(my_type);
print set_of_values(my_type).uint_min().as_a(my_type);
This may be quite simple, but i can't find the answer anywhere. In Prolog, when you want to prevent it from searching for additional answers, once a variable has already been instantiated, you can use the ! sign (usually called the "cut" sign).
You can see it in this link to understand what i mean:
http://www.learnprolognow.org/lpnpage.php?pagetype=html&pageid=lpn-htmlse44
for example, given the rule:
max(X,Y,Z) :- X =< Y,!, Y = Z.
if we query:
max(X,Y,X).
the ! sign will prevent prolog from backtracking and trying to prove (X =< Y) by re-instantiating X. This means that all answers will have the same value for X in them.
Is there something like this in pyDatalaog?
No, it doesn't have the cut operator. Cut is not part of Datalog, in general.
However, pyDatalog stops after finding the first value for given arguments of a function. The reference page says : "a function should be defined with the most general clause first, and more specific clauses next. When querying a function, the last one is used first, and the query stops when an answer is found."
So, you may get what you need with the following definition:
+ (max[X,Y] == Y)
(max[X,Y] == X) <= (Y < X)
Note however that there is an open issue.
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
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