w3c / dx-connegp

Content Negotiation by Profile
https://w3c.github.io/dx-connegp/connegp/
Other
6 stars 5 forks source link

Resource URLs prohibit the use of QSA in data aggregators and/or single page web applications #30

Open ssstolk opened 3 years ago

ssstolk commented 3 years ago

Paragraph "7.3.2.3 Resource URL" in https://www.w3.org/TR/2019/WD-dx-prof-conneg-20191126/ mentions the following:

For the representation of Resource X, according to Profile Y, in Media Type Z:

Rather than:
GET /single/endpoint \
            ?resource=http://example.org/resource/X \
            &_profile=Y \
            &_mediatype=Z HTTP/1.1

Use:
GET /resource/X?_profile=Y&_mediatype=Z HTTP/1.1

To me this seems like a missed opportunity. Is it not the case that in a decentralized Web, it is also desirable to be able to select services from data aggregators? These may not be the original content holder, but are still able to present information on a certain resource, including alternate profiles. I believe I recall a presentation by Ruben Verborgh a few years back at Europeana Tech Conference (SS Rotterdam, the Netherlands) in which he advocated the choice for consumers to select a service for their data, which may indeed be a data aggregator. Indeed, I have seen a number of applications which use such a method (mainly: single page applications) and would still benefit from being able to use QSA for profile negotiation.

rob-metalinkage commented 9 months ago

The specification allows both to exist - its agnostic about the rest of the URL and parameters - only defining the specifc synatc and semantics of the _profile and _mediatype qualifying parameters. Implementations have covered both cases so this seems a moot point.

nicholascar commented 9 months ago

I do a lot of redirecting from a resource with ConnegP QSAs to an underlying system that uses a QSA for the resource identifier too, such as https://github.com/AGLDWG/pid-proxy/blob/master/conf/linked.data.gov.au/org/gsq.conf#L22-L26

The ConnegP conformance is handled, as you see in the link above, with a redirection layer in front of the system.

nicholascar commented 9 months ago

I recognise that there is inconsistencies in Section 7.3.2.3 regarding the imperative wording of SHOULD NOT and MUST NOT

rob-metalinkage commented 9 months ago

Proposal for discussion - refer to potential for definition of a specific profile to allow custom resource identification strategies using other APIs (i.e. not just HTTP dereferencing)

rob-metalinkage commented 9 months ago

As discussed 07 Feb 2024, proposal to explore extending qsa-alt profile to support general templated URL patterns to handle this case. @YoucTagh to explore options.