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?
Just trying to understand what “client to client” means here:
Are you thinking of directly fetching data from App A while using App B?
I’m not aware of any; I suspect this is discouraged (at least for now) – data should be stored to Pod, not held by the data consumer (App) unless really necessary.
Or, is it about the interoperability of data stored within the Pod?
You already have an ontology. Can’t you reuse it in the new App? What is your further requirement for interoperability (e.g. a second ontology? a different storage location in the Pod?)?
Some other guesses:
Are you looking for ontological reasoning tools? Or SPARQL-based query tools?
Are you looking for a place to persistently publish your ontology?
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?
we need to specify how an other app could find the right data.
This is very related to [Post deleted] - #7 by mrkvon; that is, in the long term, if we adopt a hybrid-kg model then we decouple data and location. But that doesn’t provide you with a solution that works right now.
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.
Solid Protocol is based off the template that https://dokie.li/ generates which is also aligned with the template that respec and bikeshed generates.
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.
