5th DatasourceServiceProposal

General strategy

Address the most important of the 3 types of services identified (DatasourceServices, ProviderServices and MessageBrokerServices): the*DatasourceService*.

Files

• Shared Core Schema : http://ww3.bgbm.org/viewcvs/viewcvs.cgi/*checkout*/schemas/protocol/newprotocolCore.xsd
• Datasource Service Schema : http://ww3.bgbm.org/viewcvs/viewcvs.cgi/*checkout*/schemas/protocol/newprotocolDatasource.xsd

Details

• Address only DatasourceServices ( ~ DiGIR? resources) in the protocol.

• Use the same approach regarding AccessPoints:
• Only datasources will have an access point (provider software access point is not covered by this protocol).
• Datasources will accept all kind of requests.
• Eliminate DifferencesInHeaderInformation? by (see DatasourceHeaderProposalOne):
• Removing the optional attribute "resource" in both "source" and "destination" elements (affects DiGIR?).
• Removing the "destination" element (affects both).
• Allowing multiple "source" elements to be able to track each address in the process, and incorporating the "sendTime" element as an attribute of "source". However, intermediaries don't need to stamp a source element - it's an optional behavior (affects both - related to new BioCASE? proposal).
• Making the address ("accesspoint") an attribute of "source", not its content. In responses from a datasource, the address should be the exact accesspoint of the datasource (affects both).
• Including an optional "software" attribute inside the "source" element which should hold the name and version of the software used. More detailed software descriptions can be specified in the capabilities reponse (affects both).
• remove the "type" element and only use the immediate element after "header" to determine the type of requests/responses.

• Eliminate DifferencesInRequestTypes by: (for detailed definitions see further below)
• Including a MetadataRequest FifthProposalDatasourceServiceProposal Response (affects BioCASE?).
• Defining the metadata elements in a separate schema (affects both).
• Including a CapabilitiesRequest FifthProposalDatasourceServiceProposal Response (affects DiGIR?).
• Including a PingRequest FifthProposalDatasourceServiceProposal Response (affects both).
• Provisionally have 2 seperate search Request FifthProposalDatasourceServiceProposal Response types:
  • a "search" Request FifthProposalDatasourceServiceProposal Response as the RecordBasedApproach (affects both).
  • a "docsearch" Request FifthProposalDatasourceServiceProposal Response as the DocumentBasedApproach (affects both).

• Use the same ping Request FifthProposalDatasourceServiceProposal Response: (see PingProposalOne) (affects both)

• Use the same metadata response initially based on DiGIR? but with some changes: (see DatasourceMetadataProposalTwo)
• Resource renamed to datasource.
• Included accessPoint in the datasource.
• Removed the implementation element (duplicated).
• Moved elements minQueryTermLength, maxSearchResponseRecords, maxInventoryResponseRecords to the CapabilitiesRequest.
• Removed recordBasis and recordIdentifier elements.
• Changed useRestrictions to a generic "rights" element (equivalent to previously suggested IPR and to a Dublin Core element). Accepts xml:lang attribute.
• Provider metadata is now a datasource relatedEntity.
• Datasource name renamed to label and accepts xml:lang attribute.
• Keywords element accepts xml:lang and has maxOccurs unbounded.
• Citation is an element (with maxOccurs unbounded and xml:lang).
• Conceptual schema needs an associated schema location in its content.
• Made dateLastUpdated and numberOfRecords as an attribute part of the conceptual schema element.
• Datasource has a list of related entities.
• Each entity accepts a list of names (xml:lang), a list of roles (with controlled vocabulary defined by networks), a logo url, a description (xml:lang), an acronym and related information links.
• If values of related entities come from a local cache, we recommend a diagnostics warning in responses.
• Open Issues:
  • Each entity needs a GUID.
  • Included "language" element related to the datasource content (from Dublin Core).
  • Included generic multiple element typeOfContent. Networks should agree on a controlled vocabulary. (equivalent to Dublin Core "type" element).

• Use the same CapabilitiesRequest and Response by: (see DatasourceCapabilitiesProposalOne)
• Including a list of conceptual schemas being used (and all mapped concepts) and incldue capabilities for each schema:
  • Including a list of request methods supported.
  • Including a list of local settings (minQueryTermLength and a generic maxResponseSize substituting maxSearchResponseRecords and maxInventoryResponseRecords).
  • Optionally including a more detailed list of software in the response.
  • Including supported operators separated by categories.
  • Include the RecordDefinitions used for the conceptual schema
• Include the metadata schema being used for the SearchResponseTopStructure

• Eliminate DifferencesInConceptualBinding by: (see ConceptualBindingProposalOne)
• Referencing concepts through simple xpaths (affects DiGIR?).
• Allowing concepts from different conceptual schemas to be present in the same request by prefixing the path (affects mainly BioCASE?).

• Use the same InventoryRequest and Response: (see DatasourceInventoryProposalOne)
• Allowing filters (affects BioCASE?).
• Allowing counts, both partial and total (affects BioCASE?).
• Using the name "inventory" for this type of request (affects BioCASE?).
• Allowing more than one concept in inventory/scan requests (affects both).
• Always sort results. Order by sequence of requested concepts if multiple.

• Eliminate DifferencesWithOperators by:
• adding a new unary logical operator called "not" (affects DiGIR?).
• adding a new unary comparative operator called "isNull" (affects DiGIR?).
• dropping the operators "orNot", "andNot" and "notEquals" (affects both).
• dropping the operator "isNotNull" (affects BioCASE?).

• Additional enhacements to operators:
• allow comparative operators to compare any 2 expressions, which can be made of literals (values) or concepts. This would allow to compare 2 concepts also instead of the current restriction to compare a concept with a literal only.
• allow functions.
• change maxOccurs of LOPs to unbounded (affects both).

• Use the same way to call providers:
• Using a single POST or GET parameter called "request" which contains either the XML message or an URL pointing to the XML message.

• Changes in filters:
• allow search requests without filters (affects both).
• evaluate to false if concept is not mapped but compared.
• always insert info/warn diagnostic if unmapped concept encountered in request.

• Use the same error handling strategy:
• use CommonErrorCodes and prefixes for classification of codes.

• How should we deal with NULL values when producing responses? NULL is non existing informaion and the element containing a NULL value should therefore be dropped and not be part of the response.

• Use the same SearchRequest for a RecordBasedApproach by (see DatasourceSearchProposalOne):
• Use a fixed SearchResponseTopStructure to include metadata
• Use new footer element to give information for paging and counting.

• Use the same SearchRequest for a DocumentBasedApproach by (see DatasourceDocsearchProposalOne):
• Use new footer element to give information for paging and counting.
• ...