First Round of Edits

[erik-descilabs]

Capability | DeSci Concept | Similar DSI Concept -- | -- | -- Alias registry | dPID Contract | N/A Entry Point | Ceramic Stream root hash | base DSI Tree structure | IPFS directory | Git tree Individual Identifier | IPFS CID | SWHID & Git hash Individual Version | dPID (version of) | Baseprint document snapshot Versioning Mechanism | Ceramic stream | Git history in DSGL First Interface | DeSci Nodes | Baseprint document succession Verifiability | DID | SSH signing key

@castedo Any thoughts on adding the functionality in a first column to clarify the intention behind the comparisons? If you're ok with that, a few additional points:

• While IPLD does serve as a tree structure, dPIDs are shifting to something more similar to a knowledge graph via ceramic. I don’t know if the tree structure comparison fully tracks
• The dPID contract is the alias registry. I clarified that in the table above.
• I want to clarify that Nodes is just an interface on top of the PID system and underlying IPFS repository. Not sure if the interface line compared to BDS still works, but DeSci Nodes is not responsible for tracking versioning. It just surfaces.
  • As a sidenote, the idea of more granular versioning is really interesting. I think we shied away from it to avoid the regulatory headache but I am still a fan of the concept.
• Is it worth adding concepts in addition to the identifier itself? For example, ceramic is an indexer network.
• In "Ceramic streams vs Git Histories", would it be possible to add a line about "anyone can host an IPFS node", indicating that storage doesn't rely entirely on the public network but is rather supplemented by it

[castedo]

@erik-descilabs Quick question regarding the change from "Research object (version of)" to "dPID (version of)". What would be the closest DeSci term corresponding roughly to "Baseprint document snapshot"? This is the thing pointed to by a versioned dPID. For example, 'https://nodes.desci.com/dpid/180/v2' identifies something static (I assume) that is also identified by CID 'bafkreigksvcw5f67h2kzbxnndwf47ch74nb4vbniepacjt6y5nm74ote4m'. What is the best term for this thing that is static?

[castedo]

@erik-descilabs Regarding the term "node" I'm guessing it is getting used in two ways. One way is to mean this interface on top of the PID system. This sounds like a technical detail. The other way is how the word "Node" is getting used in the UI of https://nodes.desci.com/. For example, the "+" button on the left bar tool tips "New Node". Similarly the landing page reads

The Nodes below meet the curation criteria of ... Select a specific community to view the Nodes they have curated.

This second way of using the word "node" is way more relevant to users.

Perhaps answering this question will help clarify, if I create a node in DeSci Nodes and publish a v1 and then I want to make an update to a v2. Am I creating a new node or not?

[castedo]

@erik-descilabs I've carved off the last two bullet points into #2 and #3 to be tracked separately.

Overall, I think you're idea of adding a column will be helpful for readers. But another column of yet more formal pithy terms I think is less useful than flexible descriptive text, so I've added a "Notes" column as a 3rd column. A challenge with this document is the explosion of pithy specialized terms. We should be adding more explanatory text.

I also split the terminology comparison table into two. I bet it makes the material more digestible for a reader.

I've tweaked the language around "node" but I suspect you have better suggestions on what the analogous terms are for Baseprint snapshot/succession.

Regarding knowledge graph, I am betting it's still a hash/Merkle tree. Let me know if I'm wrong.

For Nodes in the sense of an interface, maybe there should be a 3rd table or section listing concepts that do not have an equivalent in DSI/DSGL? Then this Nodes interface concept and the pPID contract concept can go in there?