SKOS Concept History Management

From Metadata-Registry
Jump to: navigation, search

SKOS Concept History Management

This outlines proposed requirements for maintaining change history for Concepts.

PLEASE NOTE: These use cases are intended specifically to support the development of software. Many of the terms in this document such as "class" and "instance" have direct corollaries in RDF, but their usage in this document is meant to support object-oriented software development concepts.

ConceptClass

  • This is created whenever a new ConceptInstanceHistory is created
  • Has only the properties - date created, creator
  • It is not related to a scheme
  • The URI is created in the 'concept' namespace:
    http://metadataregistry.org/uri/concept/1234567

ConceptInstanceHistory

This is what we currently think of as a Concept and has all the normal SKOS properties

  • A new ConceptInstanceHistory is created every time any of the properties of the most recent ConceptInstanceHistory is changed, or a property is added or deleted. It retains all of the properties of that ConceptInstanceHistory.
  • Only the most recent ConceptInstanceHistory related a ConceptClass will be available for editing.
  • The URI is what we currently associate with the URI for a 'Concept' plus a UNIX timestamp
    http://metadataregistry.org/uri/NSDLEdLevel/1001/34456789
    NOTE: End Users will rarely see or use this URI, but it can be used for change management and tracking.
  • Has an 'isHistoryFor' relationship to a ConceptInstance
  • Has an inferential relationship to the ConceptClass
  • Will have properties for timestamp of the change and who was the maintainer that made the change.

ConceptInstance

  • Like a ConceptClass, it has almost no properties of its own, but is a representation of the most current ConceptInstanceHistory for a ConceptClass
  • Has an 'isInstanceOf relationship to a ConceptClass
  • The URI is what we currently associate with the URI for a 'Concept'
    http://metadataregistry.org/uri/NSDLEdLevel/1001
    NOTE: This URI will resolve to the most current ConceptInstanceHistory only if the status of the ConceptInstanceHistory is 'published'
  • Date/time-based vocabulary snapshots will resolve to the most recent published ConceptInstanceHistory as of the date/time requested
  • A date/time-based snapshot may also request the inclusion of statuses other than 'published'

Concept History Illustrated

(I apologize in advance for the informal notation in the illustrations)

Use Cases

User requests the current concepts for a vocabulary

  • Registry will resolve the request to:
    • Retrieve Each ConceptInstance (URI)
      • Where ConceptInstance isInstanceOf ConceptInstanceHistory
        And ConceptInstanceHistory::hasStatus = 'published'
        And ConceptInstanceHistory::inScheme = requestedVocabulary
        And ConceptInstanceHistory has most recent date

User wants to add an existing concept to a vocabulary for which she is a maintainer from another vocabulary for which she is a maintainer

  • User selects a currentVocabulary
  • User indicates that she wants to add a concept from another vocabulary
  • User selects an existing vocabulary for which she is a maintainer (selectedVocabulary)
  • User searches (or uses select box) to retrieve a list of potential concepts
  • User should optionally be able to specify only 'published' concepts and select a language
  • In order to build the list of concepts retrieved, the Registry will resolve the request to:
    • Retrieve Each ConceptInstanceHistory
      • Where ConceptInstanceHistory::inScheme = selectedVocabulary
        And ConceptInstanceHistory has most recent date
  • User selects a concept from the list (selectedVocabulary::selectedConceptInstanceHistory)
  • User saves new currentVocabulary::selectedConceptInstanceHistory
  • Registry creates a new ConceptInstanceHistory that copies all properties from the original ConceptInstanceHistory and adds ConceptInstanceHistory::inScheme = currentVocabulary.
    NOTE: The currentVocabulary::ConceptInstanceHistory will have an isHistoryFor relationship to currentVocabulary::ConceptInstance which will be an instance of the original selectedVocabulary::ConceptClass.
    A new currentVocabulary::ConceptClass will not be created.
  • Registry creates a new selectedVocabulary::ConceptInstanceHistory and adds ConceptInstanceHistory::inScheme = currentVocabulary.
  • The status will default to the same status as the latest selectedVocabulary::ConceptInstanceHistory, since the User is a maintainer for both vocabularies (???)

NOTE: This use case assumes that the user is initially only using or cloning an existing ConceptInstanceHistory. Once this is done and the user begins to change the properties of the cloned ConceptInstanceHistory (another use case), it continues to be an instance of the selectedVocabulary::conceptClass until the changes result in a semantic change. At that point, since a ConceptClass is intended to represent a single semantic concept, the Registry will create a new ConceptClass.

User wants to add an existing concept to a vocabulary, for which she is a maintainer, from another vocabulary, for which she is NOT a maintainer

This follows the previous use case, except that when the selectedVocabulary::ConceptInstanceHistory::inScheme = currentVocabulary relationship is created, the status of the new property will be 'proposed -- new'

User wants to see all vocabularies that contain a concept or all properties of a ConceptClass

  • User selects a ConceptInstance, either through selection or search, and requests all instances/properties of the selectedConceptClass for which the selectedConceptInstance is an InstanceOf.
  • Registry will resolve the request to:
    • Get the selectedConceptClass for which the selectedConceptInstance is an InstanceOf
    • Retrieve Each ConceptInstanceHistory::property
      Where ConceptInstanceHistory isHistoryFor ConceptInstance
      And ConceptInstance isInstanceOf selectedConceptClass
      And ConceptInstanceHistory::hasStatus = 'published' (???)
      And ConceptInstanceHistory has most recent date

User wants to add a relationship from a concept for which she is a maintainer to a concept in another vocabulary

  • User selects/creates a currentConceptInstanceHistory
  • User indicates that she wants to add a relationship to a concept from another vocabulary
  • User selects an existing vocabulary
  • User searches (or uses select box) to retrieve a list of potential concepts
  • User should optionally be able to specify only 'published' concepts and language
  • In order to build the list of concepts retrieved, the Registry will resolve the request to:
    • Retrieve Each ConceptInstanceHistory
      Where ConceptInstanceHistory::inScheme = selectedVocabulary
      And ConceptInstanceHistory has most recent date
  • User selects a selectedConceptInstanceHistory from the list
  • User saves new relationship property
  • Registry creates a new ConceptInstanceHistory that copies all properties from the currentConceptInstanceHistory and adds a relationship to the ConceptInstance::URI for which the selectedConceptInstanceHistory is an Instance.
  • Registry creates a new selectedVocabulary::selectedConceptInstanceHistory and adds ConceptInstanceHistory a reciprocal relationship to the ConceptInstance::URI for which the currentConceptInstanceHistory is an instance.
  • NOTE: If the User is a maintainer for both vocabularies, the status will default to the same status as the latest selectedVocabulary::ConceptInstanceHistory, (???) If not, the status of the newly created relationship in the selectedVocabulary::selectedConceptInstanceHistory will be 'proposed - new' because the maintainer of the selectedVocabulary must 'endorse' the new semantic relationship.
  • If the User is NOT a maintainer for the selectedVocabulary, the maintainer of the selectedVocabulary will be notified that a new semantic relationship has been proposed.

In this case, there is no explicit need to enforce reciprocal relationships between the concepts -- we only insist on the internal consistency of those relationships with regard to the concepts that are in a single scheme.

This also raises the possibility that a busy maintainer of a large and popular vocabulary may not want to be notified of each new proposed relationship. We should probably give vocabulary maintainers the ability to automatically accept or reject proposed relationships from maintainers of other vocabularies. Maybe even on a maintainer or vocabulary basis, e.g. accept all relationships from JoseAtLOC, accept all relationships from vocabulary LCSH, reject all others.