-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alignment of QB4ST with DCAT-2 #1123
Comments
@dr-shorthair
Temporal In very simple terms, a time interval specified by two end-points, and a time interval specified by an end point and a duration, are not always equivalent. I am not sure whether this matters or is just me splitting theological temporal hairs. What does the DCAT community think? |
Indeed - generic DCAT is not the place for hair-splitting. There are many special and not-so special cases that cannot be handled by the proposed predicates (e.g. differing vertical and horizontal resolutions are almost ubiquitous). But we want to provide a basic solution that is good enough for 80%, simple enough to not alienate non-spatial/temporal practitioners, but without being meaningless. A rule-of-thumb is to avoid nesting structures until you have to. So, indeed, DQV would be the next step, but these were deemed good enough for now. I think I understand the point you are making about temporal, but again I'm not sure its really in scope for DCAT. The primary use-case is discovery. Temporal Coverage tells you which time interval the dataset relates to. Temporal Resolution tells you what the temporal granularity of points in the dataset are, so you can quickly judge if it might be fit for your purpose. Yeah, the interval might not be an integer multiple of the granules, but that's not really the issue. Or am I missing your point? |
@dr-shorthair: No, you are spot on. I was thinking about detailed processing, rather than initial discovery. |
might this best be done by providing a profile of DCAT for describing spatio-temporal aspects of data using QB4ST? under open world nothing stops these being used for QB4ST now. |
Just an addition to what @dr-shorthair reported: For spatial coverage, DCAT2 now includes additional properties for specifying geometries as bboxes and centroids. All the relevant properties are described in the following section: https://w3c.github.io/dxwg/dcat/#Class:Location As the lack of agreed RDF properties for bboxes and centroids has been an outstanding issue in SDWWG, feedback from SDWIG would be very much welcome. |
DCAT-2 has added a lightweight treatment of spatial- [1] and temporal-resolution [2] to the existing spatial- [3] and temporal-coverage (extent) [4] capability (which use the DC properties).
QB4ST should either re-use or provide a mapping to these - see Bounding Envelopes and Coordinate granularity.
[1] https://w3c.github.io/dxwg/dcat/#Property:dataset_spatialresolution
[2] https://w3c.github.io/dxwg/dcat/#Property:dataset_spatial
[3] https://w3c.github.io/dxwg/dcat/#Property:dataset_temporalresolution
[4] https://w3c.github.io/dxwg/dcat/#Property:dataset_temporal
The text was updated successfully, but these errors were encountered: