Difference between revisions of "Other Meetings and Notes"

From Metadata-Registry
Jump to: navigation, search
Line 33: Line 33:
 
#Vocabulary management (A)
 
#Vocabulary management (A)
 
#Register agents (users, organizations, maintainers, etc.) and manage (A)
 
#Register agents (users, organizations, maintainers, etc.) and manage (A)
#Search, browse, display terms, relationships, etc.
+
#Search, browse, display terms, relationships, etc. (A)
 
#Language and script support  
 
#Language and script support  
 
##Designate languages for registered terms (A)
 
##Designate languages for registered terms (A)

Revision as of 10:47, 14 October 2005

F2F Meeting, Oct. 14, 2005, Ithaca, NY

Agenda

  • 9:00-10:00 Goals for the project: defining "success"
    • Is it usage? If so, how many (users, vocabularies, terms?)

Goal: 10 Organizations/50 vocabularies

    • Is it functionality? (can do all five below? and are all functions equally important?)
      • Creating/registering/maintaining a scheme (controlled vocabulary) and its member terms
      • Creating/registering/maintaining a schema (element/property set) and its member terms
      • Creating/registering/maintaining an application profile
      • Creating/registering/maintaining of a scheme-to-scheme mapping (value spaces)
      • Creating/registering/maintaining of a schema-to-schema mapping (element/properties)

First three are contractually mandated, last two "good if we can." Application profiles least baked.

    • Promises about Semantic Web applicability (RDF, etc.) needs to be addressed. Specifically management in RDF "space" counts towards success to NSF in its research mode. Decisions about how far to go will be made in the context of what is needed for the functionality.

What's the registry for? Still for discovery and reuse, avoiding reinvention of wheels. Also promote use by machines, rather than reliance on humans (also support and management). At the basic level, provide discovery and identification of vocabularies at the description level, which do not have term-level information available.

  • 10:00-11:00
    • Define coarse feature set for schemes and schemas, with basic tasks to accomplish for each

DECISION: We will be SKOS-centric, with emerging OWL capability.

INPUTS:

  1. Externally managed vocabularies (SKOS, OWL) (A)

GENERAL FUNCTIONS:

  1. Data management (A)
  2. Vocabulary management (A)
  3. Register agents (users, organizations, maintainers, etc.) and manage (A)
  4. Search, browse, display terms, relationships, etc. (A)
  5. Language and script support
    1. Designate languages for registered terms (A)
    2. Support translations and other language/script capabilities (B)

NON-HOSTED FUNCTIONS:

  1. Register external vocabularies with external URIs assigned by owner (A)
  2. Register external vocabularies with URIs established by the registry (A)
  3. Develop external machine interfaces to the registry (SOAP, REST) (B)

HOSTED FUNCTIONS:

  1. Register external vocabularies with no terms (A)
  2. Annotation support (D)


OUTPUTS (all outputs will be files):

  1. Lossless output of externally managed vocabularies that have been slurped in their native format (SKOS, OWL) (A)
  2. Output of vocabularies in either SKOS or OWL, no matter their original format (using OAI's use of Simple DC as a minimum as our model). (A)
  3. Output of SKOS with OWL extensions when available. (C)

NOTE: Need new definition of "hosted" and use case where maintainer is managing the vocabulary with our tools, but the registry does not hold the "canonical" version ("not hosted" in our lingo). Also has implications for verification--do we periodically check vocabularies with non-Registry URIs for changes, missing terms, etc.

NOTE: Need to think about the problem of translations, how we will manage, how URIs will work in that context, etc. Action item: Jon will draft some use cases around language support (and additional information) for discussion. Stuart will begin a discussion on the DC-Registries WG page about options and implications. [Creates questions about need for additions to Maintainer role or need for another role.]

NOTE: Need to include in our documentation a statement about UTF-8 and web services support (SOAP, REST).

  • 11:00-noon
    • Attach priorities to each feature in terms of stakeholder and client satisfaction:
      • A (must have)
      • B (nice to have)
      • C (add it if we can)
      • D (future grants)
    • Determine complexity and assess risk for each feature
  • 12:30-1:30
    • Road map, includes timelines and milestones [a.k.a. "release dates"--may be internal]
      • Try to assign 'must have' features to milestones
  • 1:30-2:00
    • Review progress
    • Review task lists
  • 2:00-3:30
    • Add external review and testing tasks/timelines?
  • 4:00-5:00
    • Communication, documentation, meetings
      • Can we agree on "communication protocols" amongst the group?
      • How often do we need F2F meetings, telecons?
      • What are our expectations re: internal and external documentations?