Re: [dxwg] Profile negotiation [RPFN]

Hi Annette,

> What I'm seeing a requirement for is a standardized way to indicate the availability of alternative forms of a dataset with different profiles and to enable the end user (human or script) to receive the most appropriate one for their use.

+1

> Consider the case where the client is a human, browsing to find a dataset that matches a certain profile that they like. If they are using a typical commercial browser, they don't have a ready facility to use content negotiation.

Agreed.
However, there can still be links to representations in a specific profile.
The difference is that these links don't need to be standardized,
as in that use case, they'd be followed by a human.

> Using content negotiation, they need to make a request and then capture the list of available formats that the server returns in the header. For that to work, the script needs to be written to expect negotiation as one way it can get such data.

Yes, but the above is true for any other mechanism.
E.g., if we return the available formats as a list of links,
that list needs to be parsed in some way too.

So in any case, clients in that use case
will need some way of parsing a list of profiles.

> If everyone publishes their data this way, that's fine. But what if content negotiation by profile follows the adoption trend of content negotiation by other dimensions?

Point regarding adoption partially taken,
even though content-type and language negotiation are used
(but not to a full extent indeed).

However, we are specifying the mechanism here,
so we can influence how it works.

> Consider the case where the client is a script for a web application. The script needs data with a specific profile to work at all.  This case works with negotiation, but it's not clear to me that it wouldn't work as well with a link-based approach, e.g. a link with an attribute that indicates its profile.

It could certainly *work*.
For me, it's more a question of
how we can elegantly integrate it into the Web
and the other existing representation dimensions.

> On the client side, it's easier and faster to check an attribute in a link than to try to follow it and then parse the header to see if you received what you wanted.

Mmm, I don't subscribe to that argument.

When you say "check an attribute in a link",
this means that you already have a document with links.
So you have performed a request,
and are parsing the response.
You then still need a second request to retrieve what you need.

With content negotiation, you would also make a request,
but that request would directly give you what you asked for,
and you check the header value to confirm (no parsing needed).

> Re registration, if you want user agents to be able to do anything with your MIME type other than download it, it needs to be registered.

That's not correct as far as I know.
There are many unregistered MIME types in use.

Consider for instance "application/vnd.github.v3+json",
which is used but registered nowhere.

> I suppose that, if the profile creator wants user agents to be able to do anything profile-specific with a dataset, they would supply a dereferenceable IRI.

Agreed.

> I'm thinking of content negotiation, where a resource is a thing with a URL and a representation is a version of it that a user agent may receive depending on the accept headers in the request.

Agreed.

However, given that "a resource is a thing with a URL",
we are free to assign a URL to that representation as well,
so it can also be approached as a resource in its own right.
Content negotiation doesn't change that.

It is also important to note that,
regardless of whether we use content negotiation or not,
that a profile-specific version V of a resource R _is_ a representation.
I.e., V is a resource and V is a representation of R,
regardless of whether V was received through conneg or links.

Best,

Ruben

Received on Wednesday, 6 June 2018 07:25:56 UTC