Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example of catalogued service #237

Closed
andrea-perego opened this issue May 17, 2018 · 13 comments
Closed

Example of catalogued service #237

andrea-perego opened this issue May 17, 2018 · 13 comments
Labels

Comments

@andrea-perego
Copy link
Contributor

@andrea-perego andrea-perego commented May 17, 2018

As per ACTION-117.

I include herebelow a full example of a metadata record for a service, as it is done in GeoDCAT-AP.

The example include:

  1. The catalogue containing the service record
  2. The record for the service
  3. The corresponding catalogue record
  4. The source ISO 19119 record, from which the catalogue record at point (3) has been derived

NB: dcat:contactPoint is used in the example following the revision in the current DCAT draft, which has relaxed the domain restriction of this property.

# The catalog  containing the service record
a:Catalog a dcat:Catalog ;
  dcat:record :EEA-CSW-Endpoint-Record ;
  dcterms:hasPart :EEA-CSW-Endpoint .

# The GeoDCAT-AP catalog record about the EEA CSW public endpoint (a service)
  
:EEA-CSW-Endpoint-Record a dcat:CatalogRecord ;
  foaf:primaryTopic :EEA-CSW-Endpoint .
  dcterms:language <http://publications.europa.eu/resource/authority/language/ENG> ;
  dcterms:modified "2012-05-21"^^xsd:date ;
  dcat:contactPoint :EEA ;
  dcterms:identifier "4be5cb08-e082-426a-9c57-8a53d7cd3f65"^^xsd:string ;
  dcterms:conformsTo <http://data.europa.eu/930>
  dcterms:source :EEA-CSW-Endpoint-SourceRecord ;
  
# The ISO 19119 record from which the GeoDCAT-AP catalog record has been derived

:EEA-CSW-Endpoint-SourceRecord dcterms:conformsTo <http://www.isotc211.org/2005/gmd> .

# The EEA CSW public endpoint

:EEA-CSW-Endpoint a dctype:Service, dcat:Catalog ;
# The resource + service type, using the relevant ISO 19115/19 code lists
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service>, 
    <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/discovery> ;
  dcterms:title "European Environment Agency's public catalogue of spatial datasets."@en ;
  dcterms:description "The EEA public catalogue of spatial datasets references the spatial datasets used by the European Environment Agency as well as the spatial datasets produced by or for the EEA. In the latter case, when datasets are publicly available, a link to the location from where they can be downloaded is included in the dataset's metadata. The catalogue has been initially populated with the most important spatial datasets already available on the data&maps section of the EEA website and is currently updated with any newly published spatial dataset."@en ;
# This corresponds to the ISO 19119 code list of classification of spatial data services
  dc:subject "infoCatalogueService"@en ;
  dcterms:identifier "eea-sdi-public-catalogue"^^xsd:string ;
  dcterms:spatial [ 
    a dct:Location ;
    locn:geometry 
      "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral, 
      "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral 
  ] ;
  dcterms:issued "2012-01-01"^^xsd:date ;
# The service conforms to the CSW specification  
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;
# @dr-shorthair, this URL corresponds in ISO 19119 to srv:connectPoint :  
  foaf:page <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
  dcterms:license <https://creativecommons.org/licenses/by/2.5/dk/> ;
  dcterms:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
  dcat:contactPoint :EEA .

# The point of contact for both the catalog record and the service  
  
:EEA a vcard:Organization ;
  vcard:organization-name "European Environment Agency"@en ;
  vcard:hasEmail <mailto:info@eea.europa.eu> ;
  vcard:hasURL <http://www.eea.europa.eu> .
@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 18, 2018

How's this? Apart from using the proposed DCAT for services predicates, I made two significant changes:

  1. The EEA catalog endpoint is a dcat:DiscoveryService (and thus is both a dcat:Catalog and a dcat:DataService). Not sure if the former actually applies though.
  2. I replaced your URI for the service with its actual URI.

The second point will clearly need a discussion. In @andrea-perego's original (above) the service-description has a separate URI. I'm suggesting that the actual URI could be used, since the descriptor properties really are associated with that thing. I also added a new proposed property dcat:endPoint which is kinda comparable to the dcat:Distribution/dcat:accessURL property - it is redundant in this case, but is better than foaf:page if we revert to some kind of intermediate resource.

# The catalog  containing the service record

:MyCatalog a dcat:Catalog ;
  dcat:record :EEA-CSW-Endpoint-Record ;
  dcat:service <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
.

# The EEA CSW public endpoint

<http://sdi.eea.europa.eu/catalogue/srv/eng/csw> a dcat:DiscoveryService ;
  dc:subject "infoCatalogueService"@en ;
  dcterms:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;
  dcterms:description "The EEA public catalogue of spatial datasets references the spatial datasets used by the European Environment Agency as well as the spatial datasets produced by or for the EEA. In the latter case, when datasets are publicly available, a link to the location from where they can be downloaded is included in the dataset's metadata. The catalogue has been initially populated with the most important spatial datasets already available on the data&maps section of the EEA website and is currently updated with any newly published spatial dataset."@en ;
  dcterms:identifier "eea-sdi-public-catalogue" ;
  dcterms:issued "2012-01-01"^^xsd:date ;
  dcterms:license <https://creativecommons.org/licenses/by/2.5/dk/> ;
  dcterms:spatial [
      a dcterms:Location ;
      locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ;
      locn:geometry "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral ;
    ] ;
  dcterms:title "European Environment Agency's public catalogue of spatial datasets."@en ;
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service> ;
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/discovery> ;
  dcat:contactPoint :EEA ;
  dcat:endPoint <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
.

# The record about the EEA CSW public endpoint (a service)

:EEA-CSW-Endpoint-Record a dcat:CatalogRecord ;
  dcterms:conformsTo <http://data.europa.eu/930> ;
  dcterms:identifier "4be5cb08-e082-426a-9c57-8a53d7cd3f65" ;
  dcterms:language <http://publications.europa.eu/resource/authority/language/ENG> ;
  dcterms:modified "2012-05-21"^^xsd:date ;
  dcterms:source :EEA-CSW-Endpoint-SourceRecord ;
  dcat:contactPoint :EEA ;
  foaf:primaryTopic <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
.

# The ISO 19119 record from which the GeoDCAT-AP catalog record has been derived

:EEA-CSW-Endpoint-SourceRecord
  dcterms:conformsTo <http://www.isotc211.org/2005/gmd> ;
.

# The point of contact for both the catalog record and the service
  
:EEA a foaf:Organization ;
  vcard:hasEmail <mailto:info@eea.europa.eu> ;
  vcard:hasURL <http://www.eea.europa.eu> ;
  vcard:organization-name "European Environment Agency"@en ;
.
@jakubklimek

This comment has been minimized.

Copy link
Contributor

@jakubklimek jakubklimek commented May 18, 2018

@dr-shorthair Regarding your point 2, I would not do that. This would make the DCAT description of the service not dereferencable, e.g. in a catalog data browsing tool.

A more generic point: Is a machine readable description of service parameters and capabilities going to be included? E.g. a link to a WSDL or WADL document, a SPARQL Service Description document, etc.?

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 18, 2018

And regarding my point 1. - I'm now thinking that, if a dcat:Catalog is a kind of dcat:Dataset, then a dcat:DiscoveryService is not a sub-class of dcat:Catalog, but rather can serve distributions or subsets of a dcat:Catalog, as a specialized kind of dcat:DataDistributionService.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 18, 2018

The (machine readable) description of the service endpoint probably comes in several parts

  1. the generic signature through the dct:conformsTo link
  2. content description through the dcat:servesDataset link
  3. yeah, need another property for specific service parameters. OGC getCapabilities response would fit here too.
@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 18, 2018

Back to point 2: @jakubklimek I follow your logic. But in that case the class names are misleading. More strictly they should be dcat:DatasetDescription and dcat:DataServiceDescription.

Now that is probably too much of a mouthful (and the horse has long since bolted on dcat:Dataset). But perhaps the class definitions should be updated to say quite clearly that these are descriptions of the corresponding things.

(It also clarifies why dcat:endPoint rather than owl:sameAs.)

@jakubklimek

This comment has been minimized.

Copy link
Contributor

@jakubklimek jakubklimek commented May 18, 2018

@dr-shorthair I agree completely, that its also the approach taken by the Solid community, can be seen e.g. in the WebID specification - the Information resource is the document and the real world resource is denoted by a hash IRI, connected to the document via foaf:primaryTopic or something like that. e.g.

ex:dataset a dcat:DatasetDescription ;
    foaf:primaryTopic <https://ex.org/resource/dataset#i>

On the other hand, this would add another level of "meta", since there is also the dcat:CatalogRecord describing the entry in the catalog.

Nevertheless, the question is what can/should be done about it now. This would mean basically to move most of the properties from dcat:Dataset to dcat:DatasetDescription, creating incompatibility with DCAT 2014.

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

@andrea-perego andrea-perego commented May 18, 2018

Thanks, @dr-shorthair , for the revised example.

My comments below:

  1. I'm happy with using dcat:DiscoveryService for the moment, modulo the ongoing discussion on whether we are going to model service types by defining specific subclasses, or rather by using another approach (as dct:type).

  2. I see your point on dcat:Catalog - if a service is not a dataset and a catalogue is a dataset, a service cannot be a catalogue. However, one thing could be both, depending on how you look at it: it can be seen either as a curated collection of datasets or the service giving access to them. And actually this is normally the case for data catalogues: they have a curated collection of datasets, exposed via a number of service interfaces (including the human-oriented ones).

  3. About the service URI, I was tempted when I started drafting the example to use it, but then I started thinking whether it was appropriate. Does the URL of the service endpoint (always) correspond to the service URI? I don't have yet the answer, so I preferred to use a placeholder. I think we need to be careful here, as the example can be taken as an implicit statement about their identity. BTW, following from point (2), probably the URI should be the one of the EEA catalogue: https://sdi.eea.europa.eu/catalogue

  4. Thanks for proposing property dcat:endPoint. I was looking around to see the terminology used in existing vocabularies (as VoID or SD) to get some "inspiration". Taking on board @jakubklimek's point on a property for the service description/capabilities (thanks, @jakubklimek ), I was thinking that we can rename dcat:endPoint into dcat:endpointURL, and dcat:endpointDescription can be the property pointing to the service capabilities.

  5. About the service description/capabilities, the idea we discussed is that this will be linked to by using the URL of the OGC capabilities (WSDL, OpenSearch, OpenAPI, SD, etc.) document. However, I wonder whether we should leave the door open to other options (e.g., by adding a placeholder class dcat:EndpointDescription). On this, I would be keen to know @fellahst's opinion - we had an interesting discussion on this issue in #56 , and @fellahst mentioned that Geoplatform.gov decided to specify the service description in RDF, and directly into the metadata record.

Looking forward to your feedback.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 21, 2018

  1. Concerning service class specialization:
  • The case against is (i) unnecessary proliferation of classes in DCAT, perhaps in a too-deep subsumption hierarchy (ii) lack of completeness (which might be managed more easily using an extensible list of types to appear as value of dct:type).

  • The case for is (i) we already know a lot about 2 or 3 types (discovery, portrayal, download), the first and last of which are pretty central to a data cataloguing system (ii) at least for DataDistributionService it has some properties and associations that other services don't. So if we are primarily modeling using RDFS with a bit of OWL then we need classes to attach the axioms to. If we model using a shapes language, then we will need a shape for every different class anyway. So I lean towards including the ones we knwo about, and making it clear that this is not intended to be an exhaustive set.

  1. AFAICT according to the current usage an individual dcat:Catalog is essentially a list of datasets and catalog-records - i.e. it is itself a kind of 'dataset', as discussed at the last telecon. That probably means that a DiscoveryService might be considered to be (i) a specialization of DataDistributionService where the dataset served is a catalog, (ii) and possibly something else as well.
@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented May 21, 2018

@jakubklimek - regarding too many meta-levels:

I don't think that CatalogRecord is a problem. It is the registration record i.e. when the item was catalogued and by whom, perhaps current status. It is quite appropriate that this is separated from the content of the record itself, since the latter might have been submitted by anyone, any time, and might also be found in other catalogs with same content but different registration information.

@jakubklimek

This comment has been minimized.

Copy link
Contributor

@jakubklimek jakubklimek commented May 22, 2018

@dr-shorthair Yes, I agree that CatalogRecord is fine and necessary. The key will be in good documentation and good examples.

@agbeltran

This comment has been minimized.

Copy link
Member

@agbeltran agbeltran commented May 24, 2018

Considering this discussion, and the addition of a property dcat:endpoint, should we consider a mapping to the SD vocabulary?

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

@andrea-perego andrea-perego commented May 25, 2018

@agbeltran said:

Considering this discussion, and the addition of a property dcat:endpoint, should we consider a mapping to the SD vocabulary?

It might be considered as a super-property of sd:endpoint, but I don't think it is necessary/useful to make this explicit (at least, not in this phase, as the semantics of dcat:endpoint might slightly change).

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented Aug 8, 2018

I think this issue can be closed as it was tied to #56 which was closed through #241

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.