W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > October 2019

Follow-up to Conneg Poll

From: Nicholas Car <nicholas.car@surroundaustralia.com>
Date: Tue, 15 Oct 2019 22:14:56 +0000
To: Antoine Isaac <aisaac@few.vu.nl>
CC: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <KU1PR01MB2102303771A62AAC02BA30C7A2930@KU1PR01MB2102.apcprd01.prod.exchangelabs.com>
Hi Antoine,

In the poll for moving Conneg to CR, you raised a number of points.

> I cannot vote in favor of the draft, because I have realized there's a complete set of features (the "QSA alternate" stuff) that is based on a data model (Alternate Representations Data Model) that I didn't get the time to look at, because my attention was drown to other issues. In fact I only noticed these things today...
There has been much more time now so please review the model!

> My worries about these is that:
> - it relies on a representation of profiles that may or may not be aligned with PROF, thus possibly undermining the coming PROF publication (it won't be very relevant if the WG publishes two even slightly different modelings for profiles)
I think that the profile representations in Conneg and PROF are aligned.  Section 6.4 (https://w3c.github.io/dxwg/conneg-by-ap/#altr) gives the mode and in it thereís a link to a Profile which could be characterised in PROF. The use of conforms to (implemented as dct:conformsTo in the appendix) is the same here as in DCAT and even PROF itself when used for instance data conforming to things).

Section A.2.2. describes extended use of the model, which is just normal RDF/OWL use, and while this doesnít include PROF examples, it could do.

I donít think we need any further formal AltP/PROF tie-ins but would a further example, perhaps as another subsection in Appendix A, be useful? If so, what are the aspects of the two models that youíd like to demonstrate alignment between, or perhaps what elements would you like to ensure thereís no mis-alignment between?

- I don't see the how the complexity of the solution will appeal to implementers: if I was someone with alternative QSAs for serving profiles, it would seem simpler to just add the standard QSAs rather than to create and serve a full description of how to discover my alternative QSAs.
I agree that it may be simpler to just adopt _profile and I encourage implementers to do so! Iíve found it possible to easily add in support for this in my implementation. But, it is possible to do things differently Ė use alternate keywords Ė and we do find cases where thatís probably the only way systems can operate. For example, CKAN uses ?profile=Ö within its ckan-dcat plugin. If it proves too hard to change that to _profile (perhaps thereís a large install base that relies on it?) then thatís a case where adding in the function to allow for QSA Key Discovery, rather than implementing _profile & _profile=all and thus the alternate QSA profile might be necessary. Iíll let you know about the DCAT plugin soon as Iím working on it directly after sending this email!

> I think that if these were put at features at risk (if just to accommodate for a better alignment with - or direct use of - PROF) I would vote 'yes'.
Currently the only Feature at risk is the HTTP implementation, due to the reliance on the IETF doc. It looks like there will soon be 2+ implementations of the QSA Functional Profiles so they wonít be at risk.

Please can you follow up my responses to these points?


Received on Tuesday, 15 October 2019 22:15:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:58 UTC