When online information about a resource adheres to one or more profiles, methods described here allow clients to list those profiles and request content according to one or more of them in order of preference. - For example, a catalog may offer a dataset description using alternative representations using [[VOID]], - [[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the - [[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and also an organisation specific profile "MyOrgDCATProfile" - which constrains various elements. These profiles may be related - for example "MyOrgDCATProfile" may be a - further profile of [[GeoDCAT-AP]]. A request for the information about this dataset description resource may - ask for the list of profiles available, or it may ask specifically for a response adhering to, for example - [[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content, + For example, a catalog may offer a dataset description using alternative representations using [[VOID]], + [[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the + [[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and also an organisation specific profile "MyOrgDCATProfile" + which constrains various elements. These profiles may be related - for example "MyOrgDCATProfile" may be a + further profile of [[GeoDCAT-AP]]. A request for the information about this dataset description resource may + ask for the list of profiles available, or it may ask specifically for a response adhering to, for example + [[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content, that is, content conforming to the default profile supported by the server.
@@ -71,10 +71,12 @@
Describing the parts of profiles and their relation to other profiles is the function of the Profiles Vocabulary [[PROF]], also produced by the DXWG. @@ -93,38 +95,40 @@
- An act of identifying something precisely or of stating a precise requirement. - Oxford English Dictionary + A basis for comparison; a reference point against which other things can be evaluated. +
+
+ Source: DCMI Metadata Terms [[DCTERMS]]'s definition for a Standard.
- One form of a specification is a standard which is a "basis for comparison; a reference - point against which other things can be evaluated" - [[DCTERMS]] + A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.
+Source: deliberations of the DXWG.
- A named set of constraints on one or more identified base specifications, - including the identification of any implementing subclasses of datatypes, - semantic interpretations, vocabularies, options and parameters of those base specifications - necessary to accomplish a particular function. + A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.
- This definition includes what are often called "application profiles", "metadata application - profiles", or "metadata profiles". + This definition includes what are sometimes called "application profiles", "metadata application + profiles", or "metadata profiles". In this document, these, and "data profiles", are all referred to as just "profiles".
-Source: deliberations of the DXWG. See ProfileContext wiki page.
+Source: deliberations of the DXWG.
ARK (Archival Resource Key) [[ARK]] is an identifier scheme for the persistent identification of information objects. - ARK identifiers can contain an optional qualifier + ARK identifiers can contain an optional qualifier "that extends the base ARK in order to create a kind of service entry point into the object named by the NAA [sc. Name Assigning Authority]." Through a qualifier, any NMA (Name Mapping Authority, a service provider offering ARK resolution) @@ -340,7 +344,7 @@
[[CSW]] is the OGC standard used world-wide by the geospatial community to implement a machine-actionable interface
- to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.),
+ to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.),
as well as other types of resources. Besides supporting common functions such as free-text and faceted search, CSW supports the retrieval of metadata according to a given metadata schema and format, indicated respectively by using outputSchema and outputFormat query parameters. Commonly supported metadata schemas are [[DC11]], and [[ISO-19115]], and the default format is XML. A given CSW instance's supported metadata schemas and formats are described in the service "capabilities" -- a machine-readable description of the service interface, that is returned via a GetCapabilities request.
@@ -368,9 +372,9 @@
An Internet resource may have many aspects over which a client/server pair of - agents might negotiate for content. These aspects are to be treated independently so content negotiation for a + agents might negotiate for content. These aspects are to be treated independently so content negotiation for a resource involving negotiation by profile and any other aspects of a resource will not affect - each other. For this reason, other than a directive to maintain independence, no further discussion of + each other. For this reason, other than a directive to maintain independence, no further discussion of negotiation by profile and the relations to other forms of negotiation are given. Specific realizations might require special handling of profile and other forms of negotiation.
@@ -412,13 +416,13 @@A server adhering to this specification MUST respond to each request with the following - responses. + responses.
A client wishes to know for which profiles a server is able to deliver conformant - representations of a resource. The content of the list can be known either before a request for a + representations of a resource. The content of the list can be known either before a request for a particular resource representation is made or it may only be known after an initial request for a resource representation is made.
@@ -717,21 +721,21 @@- While the HTTP-header approach to profiles enables fully automated retrieval of data conforming - to a desired profile, it is also advisable to enable humans to select data by profile without - requiring direct manipulation of request header content. This can be accomplished by existing - web development methods where an API supports a graphical interface. The user can be presented - with a list of available profiles and given the choice of which to retrieve for the dataset of - interest. They can even be asked to indicate a ranked choice of possible profiles, which could - then be used to retrieve multiple resources' data matching a query. + While the HTTP-header approach to profiles enables fully automated retrieval of data conforming + to a desired profile, it is also advisable to enable humans to select data by profile without + requiring direct manipulation of request header content. This can be accomplished by existing + web development methods where an API supports a graphical interface. The user can be presented + with a list of available profiles and given the choice of which to retrieve for the dataset of + interest. They can even be asked to indicate a ranked choice of possible profiles, which could + then be used to retrieve multiple resources' data matching a query.
- As one example of how an API for such a service can be implemented, a Query String Argument (QSA) - realization of the Abstract Model is presented here. Unlike the HTTP-header - realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization - is fully specified here but it is not normative. This realization does not preclude other URL schemes, - or even other QSA schemes, for profile negotiation, the general requirement being that any scheme - implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully + As one example of how an API for such a service can be implemented, a Query String Argument (QSA) + realization of the Abstract Model is presented here. Unlike the HTTP-header + realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization + is fully specified here but it is not normative. This realization does not preclude other URL schemes, + or even other QSA schemes, for profile negotiation, the general requirement being that any scheme + implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully documented and discoverable.
@@ -857,7 +861,7 @@
aaa,bbb,ccc will receive a resource that meets the requirements of profile
+ a client requesting profiles as aaa,bbb,ccc will receive a resource that meets the requirements of profile
aaa if it is available, else one that meets profile bbb if that is available, and so on.