Is there are some existing SOLID client-to-client standards I could read to help me build a new one? Or some guidelines somewhere?
I’m working on Mycelium, a SOLID based digital commons for food producers. The idea is to provide interoperable apps for managing the entire activity (products, invoices, planning, distribution and so on).
Mycelium uses and co-develops the Data Food Consortium (DFC) ontology (old visual here). We are also building a model (UML) and a connector (currently TypeScript and Ruby) which is generated from the UML via model-to-text transformation (thanks to Eclipse Acceleo).
I’m trying to make a standard on top of the DFC for Mycelium. I have defined a basic document hierarchy and some index files. I’m wondering if there is any template I could use to publish the standard?
Storing data in the pod using a specific ontology is an important step, but not sufficient. There are more conventions that need to be described. It’s not just about the choice of ontology, you also need to document which data shapes you expect, what information can be derived from for instance the folder tree, how ACLs are expected to be set, which indexes need to be kept up to date, etcetera. All of those conventions together define what expectations a second app can have when reading data from a pod, that was written there by a first app.
Hi @renyuneyun, yes like @michielbdejong said, the ontology is not sufficient, we need to specify how an other app could find the right data.
@michielbdejong Is there any resources which describe the kind of information a client-to-client standard might have (like the list you started)? And maybe some hints on what we should think about when making this sort of standard?
Right now your best option with publically available specifications is probably to add this information to a type index when you write to a Pod; so any other apps that use type indexes can find the location of the data that you wrote. If you need help with the spec @Timea might be able to lend a hand.
It’s not just about the choice of ontology, you also need to document which data shapes you expect […] all of those conventions together define what expectations a second app can have when reading data from a pod, that was written there by a first app.
I largely agree with this, and it is one of the reasons why I (personally) see type indexes as useful/necessary in the short-term but not a mid-long term feature of Solid; as they are unable to express these kinds of requirements.
In Solid QA, we are documenting how to make significant units of information in specifications available, in particular test suite tooling, test assessments, and test reporting. Part of that involves the use of Spec Terms: http://www.w3.org/ns/spec.