Metadata on resource level #32
Comments
|
@nicky508 , could you please provide an example of how this information is encoded in metadata records? |
|
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. |
|
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. |
|
True, the dataset describes properties. This turtle representation, represents one property:
This property is multiple times defined by a uri. This definedBy uri`s a prov:Entities. One of this definedBy resources is:
Which describes the mutation of status. |
|
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. |
|
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? |
|
INSPIRE features often have three properties that are feature metadata:
In the Dutch approach, the begin/end properties are not properties of the feature, but properties of an associated In INSPIRE, if only the begin/end properties are maintained as feature metadata then having a separate In the Dutch approach, it is not clear to me why |
|
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 |
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?
The text was updated successfully, but these errors were encountered: