Re: I can has GetCapabilities media types?

Or perphaps this is something for the use cases and requirements? This use
case seems to be an example for the general requirement Compatibility with
existing practices. Recording this particular incompatibilty could help in
resolving it.

Regards,
Frans


2016-02-01 12:01 GMT+01:00 Ed Parsons <eparsons@google.com>:

> Thanks Maik, I agree this sounds like a CR against the WMS spec ?
>
> ed
>
>
> On Sun, 31 Jan 2016 at 12:17 Maik Riechert <m.riechert@reading.ac.uk>
> wrote:
>
>> Dear all,
>>
>> As you may know, all OGC web services have a root GetCapabilities
>> document that contains metadata about the content and functionality of
>> the service. When I want to advertise an OGC web service as a whole
>> somewhere, then this is the web resource to use.
>>
>> Example:
>>
>> http://sampleserver1.arcgisonline.com/ArcGIS/services/Specialty/ESRI_StatesCitiesRivers_USA/MapServer/WMSServer?REQUEST=GetCapabilities
>>
>> Now, imagine you have a dataset which is published as a zip file but
>> also as a WMS service (for having rendered map layers) and a WCS service
>> (for programmatic access to the data):
>>
>> http://example.com/mydataset
>> http://example.com/mydataset/324hh42 (zip file)
>> http://example.com/mydataset/kkj423kl?REQUEST=GetCapabilities (WMS)
>> http://example.com/mydataset/nknklnkl23?REQUEST=GetCapabilities (WCS)
>>
>> I used random characters on purpose here, could be some database ID.
>>
>> Since I want my dataset to be easily ingestable in CKAN and other
>> catalogs, I decide to describe it in terms of DCAT, meaning I write a
>> DCAT description in some RDF dialect and put that file somewhere so that
>> I can give it to CKAN admins and tell them to start ingesting my dataset
>> metadata.
>>
>> To make a long story short: There's no way for a machine to easily
>> differentiate between different OGC services (here WMS and WCS), or even
>> saying it is an OGC service at all, in DCAT distributions. Why not?
>> Because all OGC GetCapabilities requests come back as a generic
>> text/xml, meaning that no specific media types exist for different OGC
>> GetCapabilities service types, which means I can only put "text/xml" as
>> media type in my DCAT distribution, and that is pretty meaningless. It
>> also means that an automated client first has to load that distribution
>> to figure out it is actually an OGC service. And *that* in my opinion is
>> not very discoverable or efficient.
>>
>> ArcGis, MapServer, and possibly others support the
>> "application/vnd.ogc.wms_xml" media type for both WMS GetCapabilities
>> and GetFeatureInfo. I'm not sure who exactly invented that, but it's not
>> OGC I think. I couldn't find an equivalent for WCS.
>>
>> CKAN itself has a special "format" field with hardcoded constants for
>> identifying certain APIs like "wms" etc. But there is no reliable way to
>> derive that field from a DCAT distribution at the moment.
>>
>> Since OGC web services in their current form will not disappear any time
>> soon, I strongly suggest to at least fix this minor problem by defining
>> media types for the GetCapabilities documents, which is more or less
>> equal to a service endpoint.
>>
>> Some suggestions...
>>
>> application/vnd.ogc.wms+capabilities+xml
>> application/vnd.ogc.wcs+capabilities+xml
>> .....
>>
>> Thanks
>> Maik
>>
>> PS: When I query the RDF/DCAT interface of CKAN, I get back
>> dct:format="wms". And I parse that and hope for the best. Enough said!
>>
>>
>> --
>
> *Ed Parsons*
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>

Received on Monday, 1 February 2016 12:29:18 UTC