Nanopublications LDF server

Matches in Nanopublications for { <https://iphylo.blogspot.com/2024/06/nanopubs-way-to-create-even-more-silos.html#comment-6484057602> ?p ?o ?g. }

• comment-6484057602 comment "Except possibly some details on the order in which certain steps should be taken. We have focussed on the technology (but always with the users in the longer term in our mind), because the technology needs to be at a certain level of maturity to start doing actual things with it. How to represent scientific content as a knowledge graph has been studied academically, and to make the next step to move this to practice we need a suitable technology first. And now that the technology is "ready enough", we can start doing this, but we won't get it right on the first try. So, in my view, what you point out are valid points, but they are not fundamental shortcomings but rather practical mistakes and rough edges that are part of the process. Right, the last two query links were broken. Somehow they got truncated. I fixed the links in my post above, and now they should work. Indeed persistence isn't free. But for nanopublications, as long as we stay in the range of thousands to millions, the costs are actually small. In particular if we separate the storage/archiving from the querying layer, as we do, where only the first is crucial for persistence. Then the persistence is more of an organizational/coordination problem than a cost problem, and with a decentralized redunant network as we have it, this task can be distributed and managed at low cost (on university servers, for example). Maybe URIs don't always resolve, but there is always a well-defined procedure to find the nanopubs at other locations. Things change if we talk about hundreds of millions to billions of nanopublications and more. Given the versatility of nanopublications, it's possible we will get there. For this we need a model where the mass creators of nanopublications also carry the associated costs. We are working on next-generation nanopublication services that will allow for exactly that. Nodes in the nanopublication network can then assert restrictions and quotas on users and types of nanopublications they replicate/accept, and so for publishing large quantities one would have to convince (with money, probably) a few of the nodes to co-host the nanopublications. Just as a quick summary of these plans; happy to explain more. And it's great that your post has triggered these discussions. Thanks for that :)" assertion.
• comment-6484057602 comment "Thanks for your reply. Yes, we seem to be in agreement then :) Except possibly some details on the order in which certain steps should be taken. We have focussed on the technology (but always with the users in the longer term in our mind), because the technology needs to be at a certain level of maturity to start doing actual things with it. How to represent scientific content as a knowledge graph has been studied academically, and to make the next step to move this to practice we need a suitable technology first. And now that the technology is "ready enough", we can start doing this, but we won't get it right on the first try. So, in my view, what you point out are valid points, but they are not fundamental shortcomings but rather practical mistakes and rough edges that are part of the process. Right, the last two query links were broken. Somehow they got truncated. I fixed the links in my post above, and now they should work. Indeed persistence isn't free. But for nanopublications, as long as we stay in the range of thousands to millions, the costs are actually small. In particular if we separate the storage/archiving from the querying layer, as we do, where only the first is crucial for persistence. Then the persistence is more of an organizational/coordination problem than a cost problem, and with a decentralized redunant network as we have it, this task can be distributed and managed at low cost (on university servers, for example). Maybe URIs don't always resolve, but there is always a well-defined procedure to find the nanopubs at other locations. Things change if we talk about hundreds of millions to billions of nanopublications and more. Given the versatility of nanopublications, it's possible we will get there. For this we need a model where the mass creators of nanopublications also carry the associated costs. We are working on next-generation nanopublication services that will allow for exactly that. Nodes in the nanopublication network can then assert restrictions and quotas on users and types of nanopublications they replicate/accept, and so for publishing large quantities one would have to convince (with money, probably) a few of the nodes to co-host the nanopublications. Just as a quick summary of these plans; happy to explain more. And it's great that your post has triggered these discussions. Thanks for that :)" assertion.
• comment-6484057602 comment "Thanks for your reply. Yes, we seem to be in agreement then :) Except possibly some details on the order in which certain steps should be taken. We have focussed on the technology (but always with the users in the longer term in our mind), because the technology needs to be at a certain level of maturity to start doing actual things with it. How to represent scientific content as a knowledge graph has been studied academically, and to make the next step to move this to practice we need a suitable technology first. And now that the technology is "ready enough", we can start doing this, but we won't get it right on the first try. So, in my view, what you point out are valid points, but they are not fundamental shortcomings but rather practical mistakes and rough edges that are part of the process. Right, the last two query links were broken. Somehow they got truncated. I fixed the links in my post above, and now they should work. Indeed persistence isn't free. But for nanopublications, as long as we stay in the range of thousands to millions, the costs are actually small. In particular if we separate the storage/archiving from the querying layer, as we do, where only the first is crucial for persistence. Then the persistence is more of an organizational/coordination problem than a cost problem, and with a decentralized redundant network as we have it, this task can be distributed and managed at low cost (on university servers, for example). Maybe URIs don't always resolve, but there is always a well-defined procedure to find the nanopubs at other locations. Things change if we talk about hundreds of millions to billions of nanopublications and more. Given the versatility of nanopublications, it's possible we will get there. For this we need a model where the mass creators of nanopublications also carry the associated costs. We are working on next-generation nanopublication services that will allow for exactly that. Nodes in the nanopublication network can then assert restrictions and quotas on users and types of nanopublications they replicate/accept, and so for publishing large quantities one would have to convince (with money, probably) a few of the nodes to co-host the nanopublications. Just as a quick summary of these plans; happy to explain more. And it's great that your post has triggered these discussions. Thanks for that :)" assertion.