Allows know-how to be discovered, indexed and linked to using meta-data about the thing and the location of know-how.
Level 2:
Portable Know-How
Provides a format and structure for know-how so that it is represented in a consistent format and can be easily moved between platforms.
Level 3:
Distributed Know-How
Supports interoperability, creation and aggregation of know-how about a thing by different designers and makers without centralised control of the know-how.
Seems reasonable, as we’re expecting maturity level to be a small and finite set. I expect it will grow beyond the three listed, but that’s a ways off, if we’re lucky enough to get there. So yeah, +1 to this proposal.
I would suggest that we could also use the existing labels (Discoverable, Portable, Distributed) without numbering/lettering of each level. I understand that the numbers / letters imply a hierarchy of levels which will be lost if they are removed, but the text below this table states that:
The intent behind the maturity model as presented is that the more of the recommended and permissive aspects of this specification that are adopted, the more open the know-how becomes
So the intent seems to be more in terms of levels of openness rather than a “hierarchy of standards” as such.
Listing them as a hierarchy also implies that each of these levels has some kind of hard dependency on the preceding one. IMO, in priciple at least, you can have a way of describing/packaging know-how for portability without it being discoverable—i.e if I had access to the files on platform A then there could be a specification for moving a project’s files from platform A to platform B without the existence of a specification for making the files on either platfom discoverable (in the sense of crawling/indexing). We are, of course, aiming to make the portability, interactivity and discoverability specs “interoperable” (e.g. in the sense that any metadata required by each of these specs is standardised) but I don’t see these as necessarily in a hierarchy.