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

@rob-metalinkage @andrea-perego thank you for your responses. This clarifies a a lot, that  also helps me refine my own comment here.


tldr: 
my feedback comes down to 2 things:

- Why are properties like dcat:bbox and dcat:centroid here in the first place? Does it really add to the functionality of data cataloging and if so, shouldn't we reuse one of the many other ways in which this relationship has been defined in other vocabularies?
- If we decided that it indeed belongs here: can we model these constructs in a way that is more aligned (in terms of uri, labels,  definition, admittedly purely aesthetic conventions) with the rest of the dcat, where labels/uri's typically hint at the intent of the relationship as supposed to the kind of information structure we expect in the range



in more detail (and reverse order ;-)):

1.a) I see that the argument here is that the exact meaning can be derived from the domain and the range. Fair enough, that is indeed one of the strengths of owl. I am still worried about possible misinterpretations, and i think a more elaborate definition could go a long way ( right now it says "The geographic bounding box of a resource." see also next point) 

1.b) About the naming of the dcat:bbox attribute (and upon further reading, the same can  be said for dcat:centroid): When making a semantic model, we aim to give a clear name (label, uri) to any rdf:property (be it a datatype property or an object property) that references the meaning or significance of the relationship. To take an example of where this is obviously done right: In rdf schema there are multiple relationships between rdf:Property  and rdfs:Resource. We have rdfs:domain and rdfs:range. We untuitively understand that just because we have  a relationship that points from something of type Property to something of type Resource, that we can just call this relationship rdfs:resource. We give the propertie(s) clear names (and uri's) that tell us something about what we mean by them. But I feel here we make that exact mistake. By defining dcat:bbox (even if you say its a literal because it can be any technical serialization of a bounding box), 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. Alternative names for dcat:bbox (that I think say more about what we want know, or emphasize what we intend)  could be "dcat:occupiesPhysicalSpace" or something like that. This also leaves the option to use another way of representing this information. requiring it to be a (certain kind of) bbox, in my opinion, belongs to the realm of shacl (see also next point).

2.a) Taking a step back: why does dcat concern itself with bounding boxes (and centroids) in the first place?  Does the rather technical object definition of bbox really add, functionally speaking, to what dcat is trying to achieve in terms of how we communicate about our data catalogs and their resources? There are whole taxonomies of how to model geometries and shapes, some much more accurate than a bounding box (why would a swept solid represent this information any less accurately?), or , some less,  why pin it down on this one if what you really want to know is where the resource is physically located?

2.b) Is this relationship really different from geosparql hasGeometry? or a similar relationship in the Industry Foundation Classes? if so, why does this vocabulary have such unique requirements that it should define its own property for it, can't we just conform to the models that domain experts have made for shapes and geometries?  If not:  why not explicitly use one of those?



Hope this helps!





-- 
GitHub Notification of comment by JoepvanGenuchten
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1392#issuecomment-905386527 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 10:42:53 UTC