Contents:
Contents
Metadata Registry Use cases
1. Registry UC1 -- User adds a new concept to a scheme that matches a concept in another scheme for which he is not the owner
Harry is creating a new concept scheme. As he enters new concepts, he uses the concept registry to find concepts in schemes for which he is not a maintainer with the same prefLabel as the concept he is adding. When he finds one, he may take one of several actions:
Import the concept instance into his scheme. Harry would only do this if he intended to make changes or additions to the existing concept statements in the context of his scheme. The concept instance receives a new URI in Harry's namespace, the skos:prefLabel and all skos:broader and skos:narrower statements are also imported, as are each of the related concepts, each receiving a new URI. The imported concepts maintain a skosmapping:exactMatch relationship to the original concept. With the exception of skos:prefLabel and concept relationships, Harry can choose which skos:[statements] to exclude from the import, but must can not exclude entire related concepts. Harry is immediately registered as a 'user' of the source concepts and scheme and will receive notifications of changes to that scheme and the concepts he has imported.
Add the concept instance to his scheme. Harry would do this if he intended to make absolutely no changes or additions of any kind to the existing statements (he wouldn't be able to.). Harry would also be required to add all related concepts to his scheme. Each concept receives a new, additional skos:inScheme statement identifying Harry's scheme. skos:inScheme is the only statement that is not owned by or endorsed by the owner of the concept, that can be added to a concept.
- Create a new concept and create a skosmapping:exactMatch or skosmapping:majorMatch relationship to the found concept. Note: skosmapping relationships are not reciprocal or bidirectional, are owned by the agent asserting the relationship independent of concept ownership, and do not need to be endorsed by the owner of either the subject or the object concepts.
2. Registry UC2 -- User adds a relationship to a concept in another scheme, for which he is not the owner
Harry wishes to extend a concept (eagle) in a concept scheme (Joe's) for which he is not an owner by declaring a skos:narrower relationship between a concept in his scheme harry:bald_eagle and joe:eagle. The following things happen:
Harry adds the relationship to his bald eagle concept by adding a new SKOS:narrower statement and looking up the URI of the Joe:eagle concept in the registry.
The relationship is added to harry:bald eagle and, since the relationship is to a foreign concept, it is forced to have a status of Proposed (NOT published).
A SKOS:broader statement is added to Joe:eagle, also with a status of proposed.
Joe receives a notice that Harry has proposed a new relationship from Harry:bald eagle to Joe:eagle, inviting him to endorse or reject the proposal.
- Joe may take either of the following actions:
5A1. Joe endorses the proposal. This causes the status of both new statements (SKOS:broader and SKOS:narrower) to be immediately changed to Published
5A2. Joe rejects the proposal. This causes the status of both new statements (SKOS:broader and SKOS:narrower) to be immediately changed to Rejected. As part of his rejection he may choose to immediately delete the offending statement from his concept.
Harry receives a notice of Joe's rejection and has the option of immediately deleting the rejected statement. He may keep it hanging around, but a Rejected statement cannot be changed to Published.
This use case raises a number of questions for the Registry:
- Can Harry change the status back to "Proposed"? and as often as he wishes? If so, Joe will get another notice each time.
- Can Joe stop this annoying behavior of Harry's by making the rejection final?
- What's to stop Harry from spamming Joe with repeated script-generated Proposals? -- can Joe preemptively reject all future proposals from Harry? from everyone globally? or on a scheme-by-scheme basis?
- If Joe can reject all future proposals, should the Registry even allow foreign relationships to be defined to his concepts?
- If not, how do we handle imported relationships?
Is the converse true -- can Joe preemptively accept Proposals?
- If so, from only Harry? globally? scheme-by-scheme?
- Is the ability to propose new statements on a foreign concept limited to relationships?
Should we skip this entire procedure and simply not allow skos relationships to be created between schemes that are not owned by the same agent, and use skosmapping relationships instead, since mappings don't require endorsement?