wiki-archive/twiki/data/TAPIR/ProtocolFeaturesRequestMethodsMetadataRequest.txt,v

head	1.12;
access;
symbols;
locks; strict;
comment	@# @;


1.12
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.11;

1.11
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.10;

1.10
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.9;

1.9
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.8;

1.8
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.7;

1.7
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.6;

1.6
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.5;

1.5
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.4;

1.4
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.3;

1.3
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.2;

1.2
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.1;

1.1
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	;


desc
@Initial revision
@


1.12
log
@Revision 12
@
text
@---+++ 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.
@


1.11
log
@Revision 11
@
text
@d27 1
a27 1
   * MetadataResponseProposalOne
@


1.10
log
@Revision 10
@
text
@d25 1
a25 1
*Metadata Definition Proposals*
@


1.9
log
@Revision 9
@
text
@d11 1
a11 1
      * It should be useful to automatically fill UDDI registries like GBIFs
d27 1
a27 2
   * MetadataResponseProposalOne based on DiGIR with seperate AccessPoints
   * MetadataResponseProposalTwo based on DiGIR with a single AccessPoint
d29 1
a29 3
---+++++ Seperate Metadata Schema
It would be clean to seperate the metadata definition from the protocol by giving it its own namespace and a seperate schema.
Still it is very much a fixed part of the protocol and should be referenced from there to define a standard metadata response for all providers regardless of their used conceptual schemas.
d31 4
a34 1
If more data items are required than the standard metadata does define, each community is free to use its own standard metadata as yet another ConceptualSchema configured by a provider.
@


1.8
log
@Revision 8
@
text
@d4 1
d24 5
a28 16
Following is a first metadata response proposal based on DiGIR:
<verbatim>
<metadata>
  <provider>
  ...
  </provider>
  <resources>
    <resource>
    ...
    </resource>
    <resource>
    ...
    </resource>
  </resources>
</metadata>
</verbatim>
@


1.7
log
@Revision 7
@
text
@d17 1
a17 1
   * 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.
@


1.6
log
@Revision 6
@
text
@d8 1
a8 1
   * What metadata do we need?
d13 1
a13 1
   * Can we use a separate schema for defining the metadata structure
@


1.5
log
@Revision 5
@
text
@d23 1
a23 1
Following is a first metadata response definition based on DiGIR:
@


1.4
log
@Revision 4
@
text
@d9 1
a11 1
      * Does the metadata describe single resources or all resources of a provider? See also the AccessPoint discussion as a basis for this.
d17 3
d21 1
d23 16
a38 1
to be completed...
@


1.3
log
@Revision 3
@
text
@d3 1
a3 1
This request returns some metadata about the provider/datasource.
d6 1
a6 1
*Open questions*
d11 1
d15 11
a25 1
   * What is descibed by the metadata? See the discussion about what is a provider, resource, datasource, etc. in ProtocolFeatures/AccessPoint
@


1.2
log
@Revision 2
@
text
@d12 1
a12 1
   * Can we use a seperate schema for defining the metadata structure
@


1.1
log
@Initial revision
@
text
@d14 1
a14 1
   * What is descibed by the metadata? See the discussion about what is a provider, resource, datasource, etc.
@