Metadata on resource level

[nicky508]

Encoding metadata in chapter 10, describes that a dataset should have meta data on the dataset using geodcat. However, we have a cadastral dataset which contains mutations on resource level The history of mutations is in the data. How should be encode this?

[andrea-perego]

@nicky508 , could you please provide an example of how this information is encoded in metadata records?

[nicky508]

At this moment, it is done using prov-o ontology.

I attached a image to give a clear idea of the data. In the Image you see 3 mutations of a building status. with the start date and the end date of the building. At this moment we use prov-o to convert the mutation data. Since we use RDF it is offcourse not mandatory for everybody. But if more people struggle with this question it would probably a valueble addition to the guideliness.

[andrea-perego]

Thanks, @nicky508 . If I understand correctly, since the ID is always the same, what you record are changes in the "status" of the building (or, better, based on my very limited knowledge of Dutch, of the "property"). Could you provide also the RDF representation, to see how you model this with PROV?

About your question on GeoDCAT-AP, this is indeed not an information that is supposed to be encoded there, since it is about a "data item" (a building) and not about the dataset as a whole. Possibly, a GeoDCAT-AP record could be complemented with some "statistical" information on the dataset, as the number of features (buildings), encoded, e.g., by using VoID, that could be automatically derived via a SPARQL CONSTRUCT query.

[nicky508]

True, the dataset describes properties. This turtle representation, represents one property:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix ns1: <http://www.opengis.net/ont/geosparql#>. @prefix ns2: <http://bag.basisregistraties.overheid.nl/def/bag#>. @prefix n1: <http://bag.basisregistraties.overheid.nl/bag/id/pand/>. n1:0758100000104471 rdf:type ns1:Feature; rdf:type ns2:Pand; rdfs:label "Pand 0758100000104471"@nl; rdfs:isDefinedBy <http://bag.basisregistraties.overheid.nl/bag/doc/2014102100000000/pand/0758100000104471>; rdfs:isDefinedBy <http://bag.basisregistraties.overheid.nl/bag/doc/2015042000000000/pand/0758100000104471>; rdfs:isDefinedBy <http://bag.basisregistraties.overheid.nl/bag/doc/2016102600000000/pand/0758100000104471>; ns1:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/6F21B6E0100BB983BE7E9C65825E915E>; ns2:identificatiecode "0758100000104471"^^xsd:string; ns2:status <http://bag.basisregistraties.overheid.nl/id/begrip/PandInGebruik_nietIngemeten>; ns2:status <http://bag.basisregistraties.overheid.nl/id/begrip/BouwvergunningVerleend>; ns2:status <http://bag.basisregistraties.overheid.nl/id/begrip/BouwGestart>; ns2:oorspronkelijkBouwjaar 2015; ns2:oorspronkelijkBouwjaar 2016; ns2:geometriePand <http://bag.basisregistraties.overheid.nl/bag/id/geometry/6F21B6E0100BB983BE7E9C65825E915E>

This property is multiple times defined by a uri. This definedBy uri`s a prov:Entities. One of this definedBy resources is:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix ns1: <http://bag.basisregistraties.overheid.nl/def/bag#>. @prefix prov: <http://www.w3.org/ns/prov#>. @prefix n1: <http://bag.basisregistraties.overheid.nl/bag/doc/2014102100000000/pand/>. n1:0758100000104471 rdf:type ns1:Voorkomen; rdf:type prov:Entity; rdf:type <http://www.w3.org/ns/sparql-service-description#Graph>; rdfs:label "Voorkomen Pand 0758100000104471 van 2014-10-21"@nl; ns1:geconstateerd false; ns1:aanduidingInactief false; ns1:beginGeldigheid "2014-10-21T00:00:00.000Z"^^xsd:dateTime; ns1:inOnderzoek false; ns1:aanduidingCorrectie 0; ns1:bron <http://bag.basisregistraties.overheid.nl/bag/id/brondocument/2014_1648>; prov:wasDerivedFrom <http://bag.basisregistraties.overheid.nl/bag/id/brondocument/2014_1648>; ns1:eindGeldigheid "2015-04-20T00:00:00.000Z"^^xsd:dateTime

Which describes the mutation of status.

[semanticfire]

I think the essential question is what metadata encoding will we use, there are various best practices on resource level metadata and their vocabulaires e.g. PROV and DCTERMS. To me it would make sense to research which model works best for INSPIRE data and then document that in the guidelines.

[jechterhoff]

The status of the feature changes, and the status is a property of the feature? That looks like the spatial object changes its state through time. If so, this is related to the topic of spatial object life-cycle (see the INSPIRE Generic Conceptual Model, chapter 9.7).

The draft base ontology defines the properties base:beginLifespanVersion and base:endLifespanversion, which would support the encoding of different versions of a feature. However, as the generic conceptual model states this topic needs further work.

Are there any best practices from the RDF community to deal with changes of resource state through time?

[cportele]

INSPIRE features often have three properties that are feature metadata:

• inspireId - not included in the RDF vocabularies as the feature URI is that identifier
• beginLifespanVersion / endLifespanVersion - included as properties of the feature

In the Dutch approach, the begin/end properties are not properties of the feature, but properties of an associated prov:Entity (ns1:beginGeldigheid / ns1:eindGeldigheid). If only the feature metadata changes, a new prov:Entity is added and the begin/end properties of the metadata entities are set.

In INSPIRE, if only the begin/end properties are maintained as feature metadata then having a separate prov:Entity just for the timestamps seems a bit much? If additional feature metadata is maintained (even if not discussed in the INSPIRE data specifications), would a separate prov:Entity for the feature metadata add value?

In the Dutch approach, it is not clear to me why ns1:beginGeldigheid / ns1:eindGeldigheid are used and not prov:generatedAtTime / prov:invalidatedAtTime.

[semanticfire]

I have the same questions regarding the Dutch approach, but from your comment I see that actually using PROV as a default metadata standard on feature level would be a smart choice