OM
OM copied to clipboard
HajoRijgersberg
Merge UCUM codes into OM2.0
I can generate rdf/xml easily as well, for the OWL-API and TopBraid serialization styles.
Hi Simon, Thank you so much for your effort! There is only one problem for me: I'm maintaining only the XML version of OM 2.0, manually to keep the file well organized. So I can't maintain several versions of OM 2.0. I see you created a turtle file. Could you somehow, with some script, insert the productions in the XML version of OM 2.0? I know I'm asking something difficult or labor intensive... But I can't leave the way OM is organized, that would be a real pity... Looking forward to hearing form you! And sorry for my late response! Best, Hajo
I clicked 'Resolve conflicts' and it seemed that the entire code in the file is doubled. Could you resolve that, Simon? Do I see that correctly?
Since I don't know your serialization rule, then I can't really do that.
I would strongly recommend using a standard serializer, such as OWL-API or TopBraid 'export'. These all support multiple representations (RDF/XML, OWL/XML, Turtle, JSON-LD). This might require the rest of your publication toolchain to also be updated, but it will make your system more compatible with other RDF and OWL systems.
No, the file isn't doubled. It is just that GitHub computes diffs on a lexical basis. Since the order of statements in an RDF file is essentially arbitrary, any change in the order, which has no effect on the semantics, shows up as a huge change in GitHub.
This is why it is best to use a standard serializer, because that will sort the statements the same order every time, so only the small changes show up in the diff.
Since I don't know your serialization rule, then I can't really do that.
Ah, that's a pity. I'll put it on my to-do list, although I don't know when I can make time for that. But I'll try!
I would strongly recommend using a standard serializer, such as OWL-API or TopBraid 'export'.
I understand your advice, but I really cannot give up the well-organized structure in the text file. It is very valuable, a.o. for maintenance reasons. It is also structured in a range of (pseudo) subontologies, ever in a farther future meant to decompose OM in unit ontologies for specific domains and maintain these. TopBraid, Protégé and I guess other editors really make a mess of the text file they create or alter..
No, the file isn't doubled. It is just that GitHub computes diffs on a lexical basis. Since the order of statements in an RDF file is essentially arbitrary, any change in the order, which has no effect on the semantics, shows up as a huge change in GitHub.
Thanx, I'll give it another try. I will inspect the first half only. Indeed, the viewer on the 'Files changed' page shows the file as it is, not doubled. It's peculiar.
So, if I see correctly, there is only one change: the fix for wattPerSteradianSquareMetreHertz. I'll accept it! :)
Do you know how I can resolve these conflicts? (The conflicts that actually aren't there; it has to do with the doubled (representation of the) file? 'Merge pull request' remains disabled... :/
What I was attempting to do was to merge the UCUM codes into the master om-2.0 graph.
Merging RDF graphs is easy - you just concatenate them. Then the next time you load the concatenated file in your RDF IDE - Protege or TopBraid, etc, - you can just re-save the graph, and it will re-sort it according to its serialization rule.
But if you are not using an IDE to edit and save, then life will be much harder. In particular, if you require a specific serialization rule to be followed which is different to the standard serializers, then collaboration on the code-base is essentially impossible.
Correct, I am working in a text file, manually, because I am working with subontologies, that is: I have made a prestep towards future decomposition of OM 2 in subontologies. But what I meant was: In Github I cannot seem to merge the pull request, because the button remains disabled, whatever I do. It says that this branche has conflicts that must be resolved, and if I click 'Resolve conflicts' it shows the "double" file. Do you know what's the problem here with Github?
I really appreciate all your efforts, also creating the turtle version of OM. I am looking for a way that I keep my well-organized RDF XML file, and the turtle files you created. It has to be manageable for me of course. Not sure yet how to do it. I'll keep you updated.
There are standard techniques for decomposition, using owl:imports. If you follow this then standard file management and serialisation can be used, and collaboration becomes possible.
I know, thanx. But I am not yet ready with the full design of subontologies. It is on my list!
I have fixed the UCUM code for wattPerSteradianSquareMetreHertz in the file itself, Simon, and uploaded it to the Github. Once again, thanx for your effort! :)
@jmkeil , would the automated generation of ttl versions of OM be something as well for the pipeline approach that you suggested?
@dr-shorthair , Jan Martin has validated om-2-ucum.ttl using ABECTO. And he has proposed a number of corrections for errors that his method has found. It is in the other open merge pull request that we have at this moment (https://github.com/HajoRijgersberg/OM/pull/70). There is a more complex merge conflict there, once that one has been resolved the errors will be corrected.