Re: [dxwg] Definition of dcat:spatialResolutionInMeters incompatible/problematic with JSON-LD (#1536)

If we take @pchampin idea of defining range to be xsd:double or xsd:decimal then implementations can choose which they need - and a note saying E notation should not be used in xsd:decimal to be strictly compliant makes sense.  Either that or make just a xsd:double - there is not enough information supported by other DCAT property semantics for the precision to matter much I suspect:  spatial resolution is a complex thing depending on all sorts of map project issues - and the subtle differences with number precision would be lost in, for example, the issues of plate tectonic shift (some jurisdictions use dynamic datums with temporal epochs). "Effective spatial resolution" would need to be calculated anyway depending on map projection of the data, view angles of sensors and all sorts of things, and maybe an approximation to start with.

So the real solution for precision would be to fix this in GeoDCAT  - allowing core DCAT to provide "general statements" and GeoDCAT be rich enough to have all the other information you would need to make the fine distinction.  Syntactic interoperability matters most for core DCAT as the semantics probably dont allow more precise information regardless of syntactic precision preservation - so xsd:double might be easiest? 


SHACL constraints are probably going to be more practical use than OWL or RDFS - AFIACT very little OWL reasoning is done dynamically in the sort of environments concerned with data cataloging - DCAT doestn't really support rich enough description to support much meaningful reasoning - you would need to attach other data with relevant information models for most interesting cases anyway. 

GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 31 October 2022 21:58:57 UTC