Difference between revisions of "SKOS Concept History Management"

From Metadata-Registry
Jump to: navigation, search
 
Line 1: Line 1:
 +
== SKOS Concept History Management ==
 
This outlines proposed requirements for maintaining change history for Concepts.
 
This outlines proposed requirements for maintaining change history for Concepts.
  
ConceptClass
+
=== ConceptClass ===
 
+
* This is created whenever a new ConceptInstanceHistory is created
Has only the properties - date created, creator  
+
* Has only the properties - date created, creator  
This is created whenever a new ConceptInstanceHistory is created
+
* It is not related to a scheme
It is not specifically related to a scheme, but since it's almost always created when a ConceptInstanceHistory is created it tends to be, although this is specifically not a requirement
+
* The URI is created in the 'concept' namespace:<br />http://metadataregistry.org/uri/concept/1234567
 
+
This reads a bit fishy, maybe it could be tightened up? Maybe more punctuation would help?
+
 
+
The URI is created in the 'concept' namespace:
+
http://metadataregistry.org/uri/concept/1234567
+
 
   
 
   
ConceptInstanceHistory
+
=== ConceptInstanceHistory ===
 
+
 
This is what we currently think of as a Concept and has all the normal SKOS properties  
 
This is what we currently think of as a Concept and has all the normal SKOS properties  
Has an 'isHistoryFor' relationship to a ConceptInstance and has an inferential relationship to the ConceptClass  
+
* Has an 'isHistoryFor' relationship to a ConceptInstance  
Will have properties for timestamp of the change and who was the maintainer that made the change
+
* Has an inferential relationship to the ConceptClass  
 
+
* Will have properties for timestamp of the change and who was the maintainer that made the change.
 
+
* 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.
We should add these properties to our internal set, no?
+
* 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<br />http://metadatarepository.org/uri/NSDLEdLevel/1001/34456789<br />NOTE: End Users will rarely see or use this URI, but it can be used for change management and tracking.
 
+
A new ConceptInstanceHistory is created every time any of the properties of the most recent ConceptInstanceHistory is changed or a property is added and retains all of the properties of the that ConceptInstanceHistory
+
 
+
 
+
Added or deleted?
+
 
+
 
+
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://metadatarepository.org/uri/NSDLEdLevel/1001/34456789  
+
End Users will rarely see or use this URI, but it can be used for change management and tracking.
+
 
   
 
   
 +
=== 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'<br />http://metadatarepository.org/uri/NSDLEdLevel/1001 <br />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'
 
   
 
   
ConceptInstance
+
== Use Cases ==
 +
=== User requests the current concepts for a vocabulary ===
 +
*Registry will resolve the request to:
 +
** Retrieve Each ConceptInstance (URI)
 +
*** Where ConceptInstance isInstanceOf ConceptInstanceHistory <br />And ConceptInstanceHistory::hasStatus = 'published'<br />And ConceptInstanceHistory::inScheme = requestedVocabulary<br />And ConceptInstanceHistory has most recent date<br />
 +
=== 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 ===
  
Like a ConceptClass, it has almost no properties of it's own, but is a representation of the most current ConceptinstanceHistory for a ConceptClass
+
* User selects a currentVocabulary
Has an 'isInstanceOf relationship to a ConceptClass
+
* User indicates that she wants to add a concept from another vocabulary
The URI is what we currently associate with the URI for a 'Concept'
+
* User selects an existing vocabulary for which she is a maintainer (selectedVocabulary)
http://metadatarepository.org/uri/NSDLEdLevel/1001
+
* User searches (or uses select box) to retrieve a list of potential concepts
This URI will resolve to the most current ConceptInstanceHistory only if the status of the ConceptInstanceHistory is 'published'  
+
* User should optionally be able to specify only 'published' concepts and select a language
Date/time-based vocabulary snapshots will resolve to the most recent published ConceptInstanceHistory as of the date/time requested
+
* In order to build the list of concepts retrieved, the Registry will resolve the request to:
A date/time-based snapshot may also request the inclusion of statuses other than 'published'
+
** Retrieve Each ConceptInstanceHistory
+
*** Where ConceptInstanceHistory::inScheme = selectedVocabulary<br />And ConceptInstanceHistory has most recent date  
Use Cases:
+
* User selects a concept from the list (selectedVocabulary::selectedConceptInstanceHistory)
User requests the current concepts for a vocabulary:
+
* User saves new currentVocabulary::selectedConceptInstanceHistory
Registry will resolve the request to:
+
* Registry creates a new ConceptInstanceHistory that copies all properties from the original ConceptInstanceHistory and adds ConceptInstanceHistory::inScheme = currentVocabulary.<br />NOTE: The currentVocabulary::ConceptInstanceHistory will have an isHistoryFor relationship to currentVocabulary::ConceptInstance which will be an instance of the original selectedVocabulary::ConceptClass.<br />A new currentVocabulary::ConceptClass will not be created.
    Retrieve Each ConceptInstance (URI)
+
* Registry creates a new selectedVocabulary::ConceptInstanceHistory and adds ConceptInstanceHistory::inScheme = currentVocabulary.
        Where ConceptInstance isInstanceOf ConceptHistoryInstance
+
* The status will default to the same status as the latest selectedVocabulary::ConceptInstanceHistory, since the User is a maintainer for both vocabularies (???)
        And ConceptHistoryInstance::hasStatus = 'published'
+
        And ConceptHistoryInstance::inScheme = requestedVocabulary
+
        And ConceptHistoryInstance 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/creates a currentVocabulary
+
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 indicates that she wants to add a concept from another vocabulary
+
User selects an existing vocabulary for which she is a maintainer
+
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 ConceptHistoryInstance
+
        Where ConceptHistoryInstance::inScheme = selectedVocabulary
+
        And ConceptHistoryInstance has most recent date
+
User selects a concept from the list
+
On saveŠ
+
 
+
Registry creates a new ConceptHistoryInstance that copies all properties from the original ConceptHistoryInstance and adds ConceptHistoryInstance::inScheme = currentVocabulary.
+
The currentVocabulary::ConceptHistoryInstance will have an isHistoryFor relationship to currentVocabulary::ConceptInstance which will be an instanceOf the original selectedVocabulary::conceptClass.
+
 
+
 
+
What if a property was deleted?  Maybe it should say " ... copies all remaining properties from the original ... "
+
 
+
 
+
A new currentVocabulary::conceptClass will not be created.
+
 
+
 
+
Hmm, seems the assumption here is that the change is not a semantic change. Maybe we need to specifically say that for this one and add one for a semantic change?
+
 
+
 
+
Registry creates a new selectedVocabulary::ConceptHistoryInstance and adds ConceptHistoryInstance::inScheme = currentVocabulary.
+
The status will default to the same status as the latest selectedVocabulary::ConceptHistoryInstance, since the User is a maintainer for both vocabularies (???)
+
 
   
 
   
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:
+
=== 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 the status of the selectedVocabulary::ConceptHistoryInstance::inScheme = currentVocabulary relationship is created the status of the new property will be 'proposed -- new'
+
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 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 Instance.
+
* 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:
+
* Registry will resolve the request to:
    Get the selectedConceptClass for which the selectedConceptInstance is an InstanceOf
+
** Get the selectedConceptClass for which the selectedConceptInstance is an InstanceOf
    Retrieve Each ConceptHistoryInstance::property
+
** Retrieve Each ConceptInstanceHistory::property<br />Where ConceptInstanceHistory isHistoryFor ConceptInstance<br />And ConceptInstance isInstanceOf selectedConceptClass<br />And ConceptInstanceHistory::hasStatus = 'published' (???)<br />And ConceptInstanceHistory has most recent date
        Where ConceptHistoryInstance isHistoryFor conceptInstance
+
        And conceptInstance isInstanceOf selectedConceptClass
+
        And ConceptHistoryInstance::hasStatus = 'published' (???)
+
        And ConceptHistoryInstance 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 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<br />Where ConceptInstanceHistory::inScheme = selectedVocabulary<br />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.
  
User selects/creates a currentConceptHistoryInstance
+
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.
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
+
In order to build the list of concepts retrieved, the Registry will resolve the request to:
+
    Retrieve Each ConceptHistoryInstance
+
        Where ConceptHistoryInstance::inScheme = selectedVocabulary
+
        And ConceptHistoryInstance has most recent date
+
User selects a selectedConceptHistoryInstance from the list
+
On saveŠ
+
  
Registry creates a new ConceptHistoryInstance that copies all properties from the currentConceptHistoryInstance and adds a relationship to the conceptInstance::URI for which the selectedConceptHistoryInstance is an Instance.
+
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.
Registry creates a new selectedVocabulary::selectedConceptHistoryInstance and adds ConceptHistoryInstance a reciprocal relationship to the conceptInstance::URI for which the currentConceptHistoryInstance is an instance.  
+
If the User is a maintainer for both vocabularies, the status will default to the same status as the latest selectedVocabulary::ConceptHistoryInstance, (???) If not, the status of the newly created relationship in the selectedVocabulary::selectedConceptHistoryInstance will be 'proposed - new'.
+
+
Yeah, I think the bits at the end will need some more discussion (the "endorsement" issue, for one thing) but I think you've got the gist of it down very nicely.
+

Revision as of 04:39, 18 October 2006

SKOS Concept History Management

This outlines proposed requirements for maintaining change history for 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

  • 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.
  • 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://metadatarepository.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.

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://metadatarepository.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'

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.