...
For a deleted entity, the URI will no longer resolve.
Minimum: URI of the deleted thing.
If cache is a blob graph, then URI is sufficient.
Challenges:
- Are there other outside references to the triple? Can produce orphaned sub-chains. If access is always through the subject URI, there may be tolerance for kruft where the outside reference doesn't exist when you try to access it.
- How far out into the graph would you delete? - following blank nodes; following through other URIs.
Better not to delete. Better to deprecate (see below) and add see instead.
Approach:
Example Data Stream:
...
It is common practice for the deprecated entity to include information on what should be used instead.
Are there challenges when there are lots of deprecated entities?
- triples do grow as deprecations grow
- deprecations can be indexed separately or together, but this is driven by decisions made at the authority provider
Deprecations are fulfilling a need to...
- maintain URIs over time
- desire not to throw away any information
- gives history of the authority
- aids disambiguation
Are there times when a deprecated term should become deleted?
- would this be a choice of the consumer?
Implementation
- entity deleted, but URI is marked deprecated and remains in a registry of URIs
Can you deprecate a part of the graph for an entity?
- Example - a specific attribute: a label is no longer valid or an occupation is no longer valid
- Example - a link to another entity: a link to a role or agent
RDF is atemporal meaning that when you publish a graph, it exists and will always exist. A graph is true and is later succeeded by another graph. How to identify what is different? Can deprecation be used to identify what has changed? If you have two graphs, version 1 and version 2, the difference is the change. Challenge with knowing the edges of the graph are different in 1 vs. 2.
LOC views graph as corresponding to a MARC record? Each update of the system replaces the graph. This is possible because the graph is a blob for the subject URI.
Example: Series - name-title authority record vs. multiple - author name changed and in perhaps 10 records, the records are updated upstream
Complication comes in when starting with a single URI and connects to another URI that has its own definition outside the current URI's graph. If blank node, then this is not an issue.
Challenge with blobs is that if the blob references a URI that has a life outside the blob, then any data for the outside URI will be out of date within the blob. Potential solution is for the blob to only have URIs and pulls in other data for the outside URI live.
Similar to normal forms in database theory. Don't repeat data to avoid data redundancy.
Copy cataloging in BibFrame – work, instance, agent, item, etc. – Ideally, copy cataloging would be list of URIs. Significant practical difficulties.
Can we provide a sparql query that would indicate what needs to be updated in the graph?
Another option is to have delete, add, insert type diff commands that can be processed in order to make the graph changes.
Examples:
Approach:
Example Data Stream:
...