Related to graphology/graphology#497

It seems to me the specs are not particularly precise regarding what the <meta> section should accept, but the xsd schema seems to indicate you should only be able to specify <creator>, <description> and <keywords>. What's more, I think I already found gexf in the wild having arbitrary tags there, notably <title>.

Should we amend the xsd schema to fit usage? Am I hallucinating this usage? What was meant to be accepted here?

The meta lacks a proper title

@mbastian said

• Add an optional edge kind attribute: This is the base of the property graph and defined some kind of label that defines the nature of the relationship. Unfortunately we already use type (for directed/undirected) and label (unique string for each edge) but "kind" seems clear enough.
• idtype: The current 1.2 specifications describe an idtype attribute one can set on graph to configure the type of element ids. This is actually something that we never implemented in the import/export and could now be done because GraphStore supports it. So I suggest to start supporting this and also add long in addition of string (default) and integer.
• slice mode: To make the distiction between dynamic graphs contained into a single GEXF (i.e. our current 'dynamic' mode) and dynamic graphs contained in a collection of GEXF files I suggest to introduce an additional 'mode' attribute names 'slice'. The possible values are currently 'static' (default) and 'dynamic'.
• Add a new “hex” attribute to viz:color: It would allow to use things like hex=“#FF00FF”. I would suggest to support alpha there as well.

Something I forgot to mention, we've modified the array support. The 1.2 format supports something called a "liststring" which is basically an array of strings and would be able to parse something like foo|bar where | is the separator. This wasn't very well done and @eduramiba improved the underlying array parsing and printing code so we can parse things like [foo, bar], foo,bar or even ["foo", "bar"]. We've also added new types: listboolean, listinteger, listlong, listdouble.

I understand that GEXF's design is mostly done around Gephi, nonetheless, it may be a good idea to try to keep track of other Graph XML formats providing similar support. This could bring ideas about needed/desired features for both GEXF and Gephi. Here are a few examples:

• DGML: Directed Graph Markup Language (link)
• GraphML (link)
• DGML: Directed Graph Markup Language (link)
• XGMML: eXtensible Graph Markup and Modeling Language (link)

XML formats used in Phylogenetics (some interesting features to consider for GEXF)

• PhyloXML (link)
• NeXML (link)

Hi,

the wiki is really nice to read and use. I've just found that it was a good practice to add the count attribute on nodes.
It could be nice if you were adding it by default on the code samples so people do not forget (or even think) to put it in their gexf files.

I tried to validate a gexf file version 1.3 with xmllint version 21003 as described in the documentation, but I got following error:

$ touch test.gexf
$ xmllint -debugent -noout -schema http://gexf.net/1.3/gexf.xsd test.gexf
new input from file: http://gexf.net/1.3/gexf.xsd
new input from file: http://gexf.net/1.3/dynamics.xsd
new input from file: http://gexf.net/1.3/viz.xsd
http://gexf.net/1.3/gexf.xsd:22: element element: Schemas parser error : element decl. '{http://gexf.net/1.3}graph', attribute 'type': The QName value '{http://gexf.net/1.3}graph-content' does not resolve to a(n) type definition.
http://gexf.net/1.3/gexf.xsd:43: element element: Schemas parser error : element decl. '{http://gexf.net/1.3}node', attribute 'type': The QName value '{http://gexf.net/1.3}node-content' does not resolve to a(n) type definition.
http://gexf.net/1.3/gexf.xsd:51: element element: Schemas parser error : element decl. '{http://gexf.net/1.3}edge', attribute 'type': The QName value '{http://gexf.net/1.3}edge-content' does not resolve to a(n) type definition.
WXS schema http://gexf.net/1.3/gexf.xsd failed to compile
new input from file: test.gexf
test.gexf:1: parser error : Document is empty

NetworkX is the goto Python library for graph manipulation and already has a GEXF import/export.

Definition of done

• Import/Export are fully 1.3 compatible (based on what is possible given networkx internals)

When using Gephi, I receive warnings that 1.2draft is deprecated. However, it also appears that 1.3 is a "work in progress."

Could you please advise on the appropriate way to produce a gexf for importing into Gephi? Thanks.

https://gephi.org/gexf/format/

• Communication
  • Issues
  • Discussions

should point to github. Issues and wiki instead of https://answers.launchpad.net/gexf

Goals are

1. to update the RelaxNG specifications so XSD files can be generated. Sources for 1.2 version are in specs folder.
2. update the PDF primer document. Latex sources are in the primer document.

but maybe find a way to allow backwards compatibility via hierarchy.rng

Now that we have a repo would it make sense to move the old pdf/tex primer materials into the repo's wiki?

No proper reference to the slice mode is contained in the primer

I realised we don't specifically mention a license in this repository.

I suggest https://creativecommons.org/licenses/by/4.0/ but I'm open for suggestions

gexf 1.3 could change to xml 1.1. I think it should be the default, but we'll have to make sure that this doesn't interfere with xml1.0 dates e.g. when importing gexf1.2 graphs.

Discuss legend specification: https://github.com/gephi/gexf/tree/legend/specs/1.3.1

@mbastian wrote

• Add a “timerepresentation” enum in : The value would either be “interval” or “timestamp”. Interval would the default so we’re backward compatible. This configures the way the time is represented and we choose not to mix the two so it's needs to be explicitly set.
• Add a “timestamp” attribute to : This allows to define a timestamp for the entire graph. That’s the corner stone of supporting collections of GEXF files where each is a slice with a timestamp value. Essentially, it means that each element in the graph exists at this timestamp. If the attribute columns are dynamic we would also set values at that time.
• As we want a “timestamp” attribute for we should revisit the meaning of the “start” and “end” attributes in as well. Right now, they define the dynamics' bounds but that could be inferred from the data as well by taking the min and max so I don't think it's very useful. Instead, it could define the interval for the entire graph like the new "timestamp" would do.
• Add a “timestamps” attribute to node/edge: Add an array of timestamps. Each of the element in the list should follow the format agreed on in "timeformat".
• Add “timestamp” to : Defines a unique time 't' for this attribute value.
• Add "timezone" configuration: Timezone can be defined as part of the timestamps themselves (e.g. 2015-01-01T13) but it should be possible to define a global timezone if this is omitted. By default, we would use the local user timestamp.
• consistency between intervals and timestamps: Both time representation should have the same feature. If we allow to define "timestamps" on elements we should also allow "intervals". Similarly if we keep the concept for intervals we should add support for timestamp spells as well.