From NSDLWiki

Contents [hide] 1 Impact Analysis of v2.0 Proposal 1.1 Reference Materials 1.2 Goals 1.3 Analysis Questions: 1.4 Collections 1.4.1 Implementation 1.4.2 Viability of v2.0 Proposal 1.4.3 Impact on Existing NDR Objects 1.4.4 Impact on Existing Applications 1.5 Metadata Providers 1.5.1 Further Description and Examples Based on Developer Questions 1.5.2 Implementation 1.5.3 Viability of v2.0 Proposal 1.5.4 Impact on Existing NDR Objects 1.5.5 Impact on Existing Applications 1.6 Collection Metadata 1.6.1 Implementation 1.6.2 Viability of v2.0 Proposal 1.6.3 Impact on Existing NDR Objects 1.6.4 Impact on Existing Applications 1.7 General Issues with Collection Level API 1.7.1 ServiceDescription 1.7.2 State vs. OAI Visibility 1.8 Sign Off 1.8.1 Developer Concerns

Impact Analysis of v2.0 Proposal

Reference Materials

• NDR Terminology
• Features List (includes links to specifications)

Goals

Add Collection Level API calls with minimal changes to existing objects and minimal changes to functionality of existing applications while avoiding decisions that prevent implementation of long term goals for the full v2.0 API.

It is acceptable to plan 'work arounds' for existing functionality that does not completely fit with the vision for v2.0 API. These 'work arounds' may look quite different than the long term plan, but represent a stepping stone from the existing functionality to the full v2.0 API vision.

Analysis Questions:

Base your analysis on the proposed specifications. If functionality is not specifically addressed there or in this document, you should assume it is not available.

For your applications, include the following information in this document for any functionality that is not addressed by the proposed API.

1. Determine if applications can use the API to perform all functionality related to current GCCO creation, management, and use.
2. For any functionality that cannot be performed according to the current specification...

1. Describe the functionality.
2. Is the functionality required?
3. Is the functionality consistent with the long term goals? (ex. annotations will be used for this functionality)
4. Is there a temporary workaround until other portions of the API are available?
5. Does the API need to change to accommodate this functionality?

Collections

Collections are currently two level. Collection of Collections representing NSDL.org (aggregator object) with Library Collections (generic collection composite object - GCCO) having a memberOf relationship to the Collection of Collections.

Implementation

Collection of Collections is created by the Big Bang for NSDL.org. The handle to this aggregator is manually given to applications that need to add a generic collection as a memberOf that aggregator, thus establishing that generic collection as a Library Collection.

Viability of v2.0 Proposal

The addCollection specification allows for users to include zero or more parentCollections. This would fulfill the requirement of connecting a new Library Collection to the NSDL.org Collection of Collections.

Impact on Existing NDR Objects

NONE

Impact on Existing Applications

Required:

• NONE

Recommended:

• Manipulation (add, modify, delete, get) of new and existing collections should be through the v2.0 API

Functionality:	Collections (Josh 15:28, 30 March 2010 (UTC))
Description:	FeedEater is currently supposed to add resources from RSS feeds to library collections. In API 2.0, it seems that FeedEater will instead add resources to its own collections. FeedEater will need to be modified to replace the current method with a relationship-based, multi-collection method.
Application:	FeedEater
Required:	Yes
Long Term Plan:	FeedEater will present all collections within the library (including its own) to the user in a hierarchical manner. The user can select any collection to which a feed should add resources. Adding a feed to a selected collection will: Create a new collection for that feed. Set a parent collection on the new collection that points to FeedEater's "list of feeds" collection. Set a parent collection on the new collection that points to the selected collection. Add meta data to the new collection for ingesting and tracking. FeedEater's ingest process will need to be modified to select all collections with a parent that points to the "list of feeds" collection and operate on the resulting collections.
Required Changes to API:	It would be useful to either have an explicit addParent method or just input the actual collection record in a modifyCollection call. Having to specify <add> and <remove> seems error-prone, process-intensive, cumbersome and will require additional coding/logic in every application. I've never seen this method before; it muddies the waters between what is data and what is an operation. I don't want to have to iterate over a list of all collections and their data to find a single collection or the children of one. This will be a large waste of processing and bandwidth, especially after applications start adding larger numbers of collections. This is the problem that started this whole API process. The ability to retrieve a subset of collections would be extremely useful, such as getChildren(parentHandle). That doesn't scale well, though, as the properties of collections grows. Better still would be a find method that allows various parameters, e.g. findCollections("parentCollection", parentHandle). --Elrayle The current v1.0 API uses the <add>, <modify>, and <delete> commands for modify requests. The benefit is that you don't have to read the entire object and pass back things that you aren't changing. It allows you to target the specific part of the object you are changing. --Elrayle I'm not sure I'm following your use case for the scalability issue. Can you elaborate with a specific example? Once I understand the problem, perhaps we can come up with a solution that makes since for others as well. There is going to be a find API request. John will have to address the issues regarding whether you would be able to specify search criteria like find( where: "parentCollection"==parentHandle ). This is, of course, not the actual syntax. Assuming the find API request can handle getting you a list of children handles, does that meet your requirement?
Work Around:	None.

Metadata Providers

Metadata Providers objects are part of the GCCO for Library Collections. The objects and relationships shown for Collection Definition make up the GCCO. The Collection Management and Collection Content areas are included to provide context. Note that this diagram defines the composite object within the context of a Library Collection, but it is actually a generic container not restricted to the Digital Library architecture.

Traditionally, there has been a one to one relationship between the Collection Aggregator and the Collection Metadata Provider. With the advent of Web Feed Ingest, this is no longer the case. Multiple ingest mechanisms can feed a single Library Collection.

Further Description and Examples Based on Developer Questions

We currently have a GCCO named NSDL Collection of Collections which all NSDL applications give the meaning of representing the NSDL Digital Library. The NSDL Collection of Collections GCCO has children GCCOs that applications give the meaning of Library Collection. In the current modeling of NSDL in the NDR, the Metadata Provider(s) that are part of the Library Collection GCCO represent each possible provider of metadata for the Library Collection. Since these GCCOs are maintained manually and applications have access to all parts of the GCCO, this works.

The current structure is...

NSDL Collection of Collections (GCCO) -> Library Collection (GCCO)

where, Metadata Provider object(s) are part of the Library Collection (GCCO)

The problem for v2.0 is that the applications will no longer have access to all the parts of a GCCO. They will have access to the handle we give them that represents the GCCO as a whole. Any operations will be made on the GCCO as a whole and not to individual parts. So, we can either complicate the API by surfacing the concept of metadata providers (complete with AddMetadataProvider, DeleteMetadataProvider, ListMetadataProviders, etc.) or we can establish that there is one Metadata Provider per GCCO.

This brings us to the structure...

NSDL Collection of Collections (GCCO) -> Library Collection (GCCO) -> Metadata Provider (GCCO)

See Use Case: Building a Library Collection, with Three Sources of Metadata, for a Digital Library for how this would be created.

By using this structure, we can support collections with multiple metadata providers without having to change the API calls that create GCCOs (addCollection, modifyCollection, etc.). Simple and flexible.

Implementation

In the current implementation, applications are responsible for adding each object and establishing the relationships to existing objects that comprise the GCCO.

The proposed API is supposed to hide the implementation details of the GCCO and allow users to operate on a single conceptual object. The external representation (the one that applications know about) of the GCCO is the handle to the Collection Aggregator (NDR base object). All collection API requests (modifyCollection, getCollection, deleteCollection) pass this single handle as the representation of the collection.

Here is where it gets complex. To have multiple Metadata Providers in a single GCCO would require surfacing the concept of metadata providers. This creates the situation where there are multiple handles involved to work with the GCCO. Adding metadata would require identification of the Collection Aggregator handle and the Metadata Provider handle.

There is a proposal to create a hierarchy of generic collections to return to the simplified one-to-one relationship between Collection Aggregators and Collection Metadata Providers. See the proposed solution in Use Case: Building a Library Collection, with Three Sources of Metadata, for a Digital Library.

Since Metadata Record v2.0 API calls are not being implemented in the first round, addMetadata v1.0 API calls will need to be modified to take the Metadata Provider's GCCO handle (which is the aggregator handle) as the metadataProvidedBy handle and turn it into the handle for the metadata provider object that is part of the Metadata Provider's GCCO.

Viability of v2.0 Proposal

The current structure of NSDL.org Collection of Collections (aggregator) <-- Library Collection (GCCO with multiple Metadata Providers) cannot be maintained with the Collection level calls as proposed.

If the structure is moved to NSDL.org Collection of Collections (GCCO) <-- Library Collection (GCCO) <-- Metadata Provider (GCCO) is implemented, then the proposed API calls for Collections will work.

Impact on Existing NDR Objects

Each existing Library Collection (GCCO) will need to be split. The existing Metadata Provider objects in a Library Collection (GCCO) will be moved to a new Metadata Provider GCCO. The Metadata Provider object will become the Metadata Provider object for the Metadata Provider GCCO. A new Metadata Provider object will be created for the Library Collection (GCCO) to maintain the integrity of the GCCO for the Library Collection.

Impact on Existing Applications

Required:

• There will be a two step process for creating a Library Collection. 1) create the Library Collection (GCCO) and 2) create the Metadata Provider (GCCO).
• Trusted agents have the power to create the Library Collection (GCCO) NOTE: This isn't really a change.
• Owner agent must grant authorization to other agents
• The owner and authorized agents may create a Metadata Provider (GCCO) with the Library Collection (GCCO) as a parent

Recommended:

• All the required actions described can be accomplished with existing API calls, but attention to the details of the rules must be observed. It is highly recommended that applications switch all Collection level management (add, modify, delete, get) to the v2.0 API requests

NOTE: API calls to manipulate metadata objects may specify the metadataProvidedBy relationship which takes the handle to the metadata provider object. Applications using the v2.0 Collection level API will not have this handle. But the proposed implementation would allow the v1.0 Metadata API calls to operate with a Collection Aggregator handle which is the handle used by v2.0 Collection level API requests. All operations on metadata by applications will remain unchanged, now having the option of passing in the metadata provider handle or the collection aggregator handle. Use of the metadata provider handle will eventually be deprecated.

Functionality:	Datastreams (Josh 15:34, 30 March 2010 (UTC))
Description:	FeedEater uses datastreams (called "WFIngestParms" and "WFHistoryParms") on MDP objects to store information related to past and future feed ingest jobs. The application uses the setMimeType, setContent, getDatastream and addDatastream MDP methods.
Application:	FeedEater
Required:	Yes
Long Term Plan:	FeedEater needs a way to associate its own data with a collection. This data does not currently and may not in the future conform to any current metadata schema. I don't see a way to implement this using API 2.0. Annotations and the general/application data format will work, but those aren't available until API 2.1/post-August (AFAIK).
Required Changes to API:	None.
Work Around:	Creating a FeedEater-specific metadata format for API 1.0 calls or a (scary) general metadata format may work until annotations are available.

Functionality:	Datastreams (Tim 15:34, 30 March 2010 (EST))
Description:	The OAI metadata generation service (part of the NDR) uses the datastream ServiceDescription on MDP objects to fetch information for the construction of the OAI record. The application relies on the existing internal "GCCO" relationships to gather information. This process does not update the NDR objects.
Application:	getMetadata and getMetadataAbout (NDR methods) - these are disseminations on the Metadata Object type within the NDR.
Required:	Yes, so far.
Long Term Plan:	The Metadata generation service needs a way to gather its data. As long as the relationship structure (proposed) for the GCCO objects is well-defined - OR - this data is no longer required for the OAI records, we can move ahead.
Required Changes to API:	None
Work Around:	Modifying the OAI requirement for ServiceDescription data, or changing the methods to discover the new placement of this data.

Collection Metadata

The Collection Metadata is the metadata associated with the GCCO which represents the Library Collection. It appears to be applications specific.

Implementation

The Collection Metadata is currently created and maintained by applications using low level metadata object API requests. The Collection Metadata has a metadataProvidedFor relationship with the Collection Aggregator.

Usage:

• NCS puts in multiple datastreams in the Collection Metadata object.
• OAI - OAI harvest/ingest does not update any collection information.
• WFI ?

Functionality	MDP data streams
Description:	Ostwald 22:44, 26 March 2010 (UTC) The NCS is using data_streams in the MDP to store app-specific data about the NCS Collection. To the NCS it seemed the MDP was the appropriate place to store this, but in the end it doesn't matter where it is stored, as long as it is associated with the NCS Collection.
Application:	NCS
Required:	Yes
Long Term Plan:	Either use v2.0 Metadata API requests to add this information as metadata OR store this information as annotation(s) on the NCS Metadata Provider GCCO.
Required Changes to API:	Be sure that getCollectionRecord returns all metadata for the collection. The format of information returned by getCollectionRecord should probably be consistent with that of getResourceMetadata.
Work Around: (for August)	Use v1.0 addMetadata API request to add metadata to the NCS Metadata Provider GCCO's Aggregator object. The handle is returned when the NCS Metadata Provider GCCO is created.

Functionality	Collection Metadata (ncs_collect and GCCO Metadata in general)
Description:	Ostwald 22:44, 26 March 2010 (UTC) The Collection Metadata currently stores information about an NSDL collection that is used by the Collection Admin staff (this is the ncs_collect record, which is stored as a data_stream in the Collection Metadata Record).
Application:	All
Required:	Yes (for ncs_collect), No (for general GCCO Metadata)
Long Term Plan:	The current plan is to replace ncs_collect with nsdl_collect and to have applications use annotations for things like nsdl_collect. Currently, ncs_collect has ingest related information, while the proposed nsdl_collect will not include ingest related information. The nsdl_collect metadata will apply to every Library Collection GCCO regardless of ingest mechanism used. Ingest related information is considered application data and will be managed by each application by placing an annotation(s) on the Metadata Provider GCCO for that application.
Required Changes to API:	Be sure that getCollectionRecord returns all metadata for the collection. The format of information returned by getCollectionRecord should probably be consistent with that of getResourceMetadata.
Work Around: (for August)	You won't have access to "the Collection Metadata object". But you can add an additional metadata object. Use v1.0 addMetadata API request to add metadata to the Collection Level GCCO's Aggregator object. The handle is returned when the Collection Level GCCO is created. Since the current ncs_collect includes havest information, a copy of the ncs_collect may need to be placed on the Metadata Provider GCCO put in place for Harvest Ingest. This is to avoid adding a requirement that nsdl_collect be implemented prior to the August deadline.

Ostwald 23:04, 26 March 2010 (UTC) ISSUE - Is it true that we are no longer considering any form of collection-level metadata? If so, nsdl_collect (and ncs_collect) are no longer relevant. And we need to come up with some other means of managing information about NSDL collections. On the other hand, even though the collection-level metadata (ncs_collect) is written to the NDR, I don't believe any application actually accesses it from the NDR. Instead, the collection-level information is obtained via the NCS web service. Bottom line: if we don't care whether this info is actually stored in the NDR, maybe we don't need no stinking nsdl_collect.

--Elrayle - I'm not sure why it was decided to implement the addCollection call by specifying title, description, and contact(s) as parameters of addCollection. It all seems like metadata to me. I suppose it raises these to the level of required metadata. This design does limit the flexibility of GCCO metadata. I would have no problems with having addCollection be changed to have <metadataXML> and <metadataFormat> as parameters instead of <title><description><contacts>. Perhaps we can predefine <metadataFormat>default</metadataFormat> which includes those <title><description><contacts>. I believe the current long term plan for addressing this is the use of annotations to hold ncs_collect. (See comment below regarding metadata vs. annotations.)

--Elrayle - I have philisophical questions about the distinction between metadata and annotations. We haven't clearly defined the difference. In my mind, the distinction is between vetted information which is consistent with a Collection Management Policy about a collection or resource (Metadata) and user enhancements to a collection or resource (Annotations), where user can be a single user or application or organization. The key is that the information stored in annotations is not controlled by a Collection Management Policy. It is easy to see how star ratings, reviews, and comments fit as annotations. It is not clear that nsdl_collect metadata is an annotation.

Sclark - NSDL.org doesn't create collections but only retrieves information about collections. Currently, it uses the NDR in two ways - both in the Landing pages. 1. to get the resource URL from the handle provided by the Browser URL and 2. To get the collection metadata to display on the page. Possible Concern The Landing pages currently gets collection metadata from the NDR to display in the little drop down blue boxes linked from the logos. This is the same information as provided in the More Info about Collection page on search results, only the search results gets that (same) information from the search service. To me, I'm not really certain why the Landing Pages and the Search results pages gets their collection metadata from different places and it makes sense for both to get that info from one location. So...if this API doesn't provide collection metadata, can that metadata still be accessed via the search service for landing pages and search results display?

I'm figuring that I would continue to get the Resource URL the same way as I have been http://ndr.nsdl.org/api/describe/2200/20061003230008455T

Viability of v2.0 Proposal

In the current proposal, the Collection Metadata object is not exposed to applications. Applications could manually create a second metadata object through the v1.0 metadata base object API setting the metadataProvidedFor relationship to the Collection Aggregator handle returned by addCollection. This would create two Collection Metadata objects.

In a more general sense, the viability of simplifying Collection metadata down to title, description, and contacts is highly dependent on who and how the current metadata is used. There is a proposal to include this metadata as annotations of the collection, but annotations will not be available in the first round. It could be that having a second, or possibly many, metadata objects for a GCCO is a viable solution.

--Ostwald 22:16, 26 March 2010 (UTC) - Why not have an optional xmlBlob parameter to add/modifyCollections that is stored in the CollectionMetadata object?

• This xml, if present, would be inserted in the getCollectionRecord response.
• If getCollectionRecord was called on a collection that contained collections, then the xmlBlobs for the requested collection, as well as the blobs for all child collections, would be returned (similar to the listResourceMetadata)

--Elrayle - Does the work arounds and API changes described above address this concern?

Impact on Existing NDR Objects

NONE

Impact on Existing Applications

The impact of having two, any possibly many, Collection Metadata objects is unknown. Who uses the Collection Metadata besides the application that enters it?

Required:

• NONE

Recommended:

• Use addCollection to create the collection, which should simplify the process for creating the GCCO
• Add a second Collection Metadata object which is managed by the application through v1.0 metadata base object API requests

General Issues with Collection Level API

ServiceDescription

The OAI metadata generation service (part of the NDR api) method getMetadataAbout use this datastream from the metadata provider to generate the OAI about portion of the metadata records provided to the outbound OAI service

Primarily used to generate the branding information that is included in each OAI item record.

Functionality	ServiceDescription
Description:	Tcornwell 10:36, 26 March 2010 (EST) The OAI metadata generation service (part of the NDR api) method getMetadataAbout uses this datastream from the metadata provider to generate the OAI about portion of the metadata records provided to the outbound OAI service. Primarily used to generate the branding information that is included in each OAI item record.
Application:	PROAI Public, PROAI
Required:	Possibly OK to Deprecate
Long Term Plan:	DDS will take over the requirements of search. This information needs to be placed somewhere to be available for search whether the search is driven by PROAI or DDS. I believe, but am not sure, that branding information is to be part of the proposed nsdl_collect.
Required Changes to API:	Be sure that getCollectionRecord returns all metadata for the collection. The format of information returned by getCollectionRecord should probably be consistent with that of getResourceMetadata.
Work Around: (for August)	If it can't be deprecated, can it be converted to metadata for the GCCO? Note that the only reason it can be deprecated is because this information is currently retreived from NCS, not the NDR. Long term, this information should be coming from the NDR. Deprecation is seen as a short term work around, not a long term solution.

State vs. OAI Visibility

Currently, the OAI Visibility property is used to determine whether a metadata item can be placed in the public OAI and search OAI feeds produced by NDR.

State has been proposed as having values Active and Inactive. The purpose is unclear. Its relationship to OAI Visibility is unclear.

KG response: The potential use case idea was if someone downloads the NDR and they don't want to be concerned with the NSDL collection information/notion but just want a way to indicate whether a collection is active or inactive (this is why state was put in the ndr_collect record).

However, this use case is not well developed and I am not sure what would be the desired actions if a collection is listed as inactive.

Bottomline: remove the state concept but keep the OAI visibility concept (in nsdl_collect) because the NSDL Collection Policy allows collections builders to tell NSDL 'don't share my metadata outside of NSDL'.

--Elrayle 13:47, 26 March 2010 (UTC) ... Katy, nsdl_collect is not used currently, is that correct? Can you elaborate what is currently used, what you are proposing, and the impact of that proposal on NDR as a whole and applications specifically?

KG: nsdl_collect is the proposed replacement for ncs_collect which is the current NSDL collection metadata format and currently tracks OAI visibility. So I am saying current functionality needs to be kept and continued. I am not sure how this OAI visibility is currently done on the back-end but this OAI visibility is currently being recognized and needs to continue.

Tcornwell 11:38 EST, 26, March 2010 The "state" value is a part of the fedora object - the predicate is: fedora-system:def/model#state. As such, I don't think that it can be removed from any fedora object. I believe that it is currently used to identify metadata objects that are to be marked as deleted through the NDR API "delete" method. This mechanism allows the OAI service to find & flag these items as deleted.

--Elrayle -- I believe that "state" was being proposed as the status of the creation process, for example state="Inactive" while the Library Collection is under development and state="Active" once it is complete. I had proposed the use of the Fedora Object state as the implementation, but the concept was never fully developed. Tim's statement is about the current functioning of the use of the Fedora Object state and will remain unchanged. The state issue is being latered for discussion at a later point in time. It will not be part of the implementation for the August deadline.

--Elrayle -- Mixed up in all this is the concept of visibility that is currently driven by OAI Visibility property. This is also not well defined. The table below describes the OAI Visibility issue.

Josh 15:45, 30 March 2010 (UTC) -- It seems to me that OAI visibility is OAI-specific application data that is used by other applications (possibly poorly). Any collection-defined "state", which I think is a bad and ambiguous idea, should not apply to one specific application, but to everything as a whole as it is a property of that collection in the entire system. It would be better, for example, to have a production library collection and a testing library collection, and maybe an archive or deleted collection. If that's not applicable, maybe I don't understand what "state" is meant to signify--which just illustrates the ambiguity.

Functionality	oai_visibility
Description:	The oai_visibility property controls whether all metadata records for a metadata provider are included or excluded from PROAI-PUBLIC and/or PROAI (search). Rules for PROAI-PUBLIC: metadata included only if (metadata)OAIvisibility="PUBLIC" && (metadataProvider for Collection)OAIvisibility="PUBLIC" Rules for PROAI (search): metadata included only if (metadata)OAIvisibility!="PRIVATE" && (metadataProvider for Collection)OAIvisibility!="PRIVATE
Application:	PROAI Public, PROAI
Required:	In some form to meet contractual obligations regarding visibility.
Long Term Plan:	DDS will take over the requirements of search. How will this be surfaced in DDS?
Required Changes to API:	TBD
Work Around: (for August)	More information is needed. I believe that oas_visibility is a property of the Metadata Provider base object that is part of the Library Collection GCCO.

Sign Off

Each developer should place mark the status beside the application(s) that you support. I indicated the developer that I believe to be responsible. Of course, change the developer name if someone else is responsible. Feel free to add comments below the sign off table or in the text of this document if you have questions or concerns.

Possible Values for Status:

• OK - indicates your belief that the proposed specifications and impact analysis are acceptable for the application
• Concern - indicates that the proposal won't work or you have some concerns that need to be addressed
• N/A - indicates application either doesn't use NDR-API, or does not have any Collection related NDR-API interactions

Application	Developer	Status
NCS (NSDL Collections)	Jonathan	I am concerned that we have no way to manage Collection Admin information
NCS (non-NSDL Collections)	Jonathan	Okay for now but eventually need app-specific data
Harvest Manager	John	N/A
OAI Harvest	Tim	Okay
Web Feed Ingest	Josh	Concern
OAI Services (proai)	Tim	Okay for now with modifications to accommodate new GCCO heirarchy.
Search	Tim	N/A - This currently relies on OAI feeds.
Content Cache	Tim	N/A
Sitemap	Tim	N/A - Sitemaps uses the fedora RI directly.
Expert Voices	Josh
OnRamp	Lynette	N/A - uses WFI
NSDL Wiki	Tim	N/A - since direct editing of the NDR has been deprecated.
Math Images Wiki	Tim	Concern I have no idea if this application's users are updating the NDR.
DDS-NSDL	John	OK
Strand Maps	John	N/A
NSDL.org	Sharon	Possible Concern see above regarding collection metadata as used in the landing pages and search results
Collections	Katy	I am concerned that we have no way to manage Collection Admin information

Developer Concerns

If you marked that your status that you have concerns, please elaborate here. You can sign your comments using --~~~~ in the wiki markup.

--Ostwald 22:19, 26 March 2010 (UTC) - without annotations and without collection metadata there doesn't appear to be any way to stash application-specific data in the NDR. For the NCS this means we can't assume the NCS can be bootstrapped from the NDR, which at one time was a requirement. Because this requirement has never been exercised, I am willing to live without it (at least until annotations are available).

--Ostwald 23:22, 26 March 2010 (UTC) - As things currently stand, all information used to administer collections (and also used by other apps such as NSDL.org and Harvest Manager) lives only outside the NDR, which at one point was a big concern.

--Ostwald 23:22, 26 March 2010 (UTC) - I would be very concerned if clients of the API were required to descend to the lower-level NDR 1.0 API to perform basic operations. Without basic item-level calls at the 2.0 level, even if clients are able to create collections they won't be able to populate them without making multiple 1.0 API calls for each resource/item. Also at the collection level (e.g., as discussed with respect to Collection Metadata) having to make 1.0 calls seems a BAD thing.

--Elrayle - I understand your concerns about the lack of Item Level 2.0 API calls. These have not been discarded. The implementation approach being used here is iterative. By the August deadline, all Collection Level 2.0 API calls will be implemented and placed into production. This means that everything has to be able to play nicely in this partial 2.0 API implementation. The team will then decide which functionality should be put in place for the next iteration, most likely this will be either Annotation v2.0 API requests OR MetadataRecord v2.0 API requests. Again, the second iteration will be expected to be complete and placed into production. All applications will then need to be able to play nicely with Collection v2.0 API request and (if selected for the next iteration) MetadataRecord v2.0 API requests. Appropriate work arounds will need to be made for the other v2.0 API calls that are not yet implemented. This may not be an ideal approach, that is releasing the API in iterations, but it necessary to meet the August deadline given the level of resources we have to commit to the task.

--Elrayle - I created Use Case: Building a Library Collection, with NCS Managed Metadata only, for a Digital Library that describes how to use addMetadata for Collection Metadata and Application data.

Josh 15:53, 30 March 2010 (UTC) -- One problem API 2.0 is supposed to solve still exists: there is no easy way to find collections based on criteria. It seems this is fairly easily solvable and significantly future-proof with a find method. Worse still, there seems to be no way to store application-specific data whatsoever in a post-August, pre-2.x-finished world. FeedEater requires application data to function, whether this is kludged into metadata or moved into a MySQL database, it needs to exist somewhere...

--Elrayle - PROAI search is going to be replaced with DDS search. DDS search will implement the v2.0 findCollection API request. I am not clear on the details of this since John will be implementing this part. Josh, does that address you concern? I will update the feature list to include a find api request. BTW, there is a v1.0 find method. I'm not sure how it is implemented. I assume it is insufficient to the task or it would already be in use.