Follow-up to Conneg Poll

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?

Thanks,

Nick