F2F Meeting, 10/14/05, Ithaca

From Metadata-Registry
Jump to: navigation, search

Agenda and Notes, 10/14/05

  • 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.


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


  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)
  6. Registry to Registry and Registry to Organization service interactions (A)
    1. Test registry to registry interactions using two instances or our own registry (A)


  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)


  1. Register external vocabularies with no terms (A)
  2. Edit registered vocabularies (A)
  3. Non-RDF vocabulary import for editing/managing (XSLT?) (C)
  4. 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).

NOTE: Ask Alistair if there are any validators for SKOS and OWL.

  • 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]


Year 1: Nov. 30:

  1. Determine data store and RDF Libraries (Ryan & Jon)
  2. Set up 'sandbox' for initial ingest testing (with Oknam's vocabularies) (Ryan & Jon)
  3. Test queries on ingested data (Ryan & Jon)
  4. Determine needs for management information about Agents and Vocabulary Descriptions (Diane & Stuart)
  5. Draft versioning policy (Diane & Stuart)

Dec. 31

  1. Implement Agent registration
  2. Implement Vocabulary description registration
  3. Set up workflow to associate vocabulary descriptions and schemes

Jan. 31 [Begin to involve Betatest Partners]

  1. Build interface prototypes (search, browse, display) and develop initial feedback loop on prototypes (Jon & Ryan)
  2. Determine needs for SKOS information (Diane & Stuart)
  3. Define validation steps (Ryan & Stuart)

Feb. 28

  1. Build interface prototypes (create, update) and develop initial feedback loop on prototypes (Jon & Ryan)
  2. Define notification workflow, text, rules (Diane & Jon & Ryan), including pending action notification (Ryan)

Mar. 30

  1. Implement creation/updating of terms (Jon & Ryan)

Apr. 30

  1. Implement and test notification (Diane & Jon)
  2. Define complete Registry Administrator functionality (Diane & Jon)

July 30

  1. Define schema registration workflow/data requirements (Stuart & Diane)
  2. Build Registry administrator interface prototypes (Jon)

Aug. 30

  1. Build interface prototype (create, update) for schemas and develop initial feedback loop (Jon)

Year 2: Oct. 2006 (+12):

  1. Build interface prototype (create, update) for application profiles and develop initial feedback loop (Jon)
  2. Develop flash movie/screencast for building APs

Nov. 2006

  1. Develop requirements for community gathering around vocabularies

Annual Meeting, Nov. 2006 (+13 mos.): Demonstrable system:

  1. End user search and display
  2. Creation of hosted vocabularies within system
  3. Registration of simple schema
  4. Flash movie/screencast for building AP
      • Try to assign 'must have' features to milestones

  • 4:00-5:00
    • Communication, documentation, meetings
      • Can we agree on "communication protocols" amongst the group?

Smaller groups will report out via the list, not necessarily carrying on all conversation via the list. Progress reports each week before the meeting (morning of or night before). Also notify if something substantial added to wiki or other documentation.

      • How often do we need F2F meetings, telecons?

Continue weekly telecons, focus on discussion rather than reporting. One more F2F meeting (somewhere) in April.

      • What are our expectations re: internal and external documentation?

External documentation:

  1. Tool related
  2. Visiter focused

Should write a documentation plan and job description for second year librarian in April. Much of this should be part of the CMS planning.