ANZLIC The Spatial Information Council  
[Jurisdictions][Home][Contact Us][Site Map][Site Search][Glossary]  
 

 

ASDI-L Mailing List Archive

From: Doug Nebert ([email protected])
Date: Thu Jun 19 2003 - 02:19:34 EST


David Crossley wrote:

>
> > ApplicationProfile
> > (ISO defines as "Name of Application
> > profile that can be used with the
> > on-line Resource")
> > be something like a list of formats
> > e.g. OGC (need help here)
>

I interpret the Application Profile to be something different - in
current OGC usage and ISO usage, it is more a shorthand for a domain
of application that could be associated with specific operations and
even multiple formats or schemas of response. This field hasn't been
worked out in practice, but it means more than protocol. In practical
implementation our national profiles or communities of practice
will need to adopt a common approach for how to populate these
fields with identical semantics, or we won't interoperate.
 
> Here are two examples of what we are using in that field:
> ogc:WMS-1.1.0-http-get-map
> ogc:WMS-1.1.0-http-get-capabilities
> I think that this is dangerous - too much information in one field.
> It would be better to have separate metadata fields.
>

This actually follows a "URI" scheme where we decomposed the aspects
of Protocol (not application profile) where they would make a
difference. This is documented in a white paper I sent to OGC with
such ideas and provides some examples. Here is an excerpt:

"To accommodate these variations, the following syntax is recommended
in support of the OGC Web Mapping Service specification, as an example:
Protocol should be constructed as a case-insensitive multi-part value
separated by dashes, square brackets denoting token boundary:

[namespace]:[service_name]-[version_number]-[interface]-[option]-[interface_name]

For example, the following case would infer the existence of a link
that would return the behavior (registered with the OGC) of a
capabilities request over http per the WMS 1.1.1 specification.
Advanced clients would be able to exploit this to retrieve the full
capabilities.xml file and construct a client interface:

<protocol>ogc:WMS-1.1.1-http-get-getCapabilities</protocol>
where:
Ogc = Namespace
WMS = Service Name
1.1.1 = Version number of the highest level of compatibility supported
http = interface protocol (e.g. http, soap, corba)
get = option on the protocol interaction (optional: use -- if missing)
getCapabilities = interface/operation's published invocation name

All permutations of services and interface handles could be specified
using this syntax by creating an Online Source compound element for
each instance."

Yes, individual XML tags could be created for these subparts, or,
more interestingly, xlink attributes of the <protocol> tag could be
added to carry these individual characteristics, but either of these
solutions would 'break' the ISO standard and would not validate
without extension. Unless we all adopt the same tag extensions
(which could be a policy decision) it's safer, if inelegant, to
create this multipart value string to denote what we are looking
for and parse for "WMS" and "map" somewhere in the <protocol> tag!

I support your notion of declaring service associations from the data
point of view - that is, where known, potentially multiple ways that
a dataset can be exposed. These could, separately, express that this
data set is know to be bound to an ftp download, a Web Map Service,
and a Web Feature Service, for example, by having three OnlineResource
blocks. This does not obviate the need to separately manage some
service metadata also in ones catalog that may reference the data
instances, in turn (and their detailed metadata). So we still can
see a value in managing a catalog that hosts service metadata
(see ISO 19119 for example) and data metadata (ala 19115 via 19139).

In our research, and testbed activities in OGC bear this out, an
extension to this is to develop a third lightweight "association"
that can be held in a catalog to link specific data sets and
specific service instances and their searchable metadata. This helps
handle the various many-to-many connections between services and
data. After all, its really the specific combination of a desired
data set by its content PLUS the right version of a service
or operation that you can use that one is looking for, and you'd like
most of the service and data properties to be searchable -- without
overloading either the service or data descriptions! An association
entity should be recognized as a tried-and-true relational database
technique when normalizing a database where many-to-many
relationships exist between entries. To make this work in a
catalog, it is ever more important to have persistent data and
service instance identifiers that can be quickly looked up and to
load all the searchable properties into the catalog for ease of
access. The further refinement of this practice in a catalog is a
subject of current development work in the OGC.

Doug.

-- 
Douglas D. Nebert
Geospatial Data Clearinghouse Coordinator 
FGDC/GSDI Secretariat	Phone: +1 703 648 4151	Fax: +1 703 648-5755


[#top]