The last of what I think are the active Subversion repositories on the old openEHR.org server has been converted to GitHub now (the Archetype Editor). Repositories which appear to be inactive but could be converted if anyone wants:
liu_knowledge_tools (Linkoping has a more recent version of this AFAIK)
the original ‘knowledge’ repository containing a lot of old NHS archetypes
knowledge_tools_java - not sure about this one.
ref_impl_python
For those who have links, checkouts or other pointers to any openEHR SVN repositories, please now refer to the Github openEHR repositories.
Any questions like ‘where did xxx go?’, feel free to post them here.
Apache as something called “The Apache Attic” for unmaintained old projects in order to keep the code/assets somewhere, see http://attic.apache.org/ Perhaps we could simply have an openEHR attic project at github where each unmaintained previous project gets a sub-directory-tree.
If no major objections or counter-proposals are seen within a week from now I’ll assume lazy consensus and create an “Attic” project.
I think an attic is where things like the “liu_knowledge_tools” could go for example. Future web-policies at universities and other places are not always guaranteed to maintain old URLs and content.
will the LiU tools project never be touched again?
Apache has a "Process of leaving the Attic again" see http://attic.apache.org/
I assume we could have something similar for openEHR.
After all the code isn't
exactly last century... maybe it should just have a real project.
Regarding the archetype editor, it contains many workarounds to deal
with the then immutable openEHR Java reference implementation of the
AOM. We tried to argue for changing it to mutable at the time, but
without sucess then. Nowadays the Java AOM is mutable and that should
be considered in any new development, also the LinkEHR project has
interesting pieces that any new java editor should consider. The more
recently maintained LinkEHR editor probably fits many of the use-cases
that once motivated the LiU Archetype Editor.
That said, I think a web based collaborative editor (using javascript
etc) would be more interesting to do rather than picking up the old
LiU Archetype Editor code if there would be any new development
efforts. HTML5 also provides good support for offline mode operation.
The LiU archetype editor also contains javacode for TermViz (disabled
by default), but if anybody is interested in such functions I would
suggest looking at and extending the more recent https://github.com/ErikSundvall/TermViz instead.
So, I'd suggest we currently put the LiU Archetype editor in the
"attic" and if anybody ever wants to revive it they can fork it,
update it and then suggest opening a new active project once they have
something interesting running and a small community of comitting
developers.
it seems that in practical terms, the ‘attic’ is . This is prbably the condition that matters: So would our attic be something like following the rest of the items on the above list, plus create a physical storage location? If the project was already on openEHR@Github then maybe we move it to openEHR-attic@Github? For others which are/were in SVN, what do we do? Maybe the easiest thing is to put the zipped SVN backups on the server, with a page pointing to those archives? one of the problems with LinkEHR (which does have many good features) is that it is driven off XSD. In principle, XSD is already a deformation of any but the most trivial object model, due to its non-OO semantics. As time goes on, it is clear that the XSD expression of data models like openEHR, 13606 etc will be more and more heavily optimised for XML data. This guarantees such XSDs will be a further deformation of the original object model - the view that programmers use. So now if you build archetypes based on the XSD, you are not defining models of object data that software can use (apart from the low layer that deals with XML data conversion). I am unclear how any tool based on XSD can be used for modelling object data (and that’s nearly all domain data in the world today, due to the use of object-oriented programming languages). I’m going off the point here a bit so - what’s your preferred practical version of the attic? SVN archives like above - thomas
now that openEHR is on github, have you realised that WE’RE ALL REALLY WRITING HISTORY?
See, e.g. http://starlogs.net/#openEHR/gdl-tools
Now that’s gonna baffle them at Medinfo!
so - what’s your preferred practical version of the attic? SVN archives like above - thomas