Re: [dxwg] Distribution service [RDISV]

@andrea-perego  Thank you so much for taking the time to compare the GeoDCAT-AP approach with the Geoplatform one. 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 have a couple of comments and disagreement with the references you gave.

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 think that using dct:Service to model service is fine.  For some reason, I miss this term from DC Terms and I introduced the concept in  SRIM namespace. I would agree that dct:Service is totally appropriate. I would probably update the spec to make the alignment. 

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).  

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: 1) because it requires an out of band call to get this document 2) because it requires parsing the document in a different format than RDF.  
The RDF parameter model we used in Geoplatform, maps almost one to one OSDD model (we may need to add additional properties to fill the gap such as pattern). The benefits of this approach are: 
1) we remain in-band and clients have access to all information to perform the request to the service 
2) the model is semantic (this agnostic to implementation) and the information about accessURL (including url template), parameters,  the type of service (dct:type) and standard (dct:conformsTo) should be sufficient for a client to know how to build the appropriate query to the service. 
3) it is more or less aligned with the ISO 19119 standard.  In ISO 19119,  services are abstracted as a set of Operations with Parameters and DCP (Distributed Computing Platform) verbs. This abstraction should be sufficient to model any types of service implementation. 

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.




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

Received on Monday, 26 March 2018 15:04:17 UTC