Conversion GraphML about database HOT 12 CLOSED

JB: be careful when you say things like I actually enjoy doing XSLT coding. Children may read these lines and develop weird ideas…

from database.

Ok, well, I was initially thinking that we should use TEI as canonical data format, and then, convert everything from/to TEI, but it can actually be harder than direct conversion.

I would be for an automatic trigger. You have example of that in: https://github.com/OpenStemmata/database/blob/main/.github/workflows/pull_request.yml

from database.

And we have already the TEI code prepared, and the ODD with it. We "just" need to have the code from gv to tei… TEI is important because it is the standard format, but it does not prevent using other formats I think. So two options:

1. Offer graphml files
2. Offer the script that people can do it on their own

from database.

I agree, that it is important to offer the TEI format. However, I think it would be nice to offer GraphML as well, because it is a more common standard for network analysis and can be useful for many people who want to explore the data.

I don't think Gephi or Cytoscape open TEI. Gephi opens the .gv file, but only the id and label attribute are imported, all the other attributes (style, color) are lost. Cytoscape does not support it. There is supposed to be an extension for that, but it did not work for me.

I also had to do small adjustment when importing the DOT with NetworkX in Python, because the quotation marks were a little off.

So, as I have already written the script that can transform from DOT to GraphML, probably it would make sense to do automatic conversions and offer the resulting GraphML as another format on top of DOT and TEI. If you agree, I will try to look into setting the trigger.

from database.

You are absolutely right: totally ok for graphml or anything else. To me, the problem is that we cannot have 3 times the same file in different formats. It raises to many problems of maintenance: which one is the good one? If needed which one do I change, etc. So, personally, I would favour a solution like:

1. offer one format only
2. and the scripts to transform this data

Would you agree on that approach?

from database.

I could agree on something like that.
I'm wondering if we should still at least offer TEI and DOT. But we can keep discussing that in #38
In any case, it's fine by me if we don't include GraphML, but just a script and a brief explanation of how to use it to get that format.

from database.

OK. We let you deal with this script? And I keep working on the conversion in TEI? If I find more than 2mns free in my crazy schedule?

from database.

Yes, I'll take care of the conversion to GraphML. I'll consider again if I should do it from the DOT or the TEI, but sure, I'll take care of it.
In the corrected abstract for the EADH, we can just include that we plan to include scripts for the conversion into GraphML, then. I can take care of that.

from database.

@GusRiva : if you want me to write the XSLT for TEI to GraphML, please tell ! I actually enjoy doing XSLT coding.

from database.

By the way, despite the satisfying aspect of using most expressive language (TEI) as canonical data model, and transforming from it, to contradict myself, I see there does not seem to be any ready made TEI to GraphML conversion…

And, at least in 2011 according to Sebastian Rahtz, nobody was using the TEI graph module … (but things have hopefully changed), http://tei-l.970651.n3.nabble.com/tei-graph-module-and-graphML-td3184322.html

But we could ask around.

from database.

GraphML and this TEI graph module are so similar that I can imagine an XSLT transformation should be relatively straight forward, although there might be unforeseen difficulties.

from database.

GraphML is created automatically together with the TEI (see #84 )

from database.