Difference between revisions of "F2F Meeting, 4/28/06, Seattle"

From Metadata-Registry
Jump to: navigation, search
m
 
Line 39: Line 39:
 
* Representing both history and version in the user interface
 
* Representing both history and version in the user interface
  
Consensus: We will not use "version" to refer to "referencable snapshots" and will describe in detail how the snapshots can be used to support rational processes for vocabulary owners and users. Version is an editorial decision signaled by change in documentation that states a substantial change in structure and/or word use [... Joe will document this in more detail] [joe here - we need a taxonomy of types of vocabularies - and we might even need to consider other indexing languages {schemes for both vocabularies and other indexing languaages?} - all of this relies on work at the term level in the registry {against SKOS modeling which is on the concept level}, and which is against our print metaphor which is at the scheme level {vocabulary etc.}.  So we need a term record that can track the most current version of the term {including point to inScheme links etc.}.  If each term is current then the registry will have the most current ''Italic text''collection of terms''Italic text''. This will be the referenceable snapshot.  However, vocabulary editors may want to label a collection of terms a version, following the print metaphor.  An editor may want to signal a major revision of relationship structures and the like (say moving from DDC 19 to DDC 20), and this would need to be more than a referenceable snapshot.  It is proposed here that an editor signal this change by labeling the new version, and providing documentation linked to every term in that version.  This documentation would be a narrative on the purpose, scope, use of the vocabulary.  It would also conatin information on how it was different than previous versions.  We would need a term record that could link to all this.
+
Consensus: We will not use "version" to refer to "referencable snapshots" and will describe in detail how the snapshots can be used to support rational processes for vocabulary owners and users. Version is an editorial decision signaled by change in documentation that states a substantial change in structure and/or word use [... Joe will document this in more detail] [joe here - we need a taxonomy of types of vocabularies - and we might even need to consider other indexing languages {schemes for both vocabularies and other indexing languaages?} - all of this relies on work at the term level in the registry {against SKOS modeling which is on the concept level}, and which is against our print metaphor which is at the scheme level {vocabulary etc.}.  So we need a term record that can track the most current version of the term {including point to inScheme links etc.}.  If each term is current then the registry will have the most current ''collection of terms''. This will be the referenceable snapshot.  However, vocabulary editors may want to label a collection of terms a version, following the print metaphor.  An editor may want to signal a major revision of relationship structures and the like (say moving from DDC 19 to DDC 20), and this would need to be more than a referenceable snapshot.  It is proposed here that an editor signal this change by labeling the new version, and providing documentation linked to every term in that version.  This documentation would be a narrative on the purpose, scope, use of the vocabulary.  It would also conatin information on how it was different than previous versions.  We would need a term record that could link to all this.
  
  

Latest revision as of 08:17, 24 May 2006

Registry Project Meeting, Seattle, 4/28/06

1. Review of current work and progress

  • Infrastructure, interfaces, data, testing
  • Plans for demo to DC UB

2. General open questions and issues:

  • How do we deal with the Super Properties? For instance, do we allow people to add things labelled as "Notes" or do we require them to choose among the subproperties (definition, changeNote, etc.) This is also an issue with imported files.

Consensus: At present, we are inclined to not use general NOTE (Super Property), but instead rely on specific notes (Sub Propoerties like skos:HistoryNote, skos:ChangeNote, skos:Example, etc.) . We should be sure to document properly what we expect from vocabulary owners. We should consider the superproperties as gathering devices. Perhaps the documentation can be linked to the superproperty.

These last two points (gather devices and link to superproperty) will depend on an explicit purpose to make these useful. Why would we want to gather this subproperties and link them?


  • Is historyNote a good place to put term sources, such as we've defined in the NSDL Learning Resource Type vocabulary? We're thinking that the use of skos:inScheme should wait until we do term mapping.

Consensus: History Note is not the right place, we should consider doing a local note "developmentNote" (tied to status) or using "editorialNote" instead. [all of these notes should get a full description of purpose and use in the NSDL registry - anything we add should be defined in relation to other properties and comments should be made about this new property so it's clear. as it stands "developmentNote (tied to status) is not clear.]

Another option is to make "developmentNote" as a sub-property of editorialNote. [again this will depend on the purpose and definitions of the property - and the purpose of gathering and linking properties and subproperties in the skos of the registry]

Stuart wants us to suppress display or output of URIs pre-publication, Jon thinks it can be done in the context of the Cookbook.


  • In the NSDL vocabularies, we've listed the sources of definitions but there's no place to put those in skos. We're thinking it might be a something we should propose?

Consensus: Citations are a separate thing and need to be modelled for any number of properties.


  • Status: Jon and Diane have worked up a proposal on the use of a status property, and some suggested values. The proposal also includes some policy suggestions on how validation and review might work.


3. Versioning issues:

  • Melanie's paper on Versioning
  • Differences between "history" and "version" and how this translates into user services. How much will versioning be automated? How much will we rely on snapshots? Will there need to be a distinction between automated snapshots and "intentional" versions? If so, how will we reflect those differences?
  • Representing both history and version in the user interface

Consensus: We will not use "version" to refer to "referencable snapshots" and will describe in detail how the snapshots can be used to support rational processes for vocabulary owners and users. Version is an editorial decision signaled by change in documentation that states a substantial change in structure and/or word use [... Joe will document this in more detail] [joe here - we need a taxonomy of types of vocabularies - and we might even need to consider other indexing languages {schemes for both vocabularies and other indexing languaages?} - all of this relies on work at the term level in the registry {against SKOS modeling which is on the concept level}, and which is against our print metaphor which is at the scheme level {vocabulary etc.}. So we need a term record that can track the most current version of the term {including point to inScheme links etc.}. If each term is current then the registry will have the most current collection of terms. This will be the referenceable snapshot. However, vocabulary editors may want to label a collection of terms a version, following the print metaphor. An editor may want to signal a major revision of relationship structures and the like (say moving from DDC 19 to DDC 20), and this would need to be more than a referenceable snapshot. It is proposed here that an editor signal this change by labeling the new version, and providing documentation linked to every term in that version. This documentation would be a narrative on the purpose, scope, use of the vocabulary. It would also conatin information on how it was different than previous versions. We would need a term record that could link to all this.


4. Joe's role with the project (should he choose to have one!) Possible focus on identified gaps and issues with SKOS?

I'm open to working, let's move forward as needed with telecons and f2f stuff.


5. Technical Issues:

  • The URI issue: Should we use our own domain or purl.org? [Note: Decided to use metadataregistry.org]
  • The hash/slash issue (Jon)
  • Do we need to include all the SKOS properties in this release? Not sure we understand how all of them would be used! This relates to some extent to the superproperties but there are also some subproperties we have questions about. (Diane will distribute a spreadsheet which specifies some areas of concern.)

Consensus: We will constrain our support of SKOS properties to those we are currently considering, but allow those who use the full set to upload and expect output for the properties we cannot yet support. Once a vocabulary is uploaded it may be:

  • updated by upload only
  • updated within the registry only
  • updated in both places with a download step avoiding the overwriting of internally maintained changes.