This group aims to point at research on Linked Data and to identify relations to and impacts on INSPIRE.

| Share
Group discussion > Alignment of INSPIRE metadata with DCAT-AP

Alignment of INSPIRE metadata with DCAT-AP

Andrea Perego
1038 days ago

Dear colleagues,

This is to let you know that a short report on the alignment of INSPIRE metadata with DCAT-AP has been published on the wiki of the INSPIRE Maintenance and Implementation Group (MIG):

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/Alignment_of_INSPIRE_metadata_with_DCAT-AP

This work is yet to be finalised, but we would like to use the INSPIRE Forum to collect preliminary feedback. So, your comments are more than welcome!

Thanks

-Andrea

PS: Please note that, to post comments, you have first to register / login to the INSPIRE Forum.

Permalink

Paul van Genuchten
1035 days ago

Hi Andrea, I've read the document. It's sure usefull. I've shared your posting in the Geonetwork Community and Dutch Linked Open Data Community, if any comments from that area I'll try to duplicate them here. At this moment in time I haven't found big issues in your approach. Some minor comments/thoughts; In your approach you're frequently pointing to concepts from the INSPIRE registry, for example topic category,ResourceType. These concepts originate from iso19139 / codelists.xml. Wouldn't it be better if the original iso19139-codelist-concepts were referenced, or if technologically challenging some vocabulary at ISO/OGC (if available)?

I understand in your example you use landingpage for the download-url, it would be interesting though to see if, for iso19139 documents having a wfs, you can directly link to that WFS while issuing a getfeature-request:

dcat:Distribution ;
dcat:downloadURL <http://example.org/wfs?request=getfeature&typename=xxx&format=gml> .
dcat:mediaType "application/xml"

I don't agree with the use of landingpage for a wms server. I'd suggest to remove the wms link if a wfs link is available. If no wfs/download available present the WMS link as
downloadurl, because apparantly a rasterised representation of the data is the only thing that is available (quite useless in the semantic web).

For @en, wouldn't it be better to use 'en-GB' ('dut' in iso is 'nl-nl', where 'vls' in iso is 'nl-be')

is there a way to add a link to the original iso19139 document from which this document was translated? Or a way to indicate that the document is also available in other encodings, like iso19139.

It seems (Phil Archer commented this) in the spatial community we use the rdf/xml encoding quite a lot, where this encoding seems hardly used outside the geo world. It would probably help if you (also) provide the dcat-ap examples in rdf/xml (although they can be easily translated using http://rdf-translator.appspot.com)

Hope this is helpfull, cheers Paul

Permalink

Andrea Perego
1032 days ago

Thanks a lot for your comments, Paul, and thanks also for sharing the message with other communities!

BTW, an updated version of the draft is likely to be posted online next week, taking into account the feedback we got so far. I'll let you know on this page as soon as it will be there.

Meanwhile, please find my replies below:

1. Code lists: The problem is that we don't have URI register for ISO code lists - and this is also one of the reasons why the INSPIRE Registry was set up. And the idea is to use global and possibly derefernceable IDs for code value, also following the DCAT-AP recommendations on controlled vocabularies.

2. Landing page vs download URL. I see your point, Paul. You know, dcat:landingPage is meant to map the INSPIRE notion of "resource locator", which may denote two different things: "the link(s) to the resource and/or the link to additional information about the resource." (quoting from the Metadata Regulation). The point is that, formally, we cannot say whether a resource locator is pointing or not to a download page. Of course, in some (very few) cases you can parse the URL string to find a meaningful pattern (as WFSs). It would be interesting to identify possible solutions to this issue, on the short and long term (e.g., the Metadata TG already recommends to "type" the resource locator, in order to denote which kind of resource it points to).

3. Language codes: Thanks for the suggestion of adding also the country code. However, as far as I know, there's no mapping between the ISO alpha-3 codes and the combination language code - country code as defined by IETF.

4. Examples in RDF/XML: Good point. I'll add them when the updated version of the draft is published. BTW, the original examples were in RDF/XML, and I used rdf-translator.appspot.com to generate the TTL version :)

Cheers,

-Andrea

 

Permalink

Andrea Perego
1004 days ago

Dear colleagues,

This is to let you know that we published today a new, extended version of the proposal for the alignment of INSPIRE metadata with DCAT-AP.

The proposal now includes three documents:

  • The specification concerning a "core" version of the INSPIRE profile of DCAT-AP, which includes only the subset of INSPIRE metadata elements supported in DCAT-AP
  • The specification of the "extended" version of the profile, which defines alignment for all INSPIRE metadata elements, re-using nonetheless the ones defined in the core profile (i.e., it's a superset of the core profile)
  • A reference document for the core and extended versions of the INSPIRE profile of DCAT-AP, discussing the alignments proposed for the individual INSPIRE metadata elements

The suite of documents is available from:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/Alignment_of_INSPIRE_metadata_with_DCAT-AP

Your comments are more than welcome!

Thanks!

-Andrea

Permalink

Simon Cox
989 days ago

I'll post here as the link to topic/29902 appears to be broken. 

I am concerned that a significant number of property ranges are specified as skos:Concept. In many cases, the valid values for a property would come from a controlled set, which is not captured. I would expect to see either 

(a) a constraint that the values should come from a specified set (maybe a skos:Collection, like http://def.seegrid.csiro.au/isotc211/iso19115/2003/code/Scope/

(b) a more specific type for each property range, capturing the local semantics. The specific type can be subClassOf skos:Concept. For example, see http://def.seegrid.csiro.au/isotc211/iso19115/2003/metadata#ScopeCode 

I guess you didn't go there yet, as these types would have to be in a new namespace, and you were deliberately limiting yourselves to existing namespaces at this stage. But curious if this pattern was planned? 

 

Permalink

Simon Cox
989 days ago

The ISO/TC 211 Ontology Management Group is planning to publish a set of OWL ontologies corresponding to the UML models in the ISO Harmonized Model, using the rules defined in ISO 19150-2 (currently in DIS, FDIS shortly). (The ontologies published at  http://def.seegrid.csiro.au/isotc211/ are effectively a sneak preview of what will be published at http://def.isotc211.org/ .) This provides URIs for OWL classes and properties corresponding to ISO 19115 Metadata. This representation could be used in a formal definition of the metadata-DCAT-AP mapping as OWL axioms and rules. 

Permalink

Andrea Perego
989 days ago

Hi, Simon.

I'll post here as the link to topic/29902 appears to be broken. 

Yes, this is the right place. Thanks a lot for reporting the broken link - now it has been fixed.

I am concerned that a significant number of property ranges are specified as skos:Concept. In many cases, the valid values for a property would come from a controlled set, which is not captured. I would expect to see either 

(a) a constraint that the values should come from a specified set (maybe a skos:Collection, like http://def.seegrid.csiro.au/isotc211/iso19115/2003/code/Scope/

(b) a more specific type for each property range, capturing the local semantics. The specific type can be subClassOf skos:Concept. For example, see http://def.seegrid.csiro.au/isotc211/iso19115/2003/metadata#ScopeCode 

I guess you didn't go there yet, as these types would have to be in a new namespace, and you were deliberately limiting yourselves to existing namespaces at this stage. But curious if this pattern was planned? 

Thanks for raising this point, Simon. Actually, for the moment, the recommended sets of skos:Concept's to be used is not formally specified, but they are listed in a separate section, titled "Reference code lists for metadata elements". The full list is in the INSPIRE+DCAT-AP Reference specification:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/INSPIRE_profile_of_DCAT-AP_-_Reference#Reference-code-lists-for-metadata-elements

By doing this, we adopted the same solution used in the DCAT and DCAT-AP specifications, where the domain and range of the same properties are not formally restricted on specific sets of skos:Concept's. Moreover, in this phase, we prefer to use loose specifications until the work is more consolidated.

Nonetheless, we need to address this issue soon, at least for validation purposes. I would be very interested to know your opinion on the possible methodologies to be used, and their pros and cons. E.g., I know that W3C is in the process of setting up a WG on RDF validation [1] (a workshop was also organised on this [2]). In my understanding, this kind of technology may be useful to effectively define how to use terms from existing vocabularies in a meta/data "profile", without locally modifying their original formal specification.

-Andrea

----

  1. http://www.w3.org/2014/data-shapes/charter
  2. http://www.w3.org/2012/12/rdf-val/
Permalink

Andrea Perego
989 days ago

The ISO/TC 211 Ontology Management Group is planning to publish a set of OWL ontologies corresponding to the UML models in the ISO Harmonized Model, using the rules defined in ISO 19150-2 (currently in DIS, FDIS shortly). (The ontologies published at  http://def.seegrid.csiro.au/isotc211/ are effectively a sneak preview of what will be published at http://def.isotc211.org/ .) This provides URIs for OWL classes and properties corresponding to ISO 19115 Metadata. This representation could be used in a formal definition of the metadata-DCAT-AP mapping as OWL axioms and rules. 

Thanks a lot, Simon. This can be definitely important for work concerning the alignment of the ISO-based encoding of INSPIRE metadata (as specified in the Technical Guidelines) with DCAT-AP. The current INSPIRE+DCAT-AP specifications focus instead on the "conceptual" representation of INSPIRE metadata, as defined in the INSPIRE Metadata Regulation [1]. So, strictly speaking, they are not about the alignment of ISO 19115 with DCAT-AP.

Said that, the definition of a standard mapping between ISO 19115 and vocabulaires as DCAT and VoID would be, IMHO, an important step forward the better integration and re-use of geospatial data in other domains. It may be worth to contribute such issues to relevant standardisation initiatives, as the W3C/OGC WG on Spatial Data on the Web [2] and the W3C Data on the Web Best Practices WG [3].

-Andrea

----

  1. http://eur-lex.europa.eu/eli/reg/com/2008/1205
  2. http://www.w3.org/2014/05/geo-charter
  3. http://www.w3.org/2013/dwbp/
Permalink