moedn
commented
2 years ago Just answered a mail from OKH regarding this. I'll quote it here :)
1) Just to make this clear: I won't argue to replace OKHv1 with OKH-LOSH. OKH-LOSH was great to explore the potential of the OKH specification, but I'm yet unsure if it fully reflects the expectations of the rest of the working group. From my perspective, it's a promising base for OKHv2; it would surprise me if no change requests would arise during this process.
I don't want to spam you with information, so I'll try to summarize things :)
the current draft of OKH-LOSH is accessible here: https://github.com/OPEN-NEXT/OKH-LOSH/blob/master/OKH-LOSH.md
derived ontology here: https://github.com/OPEN-NEXT/OKH-LOSH/blob/master/OKH-LOSH.ttl
both documents have flaws, you will encounter errors in them
there's a document in which I noted down the main differences that would come into play when converting OKHv1 → OKH-LOSH
https://github.com/OPEN-NEXT/OKH-LOSH/blob/master/data_mapping/data-mapping-OKHv1.md
there's also a tool doing this conversion: https://github.com/OPEN-NEXT/LOSH-OKH-tool
our main expert for the differences between both specifications on the data level is Robin (CC), please invite him to the meeting if not done already
when drafting OKH-LOSH, mainly the following considerations have shaped it:
OKHv1's approach of a human-readable file format for metadata input (manifest file) keeps the threshold low for non-techies → will be kept
however, looking onto previous, extensive discussions, OKH-LOSH uses TOML instead of YAML
OKHv1 includes lots of optional fields
a significant part of the issues in it's repository argue about these fields; it seemed hard to find a consensus since there was no superordinate statement on how detailed data collection should be. it can be boiled down to: "more data is better" vs. "keep the specification simple & readable" this point has not been resolved in OKHv1 yet (as far as I know)
many of these optional data fields are not used in practice
see https://github.com/OPEN-NEXT/D3.3-Report/tree/main/raw%20data/OKHv1%20Test%20Crawl
Appropedia already forked OKHv1 a long time ago, introducing own data fields (such as relevance for SDGs)
together with the previous point: relying on manually created manifest files is very limiting; lots of metadata is already available on OSH online platforms via their API → OKHv2 should accept different data specifications (as e.g. Thingiverse delivers other data than OSHWA or Wikifactory); OKH-LOSH aims to bridge these gaps and make data explorable across these platforms. This is where RDF came into play
this would also resolve the discussion about specific data fields → messy data is not an issue anymore, when using RDF
the main task of OKH-LOSH was then to provide a stable structure and "interfaces" for data specifications from different platforms. After analysing OKHv1 in depth I found that it is lacking of a suitable structure and decided to fork it instead of applying minor fixes to itA comment on common misconceptions about OKH-LOSH:
"RDF is overkill" → RDF is exclusively used in the backend, where data is processed and linked. no users was ever intended to read or write RDF files. In practice OKH-LOSH is (for users) either as simple to use as OKHv1, per manifest files, or even simpler as per direct integration of a platform's API (so they don't even need to read or understand the specification to share metadata about their OSH)
not sure, but I assume it would be technically possible to use linked tables for data processing instead of RDF in order to achieve the same, but I don't really see the point behind this
"OKH-LOSH is a competing specification" → we aim not to be. for LOSH it doesn't make a big difference whether metadata is provided following OKHv1 or OKH-LOSH. Of course, the latter is richer and simpler for us, but the crawler (+scripts) supports both. Yes, there are 2 metadata specifications for OSH out there (+ appropedia), but OKHv1 could perfectly work without ever taking notice of OKH-LOSH and LOSH could do the same. However, as you may see from this eMail, I'm very much interested to merge the efforts here. In fact, I've been pitching this for a while since I began with OKH-LOSH ~2 years agoSince this is now addressed and scheduled to be clarified this Friday, I'd close this issue :)
This was the main take-away from my OKH-tools presentation meeting. And I think they are right; it poses multiple problems:
They asked me, why we made a different standard, and I did not remember. :/ I imagined, to have the freedom to change things as we see fit, fast, without having to go through a lengthy discussion process?
Either way, we should come up with a solution; for example merging was a commonly mentioned idea.