- From: Michael Luggen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Mar 2025 10:23:00 +0000
- To: public-dxwg-wg@w3.org
Thank you @bertvannuffelen for the in-depth answer and sorry for the late answer. Quick responses to your valid points: 1. We are aware of the implications regarding the harvesting structure. In Switzerland, with opendata.swiss is a centralised portal which is harvesting the local portals, and provides a consolidated form to the EU Portal. Opendata.swiss is in the lead of dcat-ap-ch, and therefore will take care of "resolving" the concepts to strings to stream up-wards. 2. As you can see in the DRAFT Usage Note https://www.dcat-ap.ch/releases/3.0_workingdraft/dcat-ap-ch_3.0_workingdraft.html#resource-keyword, we do restrict the possible keywords to 3 sources, which can easily be consulted, and are kept up-to-date. We open the Range to: skos:Concept, schema:DefinedTerm, wikibase:item.Allowing to simply provide the Concept URI, makes it effectively easier for the data providers, as they only need to provide on URI and therefore have "tagged" there datasets with concepts in all official swiss languages. Further does TERMDAT itself provide a topic classification for terms, which in turn will be another implicit advantage for the dataset providers, and finally the dataset search. 3. That is true, we estimate the change of the data portals a short term investment, which will long term pay easily in better quality of the dataset description and mostly also by reducing the work to invest in each specific dataset. 4. First, in general this is true for other attributes of DCAT as of today. But in this specific case, we only allow links on external concept URIs. We do not support the use of "ad-hoc" concepts. (As proposed, we might define this part more strictly in the usage-note.) 5. Therefore our effort to see how we can push this topic forward up-stream in DCAT-AP and DCAT itself, as of in this exchange. As you mention, the problem with using "surface forms" or "labels" as uniquely identify concept in SKOS brings often unclear semantic identifications. (This is especially true in multilingual contexts.) Therefore do we think that it is a necessary step forward to extend also dcat:keywords to make the use of concepts, over simple strings. We do not see the usage of an open-end and dynamically changing (therefore very up-to-date) list of concepts as we have with TERMDAT and also WIKIDATA as a "classification" which is used with dcat:theme. I hear your proposition of creating another property for such cases, but we estimate that the difference to dcat:keyword is difficult to communicate, as effectively it has the same semantically speaking idea at its core. Also we like to make sure that the dataset providers understand, that there is no need to provide Concept URIs and additionally literals. We like to keep our argumentation alive and would like to see that the Range for dcat:keyword is simply dropped in the future. -- GitHub Notification of comment by l00mi Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1585#issuecomment-2742937135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 March 2025 10:23:01 UTC