W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > June 2018

Re: [dxwg] Profile negotiation [RPFN]

From: Ruben Verborgh <Ruben.Verborgh@UGent.be>
Date: Tue, 5 Jun 2018 21:13:03 +0000
To: Annette Greiner <amgreiner@lbl.gov>
CC: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <23DA8BB9-1929-452B-A5BC-D33920AE4389@ugent.be>
Hi Annette,

> What do you mean? Links are already available in http.

Yeah, but you'd need a standardized way to say
"this link points to representation of X with profiles Y, Z"

>> Content negotiation is simply an existing mechanism
>> for connecting a resource to representations,
>> so reusing it seems better than inventing a new link-based negotiation mechanism.
> You are assuming the need for negotiation. That's what I'm asking you to justify.

No, I'm assuming a need for clients
to automatically find the representation they want,
and I'm proposing content negotiation for that
as opposed to a link-only mechanism.

>> Furthermore, linking assumes that there is a finite number of representations,
>> and not a combinatorial explosion of all combinations that can be made.
> There *is* a finite number of representations that would be available.

Finite, yes. Necessarily small, no.

> You would have to configure the server to return the right representations, and you would have to have created each of those representations.

In any case, but that's independent of the mechanism to find them.

>> Finally, it integrates with negotiation in order dimensions, such as
>> "give me the French document in XML conforming to profiles X, Y, Z".
> Yes, that is nice. But there are other possible dimensions to data. Why negotiate for this one?

Quite the contrary: let's negotiate all dimensions.
We already do this for content type and language.

> One can think of different versions of datasets as different resources if one wants.

Yes, the usage of content negotiation does not alter that.

> In fact, one could argue that it is always a different resource because it contains different values.

Sure, but that is independent of the mechanism to arrive at the right one.

> It's a choice to decide that it should be treated as a representation. What motivates that choice?

You seem to use "representation" as an opposite of "resource", but that's not correct.
As I've explained on GitHub, "representation" is a relative notion, not an absolute one:

>> To understand this, it's important to see that the "representation" concept is a relative notion. E.g., in the sentence "A is a representation of B", B the resource that A is the representation of. However, A is a resource in its own right.
>> An example to clarify:
>> 	 http://example.org/weather/amsterdam/2018-06-01 is the weather report for Amsterdam for 1 June
>> 	 http://example.org/weather/amsterdam/2018-06-01.html is the weather report for Amsterdam for 1 June in HTML
>> Regardless of whether 2 has its own URL, all of the following hold:
>> 	 1 is a resource
>> 	 2 is a resource
>> 	 2 is a representation of 1

>>> Why is automated discovery needed?
>> Because it's a manual thing otherwise.
> That is a tautology.

I'll try to explain better.

If you have a client that fetches resources represented in a certain profile,
do you want it to ask you every time what link it should follow,
or do you want it to be able to select the right link itself?

>> You don't want your client to ask you what links to follow.
> Why not? That is how hypermedia APIs work.

Nothing in hypermedia APIs requires clients to ask you such things.
It is a possibility, but not a requirement.

> Adding negotiation as a new alternative means that crawling the web of data has to involve checking for profile options by content negotiation in addition to checking what is available through links.

You're still free to link to them.

> But I get the feeling you have a specific use case in mind where this all makes immediate sense. *What is that use case?*

I have a client that can read certain JSON profiles.
I want that client to operate on dataset X.
The client should be able to get X in a profile it understands.

> Registration of new MIME types is needed.

I'm afraid that's not correct.
I can just start using application/vnd.my-thing whenever I want to,
and I do not need to register that with IETF.

> How do you get around new profiles needing to be registered?

You mint an IRI for them.


Received on Tuesday, 5 June 2018 21:16:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:04 UTC