Attending:

Deanne DiPietro (SEC)
Roger Kunkel (CERES, by phone)
Jan Derksen (KRIS)
Kevin Petrik (DU)
Pat Siefer (SEC)
Michael May (SFEI)
Steve Kokotas (MIG)
BC Capps (BAOSD)
Vic Chow (BML)
Allan Hollander (ICE)
David Siedband (Watershed Portals)

Summary of meeting:
In the morning we reviewed The CalEDLN Architecture and its components, then went through the components that are being developed and are either working or works in progress. Roger Kunkel walked us through his CERES API+ , which will allow developers to make use of CERES Webservices such as Geofinder and the Thesaurus browser using pre-defined queries, and showed us several working "publish directories" that are in action now sharing data using the FGDC standard.

We then looked at the CalEDLN Draft Content Standard Specification and Deanne indicated the fields that consititute a special use of the FGDC and that still require review- themekt and themekw, participant, and the additional (proposed extension) field relation which corresponds to the field by the same name in the Dublin Core Metadata Standard.

Over lunch there was much valuable discussion about data sharing, the network, and how those of us present can now start to making publish directories available and contributing to the coding and development of use cases.

In the afternoon we talked about what to do next. Below are notes from that discussion. A "*" indicates a high-priority product.

Next Steps:
     - standard acceptance and trials
     - product identification and prioritization

* Standard specifications

Talked about how we need to define standards for each content type
    - projects, data, people, organizations

Decided to focus first on Projects so we make progress

How to deal with the fact that there are no name authorities yet:

Decided to use source IDs to allow lookup of people and organizations
    - treat these the same way as other vocabularies
    - reconcile later
    - use something that helps identify the person (like email address)
    - can help there be appropriate entries with the software
    - decide on some guidelines
          - no abbrevs
          - style guide

Each person can choose within reason what to include in their ID.
Poses no risk to do this, use accepted method of attributing tags so we don't break the XML parsers
Numbers can be different in the various systems but we reconcile them eventually

Later we develop web services with name authorities for people and organizations

Format should be valid URIs, can use "tag-URI" to come up with one

* Guidelines on "How-to-publish" (how to make you information available)
    - simple way (just put the XML records in one file on a website and register the URL)
    - RSS feed

* Use cases/real-world scenarios
Very important for guiding development
    - should be specific, granular
    - should convey functionality to the programming design team
    - what is the process and purpose for creating our use-cases?
          - folder for them on the Wiki
          - Sprint in April- collect use cases and lock in by 2 weeks before Sprint
          - organize the use cases with component
          - get help from the Content Committee    

* Sprint for multi-environment programming
    - Export utilities
            - modifications to existing XML export templates to create CalEDLN standard data
            - EndNote, ArcCatalog, plone archetype tools  
     - Import utilities

     - Programming environment break-outs for expert help
             - Plone/Python, Drupal, PHP, Perl/epl

how to fund a Sprint?
    - ask our clients and supporters to sponsor
     * Sprint contribution advertisement/menu
   

* Cataloging tools, a high prioritiy indeed

    - EndNote will fall short at some point but we'd like to see how far we can take it because it is quite useful
    - ArcCatalog (we'll be writing transfer scripts or transforms for outputs from these two and maybe other off-the-shelf software)

    - will need a custom, portable data entry interface so we can attach the CERES webservices and offer the thesauri needed and add them with correct URI syntax

Sharing code- this is an Open-Source project, we need all products to be open-source so we can all take advantage of each others' efforts and get somewhere fast
    - don't be shy! can be fragments, undocumented
    - purpose is not nec.'ly to run the code but sometimes just see how it was done, maybe use pieces of it in new code

    - SVN is our system for posting code- it will be offered on the portal with Trac

Other standards:
       - decide on SKOS, FOAF, LDAP
       - publish something using these standards as a starting point

Thesaurus-building tools and instructions for posting

    - multi-Thes (software that creates standard thesauri)
    - Townsquare attributing widget
      
The role of the Content and Steering Committees and the relatioship between them and the Developers' Committee

We need to get appropriate guidance from them and help them understand how we're approaching solutions that they need. Essentially, we work for them.
Content Committee- we will have a facilitated use-case design session
Steering Committe- ask them to help get sponsors, oversight for our general direction

Get the Opterus article (S. Kokotas)- describes a use case approach to help the user community communicate their needs

Concerns were expressed about metadata retraction and authoritative identification. Once the metadata gets propogated it will be difficult to retract quickly.
There should be a general model that people publish their own metadata, and there is not re-publication of others' metadata
Model of linking back to original metadata once you've found the
resource via the discovery-level record
We will propose a basic protocol for retraction or clearing


Our audience- two different groups of people?
two tiers of participation
    - people working with basic metadata record offerings
    - people wanting to set up more technical systems