W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > August 2021

Re: [dxwg] semantics of the dcat:bbox attribute could (should?) be more explicit (#1392)

From: Andrea Perego via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Aug 2021 22:29:08 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-905918892-1629930547-sysbot+gh@w3.org>
@JoepvanGenuchten , 

About "why does dcat concern itself with bounding boxes (and centroids) in the first place?", you can find the background discussion in https://github.com/w3c/dxwg/issues/83 , which also links to the relevant use case in DXWG UCR document. Trying to summarise it:

The original version of DCAT did not provide guidance on how to specify the spatial coverage of a dataset by using geometries. Implementation experiences shew that this gap was raising interoperability issues, and therefore DCAT2 addresses it by supporting specific properties for the most typical cases - i.e., geometries, bounding boxes, and centroids.

The reason why specific properties for bounding boxes and centroids have been defined in the DCAT namespace was that there was no standard way of doing this - i.e., commonly used vocabularies, as the W3C Basic Geo and GeoSPARQL, don't have such properties (something that is instead being addressed in the new version of GeoSPARQL under development), with the exception of Schema.org (`schema:box`).

About your note at point 1.b:

> By defining dcat:bbox [...], we are basically saying (or at the very least implying): there is only 1 semantically meaningful relationship between dcat:Resource and any bounding box representation, and we are not very clear about what we mean by it.

Any suggestion on how to improve the description of `dcat:bbox` is more than welcome. However, as I said in https://github.com/w3c/dxwg/issues/1392#issuecomment-905022220 , `dcat:bbox` is just meant to specify the bounding box of a spatial thing, but it does not exclude other types of relationships between this thing and a bounding box. I gave the example of spatial coverage, but the same approach applies to any other type of relationship - e.g., a relationship as the one you give as an example (`:occupiesPhysicalSpace`) can be specified as follows:

a:Resource a dcat:Resource ;
  :occupiesPhysicalSpace [ a dcterms:Location ;
    dcat:bbox "POLYGON((...))"^^geosparql:wktLiteral
] .

I am not sure I answered to all your points, so please let me know whatever I missed. Also, it would be very useful if you could complement the issues you are highlighting with specific use cases and examples, so to better understand the possible weaknesses of the current DCAT approach in addressing your requirements.

GitHub Notification of comment by andrea-perego
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1392#issuecomment-905918892 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 August 2021 22:29:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:37 UTC