search

ProfileNegotiation / I-D-Profile-Negotiation

Internet-Draft: Indicating and Negotiating Profiles in HTTP
https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation.html
2 stars 3 forks source link

Is weighted content negotion necessary #15

Closed larsgsvensson closed 5 years ago

larsgsvensson commented 8 years ago

Comment from Antoine on DC-Architecture:

On weighted content negotiation:

In 2.2.1 you mention "there is no way to specify a weight for the profile which limits the possibilities to perform proper content negotiation."

This is indeed a problem, but I've got a super-stupid question... Couldn't the request in your ID be then to open the possibility to specify weights on the 'profile' header? Or is it just plainly impossible because it's a Link Relation Type? (don't hit too hard please!)

Yes, the Link header offers no possibility to add weights (or multiple schemas/profiles).

Then, is there actually such a big need for 'real' content negotiation? For example if will there be many clients that will send open-ended requests for 'BibFrame or DC, preferably Bibframe?'. Getting one of the other could make really a big difference, in terms of data processing involved. I'd rather expect that the client just asks the list of available profile in advance, and then calls the one it wants as part of a profile-specific process.

I don't really know if this will be a common use-case, but I could imagine it and see it as a kind of future-proofing. I frankly don't think many applications look at the q-values for the Accept-header either, but I don't think we should rule out the possibility...

Let me be clear, it's not that I'm against weighted content negotiation. Just that if having it raises a lot of problems for your proposal, then you may want to de-prioritize it. To me that's clearly not the most important point of your requirement, but that's the one that really triggers you to suggest a new header and not a Link Relation Type, which would have been more light- weight.

My main reason for not re-using the Link header with rel="profile" was that "profile" didn't really fit. Of course an alternative could be to register a new relation type "schema".

Yes I think I was moving towards this. I'm keep on leaving the door open to negotiation of profiles with weighted priorities, but if it requires a much more complex solution than the a new rel in the Link header, then one should think about it twice. Especially if (as I think) the cases for negotiating profiles with way are much less likely to happen than cases for negotiating content (and as you say I feel that the latter are not found very often).

RubenVerborgh commented 7 years ago

I think we should follow what other multi-option Accept- headers do, and also offer q parameters.

The tricky bit here is that some profiles might be combined (see #5).

ericprud commented 7 years ago

The FHIR/RDF use case specifically demands weighting OWL representations above or below other representations. For example, a FHIR value set could be expressed in Turtle in the FHIR schema (how FHIR tools expect to see it) or in Turtle in OWL (how inferencing tools expect to see it), e.g.

<http://hl7.org/fhir/ValueSet/example-extensional> owl:equivalentClass [
    owl:oneOf (loinc:14647-2 loinc:2093-3 loinc:35200-5 loinc:9342-7)
] .
RubenVerborgh commented 5 years ago

We seem to agree that weighting is necessary.