Using Github to share openEHR content

Tool Support REQUESTS
22

Done thank you for reminding me.

2 Likes
23

Yes locally hosted AD does support full readwrite access but the problem is that afaik, there is no standard approach to searchable metadata akin to Github. The idea was that anyone creating opnehr model content coukd very easily make that repo searchable.

Ive not so far found anything comporable though interestingly the forked norwegian ckm repo does serm have a topic still attached @siljelb . I canā€™t see any way to add them in Codeberg but perhaps this is work in progress.

24

It took me a while to find it too:

image
image707Ɨ605 45.6 KB

25

I will bring in some other Ideas around this. Recently I have explored how to make multi-repo documentation using Antora. It seems promising so far. The idea is to be able to write project specific documentation in each repo and then be able to aggregate and present one web page with all information searchable and readable. For Templates I use the adciidoc output from AD. This is Inspired by the work we did @ian.mcnicoll .

We might be able write some software to automate the docs from openEHR artifactsā€¦

IMHO this will be important to be able to share our modelling projects around the world.

I think @SevKohler also have some ideas on s project index for transparency.

I would love to se some joint efforts on this. First we will, as @siljelb mentions, try out how to share inter-regional projects in Norway.

26

Can we come back to the original topic?

Iā€™m not wedded to openehr-content . Iā€™d be happy with openehr-knowledge-resources.

The nice thing about Github search (I know!!) is that all that need to happen is for someone to tag the repo with that topic ands it becomes globally searchable, including via the Github API.

That allows folks to easily contribute peer-produced archetypes and templates with minimal overhead, especially if you use a standard repo template like GitHub - freshehrteam/_-freshEHR-project-folder: Standards folder structure for freshEHR projects where the topic label can be preset.

@bna - Iā€™m really interested in this Antora idea. We use that along with our variant of the asciidoc builder to build Implementation guidance for a client. Iā€™m also interested in how we might make use of the FHIR IG build stack.

Iā€™m very open to alternative ideas on how to easily share ā€˜peerā€™ content but so far I cant see anything that matches the simplicity of using Github topics.

@siulje - it does look as if Codeberg has imported the GH topic but I could not find any way to edit that or add one. Also Codeberg for now does not have an API that would allow search. Looks very interesting however.

Correction - I found how to edit Topic in Codeberg. You have ot have code there first

1 Like
27

Nice -we can search Codeberg for openehr-knowledge-resources topics

image
image1024Ɨ562 81.4 KB

even better if it was api-backed so we could combine with GH search.

ah!!!

2 Likes
28

Can we agree on

openehr-knowledge-resources

@bna @vanessap @siljelb @Paulmiller @LindaAulin @amanda.herbrand @sebastian.garde

Would it help to have that endorsed by e.g CPB ?

Also do you think we can agree a standard-ish folder structure as per

2 Likes
29

openehr-knowledge-resources makes sense to me, but I think we should define it. Does this mean archetypes and templates in their original format, or also OPTs, forms, and other downstream artefacts?

I also agree it would be useful to have a common folder structure, but Iā€™d suggest something like this:

Required:

src/ # source artefacts like archetypes, templates, aql files, and source code for logic/scripts/etc
build/ # any downstream artefacts like OPTs, form packages, compiled/interpreted code, etc
doc/ # documentation for the repo

Optional:

test/  # well, tests
data/  # sample data
dep/ # any dependencies
tools/ # any qol tools etc
LICENSES/ # for when a single LICENCE file isn't enough

Ref: GitHub Repository Structure Best Practices | by Soulaiman Ghanem | Code Factory Berlin | Medium

Edit: This is what our current repos look like, but weā€™re looking at making changes to clean it up like in my suggestion above: openEHR-no/templat-repo: Templat for Ć„ opprette nye repositorier. - Codeberg.org

1 Like
30

I realise Iā€™m late to this discussion but I just wanted to strongly +1 @Serefā€™s suggestion here simply because it works for anything that has a URL/URI, not just some content in some code forges.

GitHub tags are ā€˜sort of OK I guessā€™, and I can see a decent amount of thought has already gone into the plan to use openehr-knowledge-resources. The problem is that (as the Norwegian team have done) if someone uses another code forge site (Bitbucket, Codeberg, GitLab, whatever) then:

  • We are reliant on there being a ā€˜repository tagā€™ feature in all possible code-forges, and that it is searchable. (I guess this is quite likely to be true for most code forges though)

  • It soon becomes necessary to search all of those forges in order to get a comprehensive list of all resources.

  • If someone, anywhere in the world, on any code forge, decides to inappropriately tag a thing with openehr-knowledge-resourcesthen that repo will inappropriately show up in your search results and thereā€™s nothing you can do about it.

An awesome-openehrrepository has the following advantages:

  • Total simplicity and robustness - it can list any resource anywhere as long as it has a URL/URI, even if not in a code forge (eg it is on a simple web file server), or if the code forge doesnā€™t have tagging.

  • The list can be curated so we can trust the content of it. Managing it in Git-tracked Markdown and pushing it to a codeforge means we get revision control for free as well, and the full commit history.

  • OK, so I admit the fact it needs to be curated is also a disadvantage since somebody has got to do this, but firstly I donā€™t see this stuff changing on a very frequent basis, so itā€™s not a huge task, and secondly Merge Requests/Pull Requests are our friend here, those wishing to include new content can submit a PR and the curator simply accepts if appropriate.

  • It is probably not that hard to parse the URLs out of MD/text if automated/CLI tools are desired, as per @ian.mcnicollā€™s gh CLI search. (We are eventually going to need an openEHR Knowledge Artefacts Package Manager of some kind anyway, and at that point we might want to publish more structured metadata about each artefact, but that feels a way off if we donā€™t yet have a canonical folder structure in widespread use.

Thereā€™s nothing stopping us from doing both things - tags and an awesomelist - but Iā€™d reckon the Markdown/plain text awesomelist version would be more likely to remain canonical - as 2025ā€™s frankly bonkers geopolitical daily comic strip shifts the perception of using GitHub and other US-based services.

2 Likes
31

Yes letā€™s do both. My main concern is the governance of what is ā€˜awesomeā€™. If itā€™s really awesome it should probably be in CKM anyways. Other than that itā€™s super arbitrary. We could make sections in the list off course. And even automated additions based on GitHub/code berg tags, assuming itā€™s available over api (codeberg doesnā€™t support this I understood?).

1 Like
32

It does, Ian posted the link to the API doc:
Forgejo API

2 Likes