This is an archive of an inactive wiki and cannot be modified.


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:

  1. 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.

  2. 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.

  3. 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:

  1. 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.

  2. 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).

  3. A SKOS:broader statement is added to Joe:eagle, also with a status of proposed.

  4. 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.

  5. 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.

  6. 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:

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?