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

Re: [dxwg] Use case: web browser navigation of profile information

From: Annette Greiner <amgreiner@lbl.gov>
Date: Thu, 5 Jul 2018 11:31:05 -0700
To: public-dxwg-wg@w3.org
Message-ID: <32353bdb-5dc3-0106-e22a-47ee1efcb63d@lbl.gov>
I think this use case is extremely important and fully in scope. Our 
charter tells us to develop guidance in the use of profiles, and if we 
are going to be suggesting the use of content negotiation, I would 
suggest that item number one in the list of principles would be to also 
provide a means of profile discovery without content negotiation. I 
don't see that as at all at odds with web architecture. Conneg requires 
that the representations to be served have dereferenceable URIs anyway. 
We needn't (and IMHO shouldn't) specify the use of query strings.

One of my biggest concerns with profile negotiation is that the content 
of the underlying resource is different in the representations served by 
content negotiation. Clients are limited to an automated negotiation 
even though information to which the user has no access is relevant to 
the choice. For example, the same dataset distribution served for 
different profiles may offer more content with a profile that describes 
more things. The user may want the fuller set of data but would have no 
means of knowing that it exists. If we assume use only by 
profile-specific applications, then the application cannot do anything 
with the alternatives that it is configured not to accept, so the issue 
goes away. But I can easily imagine applications that are not limited to 
a single profile or even a short list of them. Even if they use * to 
accept all possible profiles, they only get one. They may get a list in 
the reply header, but there is no reasonable way to indicate the 
differences in content between them. Human consumers won't even get 
that, unless we address this issue.


On 7/3/18 3:16 PM, aisaac via GitHub wrote:
> I'm quite split. To me in theory the use case could be approved, 
> requirement(s) derived from it, and then we decide to reject the 
> requirements if we think they're too much at odds with web 
> architecture. This is tedious, but this would document why we've not 
> gone this way. And I think this can be useful, as others may claim 
> that this use case corresponds to a desire they have. For one I would 
> understand that people used to the OAI-PMH parameter could be tempted 
> to push for this have this pattern still available in a more general 
> setting. So with this in mind I would vote for saying that the use 
> case is in scope.
> On the other hand, our charter (https://www.w3.org/2017/dxwg/charter) 
> dictates that content negotiation by application profile should be the 
> only delivery option that we explore. So this would be a reason to 
> rule out the part about using alternatives to negotiation. The one 
> thing the charter does not explicitly reject would be the part about 
> discovering the available profiles, i.e. the `ListMetadataFormats` 
> parameter from OAI-PMH 
> (https://www.openarchives.org/OAI/openarchivesprotocol.html#ListMetadataFormats). 
> But without the other pattern to access data in certain profiles 
> without conneg, this would be a bit moot.
> In any case, @nicholascar has answered the questions I had. And the 
> title could be indeed changed to reflect better the content of the use 
> case. I had understood 'profile information' to be 'metadata 
> describing the profile', i.e. ProfileDesc statements...
> @larsgsvensson @RubenVerborgh @rob-metalinkage  I have an action to 
> call for your feedback about this case, now that it's been edited by 
> Nick :-)

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Thursday, 5 July 2018 18:31:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:45:00 UTC