...
The wider the graph, the more chance there is that data expressed in the NEW data would overlap with existing data in the cache.
Option 2:
- Feasible, but should be optional because the graph for certain authorities may be computationally expensive
- Expense may be in terms of how many new documents will be included
- What is a full entity? How much of the graph needs to be included? What serialization should be included? What ontology should be included if the authority supports multiple ontologies?
How to determine relevancy of the new entity? For full cache, all new are relevant. If not, then the downstream consumer will need to decide which new entities are relevant. This can be supported by the notification process where an institution requests to be notified when the entity is added. Intermediate 3rd party provides a notification.
Examples:
Approach:
Two possible approaches:
...
It is common for there to be multiple variant labels. In some cases, variants may represent different languages.
- If DELETE_LABEL is supported, is it ok for a variant label to be deleted and not have a corresponding add? This seems ok.
Is there an ontology that describes types of changes? Activity streams accommodates this functionality.
- Is the process of defining this a process to create an ontology or similar to ontology creation?
- Can activity stream documents describe the types of change?
- Does this increase the level of agreement required?
Examples:
- LOC is looking at using a feed that provides information on authoritative labels. This is mostly used for name changes (e.g. person died and the death date is added to the label).
...
- The label in the graph may not be directly connected to the URI (e.g. <URI><PREDICATE><NEW_LABEL>). It may go through one or more other URIs or black nodes with a number of different predicates.
- What constitutes a label may vary between ontologies. Common label scenarios:
- a single primary label
- multiple primary labels
- primary and variant labels
- primary label is not human readable
- no primary label
- Roles of consumers
- Full cache processed fully by machine
- Partial cache processed fully by machine or may need some human intervention
- Human processing with a need to quickly see changes that are important from their perspective
- Ordering
- Graphs are inherently not ordered; what implications are this?
- Is there a way to express a diff with unordered data?
- Desire is for an easy visual way to see, process, and focus in on a specific change
- Perhaps use a notification where user subscribes to particular types of changes or certain data changes
- There is a RDF graph source diff (https://www.w3.org/2001/sw/wiki/How_to_diff_RDF)
- Label changes in one language but not another
Approach:
Minimally need to include:
- URI
- NEW_LABEL - the new label to use
- PREDICATE (or some other identifier) - identifies which type of label is being replaced - perhaps should be LDPATH instead to address a label that is farther down the graph from the subjectURI.
NOTE: This can be represented as a triple. <URI> <PREDICATE> "new label"@en
...