Publishing Custom pyLODE Fork

[seanpetiya]

The OpenWEMI HTML documentation [1] is generated from the TTL using a customized, private fork of pyLODE. Should we move this fork to a public repository?

[1] https://dcmi.github.io/openwemi/ns/openWEMI.html

[nishad]

@seanpetiya, I would like to know what customization is required for PyLODE. This information will be beneficial when I merge this NS documentation with dublincore.org.

[seanpetiya]

Hi @nishad,

We made several, mostly cosmetics, updates in our fork, including:

• Adjusting the order of display for several terms
• Adding support for skos:definition and rdfs:comment, and changing the associated section and display label

I will update this comment with specific commits for reference if the fork is made public.

[kcoyle]

Nishad, the issue is that the changes we made to this display program are in someone's personal github repo. We need to move it to someplace in the DCMI repo area. It may be useful also for LRM (and possibly others). What do you recommend as a place to put this? We could put it in the OpenWEMI area but if it's useful for others it may be logical to find a more general location.

[lagbolt]

We can certainly copy the repo to somewhere public. Someone (lol) will need to rebuild all the applications in the repo. All I did was to change the Python source.

Sean, do you have your own fork which is newer than mine?

[nishad]

Hi @seanpetiya @lagbolt @kcoyle
I have created the repo for the public fork ¹ and invited you as maintainers. Please go ahead 👍

Footnotes

1. https://github.com/dcmi/pyLODE ↩

[seanpetiya]

@lagbolt I did create a fork of your repo, I just submitted a pull request to sync our changes: https://github.com/lagbolt/pyLODE/pull/1

[niklasl]

Hi all! Do you intend to submit a PR of these changes to the upstream pyLODE repository? (It could ease things (such as reviewing) if it was a github fork.)

[kcoyle]

We have been in touch with the PyLode folks. I think we need to document the changes and then create an issue there. The problem is that our code changes the order of some of the display elements, which may not be what everyone wants. I suspect that PyLode would need to create a display order option file that could control different needs. But I'm happy to take our changes to them in the form of documentation.

[lagbolt]

Hi @seanpetiya @lagbolt @kcoyle I have created the repo for the public fork 1 and invited you as maintainers. Please go ahead 👍

Footnotes

1. https://github.com/dcmi/pyLODE ↩

Nishad,

I don't think this will work (although I'd be happy to be proved wrong). I think what we need is an uninitialized repo that we can push to.

We want to preserve the link in my repo that says it is a fork of the official pyLODE repo. If we push to an initialized repo, I fear that the link will be lost.

Unless someone knows how to establish the link after the fact?

[nishad]

Hi @lagbolt, This was intentional; I do not want to maintain the upstream to the official pyLODE repo in the fork for various reasons. This repo comes under DCMI org, and we are yet to have policies on issuing pull requests to external repos. This is a broader issue with many complex edge cases, and unless there is a clear policy, an organisation repo with an upstream for a popular software is not something I want to open now. Due to the absence of such policies, any pull requests to the external upstream should be from individual forks, not from the organization repo. The whole purpose of this repo is to maintain a copy of the custom tooling of the working group, and use the same tools to reproduce the documentation.

Apart from the policy concerns, I want to avoid many long-term management issues too. For example, in the future, if anyone issues a PR from the upstream to the fork and if the working group is no longer active, and if the repository is not archived for various reasons, someone from DCMI will become liable to review the PR and ensure the integrity of the customization and the software. Again, maintaining a public software repository is entirely different from a documentation repository. For the latter, we are well capable.

That being said, I have recreated the pyLODE repo without initializing it. You can set this as an additional remote for your local repo and keep pushing from your local repo of the fork. This way, all the commit history will be maintained, and the org repo will be in sync with your fork.

[kcoyle]

The PyLode people based their work on LODE, and renamed it to reflect their "version". I suspect they aren't incorporating anything from LODE, should such occur. Although our version has only minor differences from PyLode, I suppose we could consider making it our own, separating from PyLode. There are positive and negatives to that, so we should think it through if it seems like a viable option.

[lagbolt]

@nishad I don't have permission to push to the empty repo at https://github.com/dcmi/pyLODE.