You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In REUSE (which is limited to licensing related file centered meta-data),
meta-data related to a file can be in 1 of three places,
with the following priorities (from highest to lowest):
in the header of the file its-self, if it supports comments
In a file with the additional extension .license and otherwise the same name, eg. my-doc.pdf.license
In a repo-global file: .reuse/dep5
We could almost ... reuse ( ;-) ) this whole thing as-is - I would say - except that we should probably use a more general file extension then .license. That extension should rather indicate that it contains general meta-data for the file, so it would not be limited to licensing and/or OSH, but to whatever. I Made a proposal with REUSE for this, to make their system more reusable.
In the end, what this would mean for us, is that we would get the power of tags, vs only categories and sub-categories we have with a pure directory standard.
I can already see now. that we are running into very deep and complex debates about how the structure should be and why, and that often, there are simply no optimal solutions, because many files .. in a way, should be in multiple places, or it is unclear where they should be, and files that should be together in one way of looking at it, should not be together (in the same sub-dir) in an other way of looking at it .... and all this, in the end, means we get way too much complexity. We will end up with a highly complex, bureaucratic system, that only machines are able to get right, while they can not have all the info they need to do it right. People on the other hand will never know where to look for or put files, and will end up looking for them in the whole, deep, complex tree we prescribed to the repo. For a little idea of this, you could look at issue #6.
With a tagging system, we could make the directory structure much simpler - mostly just grouping files in a way we might want to git-sub-modularize them in - and do the rest with tags like:
licensing
bom
generated
resource
image
video
software
hardware
mechanical
electrical
source
configuration
firmware
documentation
manufacturing
assembly
user
The text was updated successfully, but these errors were encountered:
Brain-stroming about possible file extensions with Timm,
these were some guiding words:
Meta
Data
Open
ReUse
Shared
Properties
extensions:
.remeta
.remix
.reuse
.metaod
.metod
.ometa (pattern matching language, but free as file-extension)
.meta (used for Unity engine data files and at least 3 other software)
.ometad
.omd (used for Prosa/OM Class Model files)
.romd
.rsomd
.rsmeta
.osmeta
.someta
.om (used for Omicron Compiler files, a math expressions programming language)
.lm (An LM file is a language model file used by Microsoft Windows and Microsoft applications. It contains statistical data used to show predictive text in Windows and Microsoft applications.)
.o_meta
.open_meta
.openmeta
.openm
.metadata (METADATA files mostly belong to Apple Metadata. A METADATA file contains Property lists && Acronis True Image metadata)
.meta4data
.met4data
.met4d4t4
.met4
.m3t4
.m374
.metap
.properties (mostly used for Java properties files, but could be re-used as-is, and others already do that too!)
... I like that last entry a lot.. let's reuse an already existing format.. any others?
This one would also be (one-way) compatible with the currently used one for .license files, I think!
Instead of (or in addition to) this dir standard.
In REUSE (which is limited to licensing related file centered meta-data),
meta-data related to a file can be in 1 of three places,
with the following priorities (from highest to lowest):
.license
and otherwise the same name, eg.my-doc.pdf.license
.reuse/dep5
We could almost ... reuse ( ;-) ) this whole thing as-is - I would say - except that we should probably use a more general file extension then
.license
. That extension should rather indicate that it contains general meta-data for the file, so it would not be limited to licensing and/or OSH, but to whatever. I Made a proposal with REUSE for this, to make their system more reusable.In the end, what this would mean for us, is that we would get the power of tags, vs only categories and sub-categories we have with a pure directory standard.
I can already see now. that we are running into very deep and complex debates about how the structure should be and why, and that often, there are simply no optimal solutions, because many files .. in a way, should be in multiple places, or it is unclear where they should be, and files that should be together in one way of looking at it, should not be together (in the same sub-dir) in an other way of looking at it .... and all this, in the end, means we get way too much complexity. We will end up with a highly complex, bureaucratic system, that only machines are able to get right, while they can not have all the info they need to do it right. People on the other hand will never know where to look for or put files, and will end up looking for them in the whole, deep, complex tree we prescribed to the repo. For a little idea of this, you could look at issue #6.
With a tagging system, we could make the directory structure much simpler - mostly just grouping files in a way we might want to git-sub-modularize them in - and do the rest with tags like:
The text was updated successfully, but these errors were encountered: