# Client to client standard resources and guidelines? **URL:** \ **Category:** General Discussion\ **Created:** [February 6, 2023, 11:16am UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124 "2023-02-06T11:16:04Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![lecoqlibre](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/lecoqlibre/32/3479_2.png) [@lecoqlibre](https://forum.solidproject.org/u/lecoqlibre)\ **Post date:** [February 6, 2023, 11:16am UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/1 "2023-02-06T11:16:04Z")
Hi there, 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](https://github.com/datafoodconsortium/) (DFC) ontology (old visual [here](http://static.datafoodconsortium.org/conception/DFC%20-%20Semantic%20business%20and%20produt%20model%20-%20visual.pdf)). 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? Thanks! ---
**Author:** ![michielbdejong](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/michielbdejong/32/195_2.png) [@michielbdejong](https://forum.solidproject.org/u/michielbdejong)\ **Post date:** [February 7, 2023, 11:42am UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/2 "2023-02-07T11:42:13Z")
> Mycelium uses and co-develops the [Data Food Consortium](https://github.com/datafoodconsortium/) Cool stuff! FWIW, we’ve documented some conventions in [pdsinterop.org/conventions](https://pdsinterop.org/conventions/overview/) You can edit this [on GitHub](https://github.com/pdsinterop/conventions). It sounds like you want to document your conventions more rigorously - let’s discuss! Maybe we can set up a video call to chat about this? ---
**Author:** ![renyuneyun](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/renyuneyun/32/3189_2.png) [@renyuneyun](https://forum.solidproject.org/u/renyuneyun)\ **Post date:** [February 7, 2023, 1:38pm UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/3 "2023-02-07T13:38:20Z")
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? ---
**Author:** ![michielbdejong](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/michielbdejong/32/195_2.png) [@michielbdejong](https://forum.solidproject.org/u/michielbdejong)\ **Post date:** [February 7, 2023, 1:46pm UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/4 "2023-02-07T13:46:07Z")
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. ---
**Author:** ![lecoqlibre](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/lecoqlibre/32/3479_2.png) [@lecoqlibre](https://forum.solidproject.org/u/lecoqlibre)\ **Post date:** [February 7, 2023, 2:27pm UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/5 "2023-02-07T14:27:57Z")
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? ---
**Author:** ![jeswr](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/jeswr/32/3924_2.png) [@jeswr](https://forum.solidproject.org/u/jeswr)\ **Post date:** [February 7, 2023, 10:46pm UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/6 "2023-02-07T22:46:03Z")
> we need to specify how an other app could find the right data. This is very related to [[Post deleted] - #7 by mrkvon](https://forum.solidproject.org/t/is-a-solid-pod-a-set-of-documents-or-is-it-a-knowledge-graph/6028/7); 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](https://github.com/solid/type-indexes) 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. ---
**Author:** ![lecoqlibre](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/lecoqlibre/32/3479_2.png) [@lecoqlibre](https://forum.solidproject.org/u/lecoqlibre)\ **Post date:** [March 31, 2023, 4:03pm UTC](https://forum.solidproject.org/t/client-to-client-standard-resources-and-guidelines/6124/7 "2023-03-31T16:03:53Z")
For publishing a client-to-client standard, some tools can be used like: - [GitHub - speced/bikeshed: 🚲 A preprocessor for anyone writing specifications that converts source files into actual specs.](https://github.com/speced/bikeshed) - [GitHub - w3c/spec-prod: GitHub Action to build ReSpec/Bikeshed specs, validate output and publish to GitHub pages or W3C](https://github.com/w3c/spec-prod) - [Solid Protocol](https://solidproject.org/TR/protocol) is based off the template that [https://dokie.li/](https://dokie.li/) generates which is also aligned with the template that respec and bikeshed generates. > In [Solid QA](https://solidproject.org/ED/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](http://www.w3.org/ns/spec). Thanks to elf Pavlik and Sarven for the hints 😉