Open erik-descilabs opened 5 months ago
@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?
@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?
@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?
@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: