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

@JoepvanGenuchten , thanks for raising this issue.

I think there are two separate aspects here: one is about the range, and one about the actual semantics of this property.

1. About the range, what is generic is the literal encoding of the geometry (`rdfs:Literal`). In [the current draft of DCAT3]( we made a slight revision to clarify this point (see

    > The range of this property (`rdfs:Literal`) is intentionally generic, with the purpose of allowing different geometry literal encodings. E.g., the geometry could be encoded as a WKT literal (`geosparql:wktLiteral` [GeoSPARQL]).

    Do you think this is not clear enough, or I'm missing your point here?

2. About the semantics of `dcat:bbox`, the property is meant to specify the geographic bounding box of a resource, as per its definition. So, if the resource is a phonebook, as in your example, it would denote the bounding box of the geometry of the phonebook itself:

    a:PhoneBook dcat:bbox "POLYGON((...))"^^geosparql:wktLiteral .

    On the other hand, to specify the geographic / administrative area covered by the numbers in the phonebook, you should use `dcat:bbox` with the class instance (e.g., `dcterms:Location`) denoting that area, and link the area to the phonebook (e.g., by using property `dcterms:spatial`): 

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

    This is exactly how `dcat:bbox` is used in DCAT to specify the spatial coverage of a dataset, as show in the relevant example in the DCAT specification:

    Does this address your concerns?

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

Sent via github-notify-ml as configured in

Received on Tuesday, 24 August 2021 22:37:00 UTC