Vertex/Edge data

[michaelcurry]

As it works right now, you can set a edges weight as NULL, FLOAT, INT but I need to more than one weight on an edge. In other words i need to set an edges weight to an array or an stdClass object.

I also need to set a vertexes data to an array/object.

How hard is this for you to implement? Maybe even adding a new property to each called "data" so you do not have to change the current functionality.

[clue]

Yes, this has been brought up a few times already and IMO it makes perfect sense to add this.

Currently, your only option is to extend (subclass) the respective base classes and add your own options there.

The actual implementation of this feature should be fairly trivial, it's just that we should work out a decent API beforehand. Considering this would eventually become the recommended way to set all attributes, we should cover a couple of use cases.

• Support abritrary data types for custom attributes.
• Nested (namespaced) attributes like graphviz.label.
  Which separator to choose? Explicitly passing the path as an array could be an option?
• Current algorithms should eventually be updated to access attributes as well.
  How should we pass which keys to extract the current edge weight from, for example?
• Can attributes be validated?
  With regards to the previous point: Currently, the edge flow can not exceed the edge capacity and the algorithms take advantage of these limitations.

Wrapping it up, I'm really looking forward to add this feature. Any input would be much appreciated 👍

[clue]

Any input would be much appreciated 👍

This is now one of the high priority tickets as it blocks quite a few other tickets. GraphViz layout attributes will be replaced by the general purpose vertex/edge properties and everything related to GraphViz will be moved to a separate project (graphp/graphviz).

The following pseudo-code is an initial draft of the upcoming API:

class PropertyBag
{
    private $properties = array();
    public function setProperty($name, $value);
    public function getProperty($name);
    // probably a number of additional methods
}
class PropertyAware
{
    // provide access to the whole property bag for advanced operations
    public function getPropertyBag();
    // additionally, we should provide two convenient shortcut methods:
    public function getProperty($name) { return $this->getPropertyBag()->getProperty($name); }
    public function setProperty($name, $value) { $this->getPropertyBag()->setProperty($name, $value); return $this; }
}

class Vertex extends PropertyAware { }
class Edge extends PropertyAware { }
class Graph extends PropertyAware { }

And the following demonstrates how this can be used:

// $edge->setWeight(100);
$edge->setProperty('weight', 100);

// $vertex->setBalance(10);
$vertex->setProperty('balance', 10);

// $edge->setLayout('label', 'some text');
$edge->setProperty('graphviz.label', 'some text');
$vertex->setProperty('graphviz.shape', 'none');
$graph->setProperty('graphviz.id', 'mygraph');

[clemens-tolboom]

Guess we need some bulk operations like:

• PropertyBag::setProperties, ::getProperties
• PropertyAware::setPropertyBag

to manipulate multiple properties like defaults at once

[clemens-tolboom]

from irc @another_clue wonders wether

PropertyAware::setPropertyBag

is a good idea. I guess now it's not as that would allow 'sharing' the same bag which probably introduce tricky bugs. Bulk ops on PropertyBag should be enough.

[michaelcurry]

I like the pseudo-code code, but I do agree it would be nice to get a list of all properties that exists on an edge / node / graph. Also a default __toString() would be nice as well.

If you write the pseudo-code i will make a pull request to add other functions.

[clue]

After discussing the naming in IRC (#graphp on irc.freenode.net) we came up with the following:

• The name "property" might be misleading with regards to the properties of a graph (see Algorithm\Property or http://en.wikipedia.org/wiki/Graph_property)
• However, the name "Property Graph" describes our approach quite good (see http://en.wikipedia.org/wiki/Graph_database and https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model)
• The name "parameter" might be misleading with regards to parameters passed to a function
• The name "attribute" seems to fit and it also used elsewhere, hence we should stick with it as well

[clue]

@michaelcurry thanks for your interest, I've just opened PR #103 to implement the first batch of methods for the new attributes.

it would be nice to get a list of all properties

Absolutely! I've added a getAttributes() and getNames() method and I'm sure more will follow as we're in the process of working out a decent API. So any input is appreciated!

a default __toString() would be nice

Perhaps you can elaborate on your use case?

[michaelcurry]

@clue Incase I am debugging, it is nice to have a to string that outputs the data in a readable format. ( yes lazy ) Even if it is a jsonEncode() fix.

When do you think we can merge #103 ? Once this is up and running I can use it for my nerd project! 👍

[michaelcurry]

@clue Any update ? 👍