webService

[mhogeweg]

Can someone clarify the definition and use of the webService element?

definition: "This field will serve to delineate the web services offered by an agency and will be used to aggregate cross-government API catalogs."

from this definition it is not clear if the value should include a web service URL like this on from the USGS National Map program:
http://services.nationalmap.gov/ArcGIS/services/US_Topo/MapServer/WMSServer?request=GetCapabilities&service=WMS

or if the value should point to a DCAT formatted json file (as in the provided example value) that in itself lists references (what is an 'API Catalog'?) to web services.

in the first case, I suggest to update the example in the schema description. if the second purpose/use is intended, there still needs to be a place in the DCAT schema itself to point to web services.

[MarinaNitze]

The webService field is designed to cleanly create an API catalog for the federal government. Unfortunately it's not possible (as far as we are aware?) to automatically parse all entries to surface APIs.

How would you propose we make this clearer and more functional?

[jpmckinney]

webService is not a DCAT property. It's a DCAT class. This schema is using it as a property, which doesn't exist in DCAT. It's fine to keep the property around, but you can't put it in the dcat: namespace (e.g. dcat:webService) if you do.

[MarinaNitze]

@jpmckinney As long as we use the ex: namespace in the examples, are we still relatively aligned? What would you change to make this clearer?

[jpmckinney]

Using ex: would avoid the DCAT issue. However, ex: is a namespace reserved for examples used in documentation. Ideally, this project should publish a brief document that declares a new namespace (maybe pod?) and defines the RDF terms in that namespace (like pod:webService).

[mhogeweg]

👍 on defining a pod namespace shortly for those things that are pod-specific elements. however, @jpmckinney I don't see a webService class in DCAT. I do see a dcat:Distribution class that 'represents an accessible form of a dataset as for example a downloadable file, an RSS feed or a web service that provides the data'. So this class is suited for recording a web service reference in its accessURL property.

[jpmckinney]

Ah, yes, the WebService class was removed in favor of the Catalog > Dataset > Distribution model. Update: Correction, they were subclasses of Distribution. In any case, WebService, Feed, and Download are gone from DCAT now.

[MarinaNitze]

We understand that DCAT no longer uses webService ... but there was still pretty strong consensus it was worthwhile to maintain it as a separate field to auto-populate a government-wide API catalog. I can't parse Distribution/Format for an API like I can an RSS feed (which we're removing in a nod to new DCAT).

So, we'll need a POD namespace to incorporate our own webService (and our other fields). This is a great idea. Do we need to do anything "official" to define this namespace? Once #44 is approved, someone want to take up defining the POD namespace elements?

[jpmckinney]

Nothing special needs to be done: you simply need to publish a vocabulary/ontology at a stable URL.

In terms of prefixes like foaf or dct, or in this case pod, it's usually good form to recommend a prefix that doesn't conflict with popular prefixes, but it's not a problem if there is a conflict. Prefixes always need to be defined by the publisher in each document, e.g. an RDF document needs to declare that dct means http://purl.org/dc/terms/ so that when it later refers to properties like dct:language, a consumer is able to expand the compact URI to the full http://purl.org/dc/terms/language.

[jpmckinney]

This seems to be continued in #136, in which case I guess this issue can be closed.

[haleyvandyck]

yes-- closing this to finish conversation on #136. Thanks @jpmckinney