Linking Two Graphs

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hello everyone,
I'm trying to create a Model where I first define the structure of a property graph (like explained here: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model, extended with types for nodes and relationships) and then I would like to define a/some traversal(s) over it such that the graphical model of the traversal is constrained to only allow valid traversals (or at least indicate if a traversal is invalid).

As a very simple example:
I define a graph where there are the node types Person and Car, and a Person can be friends with any number of other Persons, and can own at most one Car.
So there will be nodes of type "Person" and "Car" and relationships of type "Friend" and "Own".

A valid traversal would be:
From a Person over the Friend Relationship to another Person and over the Own Relationship to the Car.
(Answering the question: "What cars do my direct friends own?")

An invalid traversal would be:
From a Person over the Own Relationship to another Person
or
From a Person over the Friend Relationship to a Car

Right now I have no problem to define the Property Graph and the Modeling language for it, but extending this with a Modeling Language for the Traversal seems to be impossible. I have already looked at a lot of your examples, and searched through the forums, and read through the Manuals and Tutorials, but I just couldn't get an idea how to solve this problem. Is this even possible in the current version of MetaEdit? 

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
treo Members Profile Send Private Message Find Members Posts Add to Buddy List Member Joined: 31.Jul.2013 Points: 6	Post Options Post Reply Quote treo Report Post Thanks(0) Quote Reply Topic: Linking Two Graphs Posted: 31.Jul.2013 at 02:22
	Hello everyone, I'm trying to create a Model where I first define the structure of a property graph (like explained here: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model, extended with types for nodes and relationships) and then I would like to define a/some traversal(s) over it such that the graphical model of the traversal is constrained to only allow valid traversals (or at least indicate if a traversal is invalid). As a very simple example: I define a graph where there are the node types Person and Car, and a Person can be friends with any number of other Persons, and can own at most one Car. So there will be nodes of type "Person" and "Car" and relationships of type "Friend" and "Own". A valid traversal would be: From a Person over the Friend Relationship to another Person and over the Own Relationship to the Car. (Answering the question: "What cars do my direct friends own?") An invalid traversal would be: From a Person over the Own Relationship to another Person or From a Person over the Friend Relationship to a Car Right now I have no problem to define the Property Graph and the Modeling language for it, but extending this with a Modeling Language for the Traversal seems to be impossible. I have already looked at a lot of your examples, and searched through the forums, and read through the Manuals and Tutorials, but I just couldn't get an idea how to solve this problem. Is this even possible in the current version of MetaEdit?

janne Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 25.Mar.2008 Points: 58	Post Options Post Reply Quote janne Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 09:49
	How about the following: Modeling language contains two object types: 'Person' and 'Car', and two relationship types 'Friend' and 'Own'. Generator: Report 'Friends car' foreach .Person { id ':' newline do ~Person~Person.Person { ' has a direct friend: ' id if ~Owner~Owned; then do ~Owner~Owned.Car { ' who owns a car: ' id newline } else newline endif } } endreport which produces:

treo Members Profile Send Private Message Find Members Posts Add to Buddy List Member Joined: 31.Jul.2013 Points: 6	Post Options Post Reply Quote treo Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 12:03
	Thank you Janne for taking your time to try to answer my question. It seems that I didn't pose it quite right. I want to only define the structure of the graph, not an actual instance of it. So I would have something like this: And the Traversal should also be defined as a Language so my example for a valid traversal would look something like this: And if i had connected a Person via an Owns Relationship, I'd like to highlight that error, so it would be directly clear that this would produce an invalid traversal. In the end I want to create a graphical traversal definition language with a bit of type safety for the use of Tinkerpop Pipes (https://github.com/tinkerpop/pipes/wiki). So my question still stands, is something like this possible?

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 13:09
	If you draw your stick-man Person and Car diagram with graphical GOPRR, you'll get what you want. Your lower diagram is not exactly an instance of the upper one, at least not a stereotypical one, but it is a graph that you expect to conform to the structure and rules defined in the upper one. That kind of "conforming" is exactly what the relation is between a model and its metamodel. If you don't define any properties for the object and relationship types in the graphical GOPRR diagram, but instead just make the resulting symbols for Person, Car, Friend and Owns include the name of their type, you'll have what you want. (The symbols could even be automatically generated: they are just SVG in the MXT metamodel XML format generated by graphical GOPRR.) Looking at the Pipes framework, there is also the possibility to go further. Rather than just a constraint on what can be connected to what, as above, you can look at each relationship in the bottom diagram as a type transformation. The Friend relationship transforms a Person into another Person(s), whereas Owns transforms a Person into a Car. Pipes also has other kinds of transforms, e.g. fetching a property. Fetching the Name of a Person results in a String, and thus the legal operations on that are a different set. That would correspond to a new String object in your top stick-man diagram, with a Name relationship from Person.

treo Members Profile Send Private Message Find Members Posts Add to Buddy List Member Joined: 31.Jul.2013 Points: 6	Post Options Post Reply Quote treo Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 14:04
	Yes, my example is a bit overly simple; In my actual scenario there are over 20 kinds of Nodes and about 40 kinds of Relationships. Each Node Type and Relationship Type also has different attributes. What I'm looking for is the more complex Model that you described in your last paragraph. Though I am still lost on how to create a modelling language for it. Even more so how to keep the premise that the language will indicate if I do something wrong (like accessing a attributes that is not available, or traversing to something that is not accessible). Going from the Person-Car-Graph-Structure and assuming the Person also has the attribute Age. And assuming that each Relationship in the Traversal Graph is a Transformation between two typed Positions: Would the following be good models to describe the following Questions: "Which Cars do my Friends under the age of 35 drive?" "Which Cars do my Friends under the age of 35 drive, that also have more then 10 Friends?" And how would I highlight invalid accesses in this?

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 15:00
	With what I've suggested, you won't need to do any work to highlight invalid accesses: the modeling language for the lower diagram will ensure that the user can only build legal models. Go ahead and build your stick-man model in graphical GOPRR: (It's obligatory to specify the roles. I just defined "from" and "to" for the Friend relationship, and when creating the Owns relationship reused the same ones with Add Existing.) When you press the Build button on the toolbar, you can then create models based on that metamodel: MetaEdit+ will only let you create legal relationships - no "Person owns Person" slaves :). The symbols for Person and Car come automatically, I just defined symbols for the "to" role and the Friend and Owns relationships. I've attached the results as a MET file that you can import into the GOPRR project. Edited by stevek - 31.Jul.2013 at 15:03

treo Members Profile Send Private Message Find Members Posts Add to Buddy List Member Joined: 31.Jul.2013 Points: 6	Post Options Post Reply Quote treo Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 15:23
	Thank you Steve for the example, but how would I extend this to model the two Queries/Traversals/Questions that I described at the bottom of my last post? In the Graph Structure there is no Concept of a Filter, Traversals, Aggregation or Comparisons, so the modeling Primitives for them would not be automatically created/updated when I create/change my GOPRR model of the Graph Structure.

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 15:31
	See my last para about String in the earlier message. Similarly Aggregate would be defined in graphical GOPRR as a relationship from Person to a new Number object type (you called it Count, but I think Number will be better long term. "Count" refers more to the operation than the type of the result). Of course some of these relationships may be generic - I imagine you could have Aggregate of Cars as well as Persons, and you wouldn't want to have to draw all the possible Aggregate relationships manually in the graphical GOPRR model. Instead, you can use inheritance, giving a supertype to all such object types, and define Aggregate as a relationship from that supertype to Number. In the "instance" model that will allow Aggregate to be drawn from both Person and Car to Number.

treo Members Profile Send Private Message Find Members Posts Add to Buddy List Member Joined: 31.Jul.2013 Points: 6	Post Options Post Reply Quote treo Report Post Thanks(0) Quote Reply Posted: 31.Jul.2013 at 15:42
	Great :) So that leaves only one thing: Filtering. For Filtering by Attribute I would have to create a Relationship from the supertype to the supertype, and it should have a property in the generated model where I can tell it on which attribute it should filter. When a user selects an attribute that is not available, it should be some how highlighted. Also, I'm not quite sure how I would create the more complex filter that you can see in the second picture.

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(1) Quote Reply Posted: 31.Jul.2013 at 16:13
	Filter is where you start having to make decisions about what language you want. There are a number of ways, ranging from "simple for the modeler" (can just pick an attribute, a comparison operator and a value) through "simple for the metamodeler" (just a string where the modeler writes any code that gives a boolean result) to "powerful for the modeler" (either a string like that, or then a relationship to a new Boolean object type, which gets its value from some other traversal - e.g. like your second picture). As always with non-trivial decisions in language design, these are all trade-offs, and nothing is the "right" or "perfect" answer. I'd suggest steering away from "powerful" - people who want the fully gory details of type systems and long chains of Boolean logic will probably prefer the existing textual languages or DSLs to this graphical language anyway. You don't really want Filter to be a relationship on the supertype, because its output (the object at the "to" end of the Filter) is different in each case: Person->Person, Car->Car. If you say GenericObject->GenericObject, you also allow Person->Car and Car->Person filters. Also, you want each Filter to be different, so it can offer the modeler the appropriate set of attributes (Name and Age for Person, Make and Model for Car). You could define a PersonFilter relationship from Person to itself in the graphical GOPRR, giving it a FixedList property that lets the user choose from each attribute of Person, another FixedList for choosing a comparison operator, and a String property to enter a value (or to be more precise, something that when evaluated results in a value of the right type). By changing graphical GOPRR and its generators, you can also make that automatic: each object type would specify a list of its attributes (similar to but not the same as GOPRR properties), and the MXT generator would create the Filter type and its roles and binding, without having to draw anything extra in graphical GOPRR. For the more complex filter, just think about it in the same way: what do you want users to be able to draw, what are the object/relationship/role types involved, what properties do they have, and how can they be combined. One way might be to have an extra "read from role" entry in the attribute FixedList, that would go with an extra role into the Filter relationship. That extra role would chain into a traversal (as in your complex example), whose final element would be expected to result in a value for comparison with the operator and value specified in the other properties of the Filter. I don't think the box you've drawn around the complex condition would be necessary. Having the Person object duplicated at the start, and the Count object's Compare linking to the box, raises interesting questions about the semantics and language design of Pipes itself. Not being an expert on that, I'll have to leave those details to you! Do start actually building and playing with this. Get the simple, well-understood things working first, before tackling the more demanding questions. That way you have the experience, context and understanding you'll need to make the right decisions.