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

From Metadata-Registry
Jump to: navigation, search
Line 11: Line 11:
  
 
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.  
 
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.
 
* 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.

Revision as of 20:34, 8 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. Another option is to make "developmentNote" as a sub-property of editorialNote. 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]

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

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.