35 lines
1.9 KiB
Plaintext
35 lines
1.9 KiB
Plaintext
---+++ Metadata Request
|
|
|
|
This request returns some metadata about the provider and its datasource.
|
|
|
|
In DiGIR the structure of the metadata is defined within the protocol, in BioCASE currently there is no metadata request at all.
|
|
|
|
---+++++ Issues
|
|
|
|
* What metadata do we need ?
|
|
* Does the metadata describe single resources or all resources of a provider? See also the AccessPoint discussion as a basis for this.
|
|
* It should be useful to automatically fill UDDI registries like GBIFs (implementation issue)
|
|
* It should be compliant to the [[http://efgblade.cs.umb.edu/twiki/bin/view/SDD/UnifiedBioInfoFramework][UnifiedBioInfoFramework]] of SDD, ABCD and the upcoming Names standard
|
|
|
|
* Can we use a separate schema for defining the metadata structure ?
|
|
|
|
---+++++ Metadata Content
|
|
|
|
* No matter if resources are addressed by the protocol or whether a single AccessPoint is always a single resource, the metadata response should contain data about the provider and _ALL_ its available resources. This allows one to easily discover resources as soon as they are added.
|
|
|
|
* UDDI ...
|
|
|
|
* UBIF ...
|
|
|
|
|
|
---+++++ Metadata Definition Proposals
|
|
|
|
* MetadataProposalOne
|
|
|
|
---+++++ Separate Metadata Schema
|
|
|
|
By separating the metadata definition from the protocol, giving it its own namespace, it would be possible to use the same metadata schema in other situations outside the protocol and to manage versions separately. And other networks could easily use different metadata schemas.
|
|
Still, it would remain a "fixed part of the protocol" and should be referenced from there to define a standard metadata response for all providers regardless of the conceptual schemas being used.
|
|
|
|
If more data items are required than the standard metadata does not define, each community is free to use its own standard metadata as yet another ConceptualSchema configured by a provider.
|