-
Notifications
You must be signed in to change notification settings - Fork 1
ImportExport
Polygenea is designed to allow tools to communicate even if they have radically different internal models of what they are and what they want to do.
Any subset of the nodes a tool has may be packed for export to another tool, subject to the following guidelines.
-
If a node being sent contains a reference to a node not being sent, the reference MUST be a content-based reference (inline or hash-based ID). This ensures that if the recipient has the node in its own database the reference can be preserved.
-
If a node is sent without a source reference, arbitrary changed MAY be made to the node during export. If changes are made, content-based references to the changed node contained in other sent nodes SHOULD be updated to match the adjusted content.
If a node is sent with a source reference, its content MUST NOT be changed during export.
-
If more than one node is sent and one node sent contains a reference to another node sent, the referred-to node SHOULD be sent earlier in the export stream than the node that refers to it.
Any subset of the nodes a tool receives from another may be accepted, subject to the following guidelines.
-
If a received node contains a content-based reference to another node and if the recipient has a node with matching content, the recipient SHOULD link the new node to the one it already has.
-
If a received node contains an inline-content reference to another node and if the recipient does not have a node with matching content, the recipient MUST do one of the following:
- Leave the inline-content reference unchanged, or
- Replace the inline-content reference with a hash-based ID, or
- Add the inline-content node to its database and link the imported node to the node created from the reference.
-
If a received node contains a hash-based reference to another node and if the recipient does not have a node with matching content, the recipient SHOULD leave the hash-based link unchanged.
-
If a node is received that has no source reference, or if the recipient choses to remove the source reference from a received node, then the recipient MAY change any part of the node's content. If changes are made, content-based references to the changed node contained in other sent nodes SHOULD be updated to match the adjusted content.
If a node is received with a source reference, its content MUST NOT be changed during import.
-
If a node is received but the receiving tool decides not to include it, any local references to that rejected node in other received nodes MUST be replaced with content-based references (inline or hash-based ID) UNLESS the other nodes are also rejected.
Multiple nodes may be identical except for in their source. This is not an error: it represent that the same idea is attested by multiple sources.
If a tool cannot handle sources, it is free to remove the sources and merge the nodes however it wishes.
If a tool does handle sources but cannot handle several nodes differing only in their source, it SHOULD create a new "merged" node having a source of a new Inference node (with no rule reference) where all of the "merged" nodes are antecedents of the Inference.
If the tool has a single claim with several sources, it SHOULD export an Inference node between the claim node(s) and the set of source nodes.
If a tool that supports sources receives sourceless nodes it wishes to import and wishes to add sources to the nodes upon receipt, it SHOULD create an OutRef node describing the import event OR the sender of the data, then reference that node as the source of the imported nodes.
A tool that cares about sources SHOULD NOT try to automatically merge sourceless nodes in receives with sourced nodes it contains. Such a process can cause data corruption because the tool might not have enough information to correctly identify which sourced nodes the sourceless information was meant to discuss.
(to be added)