Re: [dxwg] Distribution service [RDISV]

Thanks for your comments, @fellahst . Please see my replies inline.

> [...] I think both approaches are very similar and probably hint that both approaches are on the right track (passing the Test of Independent Invention). [...]

I was thinking the same :smile:

> In UC20, you model catalog service as dcat:Catalog. This seems very weird to me. In my mind, a catalog is a collection of items, not a service. The DCAT specification defines dcat:Catalog as "a curated collection of metadata about datasets". A Catalog service provides an API that manages one or more catalogs, provides search, harvesting, indexing functions for example. Convoluting both notions (Catalog and CatalogService) will cause problems in modeling relationships between CatalogService and Catalogs.
> An OGC Catalog Service (CSW) should be modeled as a dct:Service with dct:type Catalog and dct:conformsTo OGCCatalogSpec.

I agree that `dcat:Catalog`, in the DCAT 1.0, makes no reference to the notion of service - and actually I made a comment along these lines in https://github.com/w3c/dxwg/issues/172#issuecomment-376229475 , where I mention use cases I'm aware of where it is simply used as a way of grouping datasets based on some criteria (e.g., the datasets produced by a project/activity).

However, I'm also aware of use cases (leaving aside the GeoDCAT-AP approach) where `dcat:Catalog` is used to denote catalogue services (I used this term in its general sense: an endpoint from which you can get a set of metadata records).

Said that, using `dcat:Catalog` to cover both cases may be confusing, as you note. An option could be to (strong) type a catalogue service with both `dcat:Catalog` and `dctype:Service`:

````turtle
a:CatalogService a dcat:Catalog , dctype:Service .
````

This could also be a possible solution to the issue I raised in https://github.com/w3c/dxwg/issues/172#issuecomment-376229475 about making `dcat:Catalog` a subclass of `dctype:Service`.

> To model relationships between Service and other items (Dataset, Layer, Map, etc..), we borrowed the terms used in ISO 19115 (operatesOn and servicedBy). However, we generalized the range of operatesOn to be srim:Item (which is superclass of dcat:Dataset), so we can refer to other types of assets such as Layer or Map. I strongly recommend we introduce a superclass of dcat:Dataset to accommodate this case (may be sioc:Item).

I think a class more general than `dcat:Dataset` would indeed be useful, also for catalogues. This links to the issue about having metadata in a catalogue about resources which are not datasets - see also https://github.com/w3c/dxwg/issues/116#issuecomment-375817833.

On a different note, I would be interested to know if you considered defining a "layer" as a distribution of a dataset, and, in such a case, why you decided otherwise. Please note that I don't have any specific position on this issue - I'm just curious.

> My last comment about the modeling of query parameters. Personally, I do not like the suggestion of using an external document such as OSDD, because it makes the implementation of the client more complex for the following reasons:
>
> [snip]

I see your point, but an RDF-based approach may have other issues. 

In Geo/DCAT-AP, the assumption was that the catalogue platform used might not necessarily be natively based on RDF. So, the rationale behind using a fit-for-purpose language (as OpenSearch) to specify the query parameters was based on the idea that such "language" would be more easily interpreted by software agents, compared to an _ad hoc_ RDF representation. 

Said that, we might have overestimated this problem, and therefore we could re-visit our resolution. I wonder whether you could share some details on how you've implemented your approach.

BTW, another reason for looking into OpenSearch was related to the work at OGC to extend it to support requirements of OGC services - see http://www.opengeospatial.org/standards/opensearchgeo and http://www.opengeospatial.org/standards/opensearch-eo

> While we should try to accommodate the different type of service implementation (REST, SOAP, RPC), we should consider that RESTful APIs constitutes the majority of service APIs out there, so the spec should make it trivial and easy to access these services.

This could be indeed a possible way forward. My concern is whether defining how this should be done in DCAT could be out of scope of DXWG. If we opt for an RDF-based solution, this seems like something to be addressed by a specific vocabulary.

-- 
GitHub Notification of comment by andrea-perego
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/56#issuecomment-376322225 using your GitHub account

Received on Monday, 26 March 2018 21:44:39 UTC