-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
metadata format #140
Comments
Very much agree! I would keep the file-extension though.
From a purely technical point of view, it should be TTL only. Apart from that, there are different alternatives:
It is a hard decision. From my experience, people will never end up choosing TTL, out of fear of non-acceptance. I think that is bad, but ... does it make sense for me to try to push it against the majorities will? no. |
Great reply, thanks!!
The current metadata approach relies on linking between other metadata files. From my naive perspective of very limited coding experience I assume that this is possible Independently from the file format (as I could just place a link in a YAML file). My suggestion based on your input:
→ for me that's (almost) enough to take a decision in our next meeting. @hoijui any suggestions for widely accepted file formats that wouldn't be too much effort to convert to TTL when following a standard structure/template? (TOML, YAML, JSON,… ? :) ) |
Sorry for my ignorance, but is "TTL" this format? As for file format (TOML, YAML, JSON, etc.), I am aware of the ongoing discussions. Sorry I didn't follow all of it so it might have already been discussed, but: From my experience it is useful to ease entry and onboarding, especially if one of our aims is to promote open source hardware. To that end, I think it would be good to use a file format that is more human-readable and easy to understand at-a-glance. An extreme example is that Markdown is much easier for a human to parse than dense HTML or even LaTeX. I certainly don't think Markdown is the format to use in this case, but of the options already presented, is there one that is more human-readable? Is this factor worth considering? (honest question) |
@penyuan thanks for reaching out!
|
Thanks @moedn for your encouragement! 😃 Understood, makes sense. I actually don't think Markdown is good as a data/metadata format, it was just meant as an extreme example of high human-readability. But yeah, maybe it'll be good to have a Markdown-formatted "for-humans" descriptive/summary document that accompanies the formal manifest file? If there is such a summary (filled out from a template, of course, as you suggested), then the manifest file itself doesn't have to be very human-readable. That said, if the specification requires both a manifest file and a Markdown summary based on a template, it's more work for projects that want to use it... |
In today's meeting we agreed on: |
The issue
How is metadata actually delivered? OKH suggests a 'manifest file' (see 4.3 here) that is
okh-thingname.yml
)I generally like this approach for it simple & effective nature, it appears stable and decentralised for me. However, some details:
The background
Just created a new task within the new research project Open.Choice (still just a proposal ← the project, not the task). The project aims to enable decentralised production, maintenance and modification of COVID-19-related hardware. This metadata standard and the OSHI appear as important building blocks for that.
The text was updated successfully, but these errors were encountered: