Comments (15)
Thanks, @AntoRot .
RDF vocabulary and specification updated via PR #54
PROPOSED RESOLUTION: Implement these changes in the current draft with the purpose of supporting the DQV approach for spatial resolution in version 2 of GeoDCAT-AP
from geodcat-ap.
Revisions applied, and final editorial fixes and revision completed.
With 1 positive vote and no negative vote, the proposed resolution can be considered approved.
I'm going to merge PR #54 and close this issue.
@AntoRot , @riccardoAlbertoni , thanks for your contributions.
from geodcat-ap.
The section 6.13 in the Data Quality Vocabulary (DQV) provides some examples on how spatialResolutionAsEquivalentScale
and spatialResolutionAsAngularDistance
can be expressed using the properties defined in that vocabulary.
That approach can be adopted without defining additional properties. DCAT-AP itself suggests to use DQV for describing spatial precision, accuracy, resolution and other statistics.
from geodcat-ap.
Thanks, @AntoRot .
Actually, the proposal of using DQV was the original one in #3 , where also some possible issues are summarised. Please note, however, that this will still require the definition of new terms.
I'll try to summarise below how to use DQV, so we could better compare it with the idea of extending DCAT2. BTW, for this discussion, it would be worth also looking at w3c/dxwg#84 , which gives the background behind the decision of defining dcat:spatialResolutionInMeters
.
As explained in #3
[...] DQV models this information as observations / measurements of a given quality metric (which corresponds to a given type of resolution).
[...]
This would however require the definition of two groups of individuals:
- Those corresponding to the different types of resolution (denoting a quality metric).
- Those corresponding to each of the different levels of resolution (denoting the measurement of a specific quality metric).
About the first group, they could be defined (in the GeoDCAT-AP namespace) as follows:
:SpatialResolutionAsEquivalentScale a dqv:Metric;
skos:prefLabel "Spatial resolution as equivalent scale"@en ;
skos:definition "Spatial resolution expressed as equivalent scale, by using a representative fraction (e.g., 1:1,000, 1:1,000,000)."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
:SpatialResolutionAsDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as distance"@en ;
skos:definition "Spatial resolution expressed as distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
:SpatialResolutionAsHorizontalGroundDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as horizontal ground distance"@en ;
skos:definition "Spatial resolution expressed as horizontal ground distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
:SpatialResolutionAsVerticalDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as vertical distance"@en ;
skos:definition "Spatial resolution expressed as vertical distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
:SpatialResolutionAsAngularDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as angular distance"@en ;
skos:definition "Spatial resolution expressed as angular distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
The second group of individuals could be instead defined in each metadata record.
The resulting specification of spatial resolution in a metadata record could be something like:
my:dataset a dcat:Dataset;
dqv:hasQualityMeasurement [ a dqv:QualityMeasurement ;
dqv:isMeasurementOf :SpatialResolutionAsEquivalentScale ;
dqv:value "0.000001"^^xsd:decimal
] ;
.
your:dataset a dcat:Dataset;
dqv:hasQualityMeasurement [ a dqv:QualityMeasurement ;
dqv:isMeasurementOf :SpatialResolutionAsDistance ;
dqv:value "1000"^^xsd:decimal ;
sdmx-attribute:unitMeasure <http://www.wurvoc.org/vocabularies/om-1.8/metre>
] ;
.
So, should we go for DQV or extend DCAT2?
from geodcat-ap.
I continue to prefer the option to use the DQV properties. In both approaches the first group of individuals should be defined anyway altough in a different way, but in case of DQV an existing solution would be reused, although more complex.
On the other side, defining the new properties as extension of DCAT2 would offer a simplest way to express the resolution.
In any case, as GeoDCAT-AP covers ISO core and INSPIRE metadata, only the corresponding property (i.e. SpatialResolutionAsEquivalentScale
in addition to dcat:spatialResolutionInMeters
already available) could be defined.
from geodcat-ap.
Thanks, @AntoRot .
Actually, although complex, the DQV-based solution provides a common pattern which makes it easier querying metadata compared with having distinct properties for each spatial resolution type. Moreover, it is more sustainable, as it allows a consistent definition of additional types of spatial resolution, if need be.
There are also a couple of other aspects in favour of DQV:
-
The two approaches are not mutually exclusive, and they could be mapped to each other
-
As you said earlier, @AntoRot , the use of DQV is recommended in DCAT. Moreover, DCAT may eventually extend support for other types of spatial resolution in its next version - see w3c/dxwg#1263 & w3c/dxwg#1266 . So, DQV might be a safer option for the moment
Based on that, I would propose to go for DQV, and consolidate the draft definitions in #15 (comment)
from geodcat-ap.
So, trying to consolidate the definitions:
- Should we merge these two into one?
:SpatialResolutionAsDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as distance"@en ;
skos:definition "Spatial resolution expressed as distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
:SpatialResolutionAsHorizontalGroundDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as horizontal ground distance"@en ;
skos:definition "Spatial resolution expressed as horizontal ground distance."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
from geodcat-ap.
In ISO 19115 "distance" is simply defined as "ground sample distance", that becomes "horizontal ground sample distance" in ISO 19115-1. This rewording I think was justified in order to distinguish it from the new metadata elements introduced in the latest version of the Standard, i.e. "vertical" and "angularDistance" and consequently the two elements match, also because it was not included as revision in the Annex G.
Consequently, I think that we should merge the two properties.
Concerning the definition of the first group of individuals you proposed in your earlier comment, seen the reasoning made in #23 about keeping properties mapped to elements coming from ISO 19115-1 not covered by the GeoDCAT-AP mappings, no objections to also add the properties corresponding to ISO 19115-1 metadata elements mentioned above, contrary to what I said in the previous comment.
from geodcat-ap.
Thanks, @AntoRot .
So, maybe we can just extend the first one with some additional textual explanation:
:SpatialResolutionAsDistance a dqv:Metric;
skos:prefLabel "Spatial resolution as distance"@en ;
skos:definition """Spatial resolution expressed as distance. It corresponds to the notion of spatial resolution as
"ground distance" of ISO 19115:2003 and "horizontal ground distance" of ISO 19115-1:2014."""@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension dqv:precision .
WDYT?
from geodcat-ap.
Another point:
- Are you happy with the textual descriptions of these individuals? Is there anything you think should be added / revised?
from geodcat-ap.
I created a full definition in PR #54
Please check it out.
@riccardoAlbertoni , as you are co-editor of DQV, it would be great if you could kindly review this work, and let us know if there's anything wrong and/or to be improved. Thanks!
from geodcat-ap.
@andrea-perego I think that the textual descriptions of both SpatialResolutionAsDistance
and other individuals are fine.
Thanks.
from geodcat-ap.
I created a full definition in PR #54
Please check it out.
@riccardoAlbertoni , as you are co-editor of DQV, it would be great if you could kindly review this work, and let us know if there's anything wrong and/or to be improved. Thanks!
@andrea-perego: Thank you for pointing to me the use of DQV into GeoDCAT-AP. I have given a quick read to it. The overall approach seems consistent with the DQV; I suggested some very minor changes in the related PR. I might not be fully aware of the whole context, so please feel free to ignore my rephasings if they do not apply to that specific context.
from geodcat-ap.
Many thanks for your review, @riccardoAlbertoni . Much appreciated.
I applied most of your suggested revisions, and left a comment for other ones, proposing a different revision.
from geodcat-ap.
Many thanks for your review, @riccardoAlbertoni . Much appreciated.
I applied most of your suggested revisions, and left a comment for other ones, proposing a different revision.
Thanks, it works for me.
from geodcat-ap.
Related Issues (20)
- Relation of various Agent classes used throughout the specification
- Revise usage of Licenses and Rights HOT 2
- DataService protocol mapped to `dct:conformsTo`
- Dataservice protocol list HOT 3
- Info: licenses in Flanders
- Access rights codelist issue
- Shared codelist for spatial concepts
- Format Publications Office HOT 1
- Info: on distribution / dataservice mapping rules HOT 1
- Info: entity conformity
- Info: mapping lineage statements
- pitfalls for metadata providers regarding expected mapping of distributions , digitaltransfers from ISO19115/19139 metadata to GeoDCAT-AP HOT 1
- Mapping of ISO metadata datestamp to DCAT HOT 4
- Mapping ISO dates to GeoDCAT-AP HOT 1
- The representation of the spatialResolution should be clearer specified and explained HOT 6
- The new GeoDCAT-AP should be defined as profile of the upcoming OGC GeoDCAT Specification HOT 2
- Mapping of metadataStandardName HOT 1
- applicableLegislationrequired for geospatial HVD´s HOT 1
- Typo in Usage note of Catalogued Resource - Catalogued Record HOT 1
- Catalogue Record: Attribute source metadata should be specified in more detail HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geodcat-ap.