Re: [dxwg] Profile negotiation [RPFN]

Are you talking about the case of a data catalog that harvests links to 
datasets published elsewhere? So thing A might be published originally 
at state.gov and harvested by lotsofstatesdata.org. When the harvester 
for lotsofstatesdata.org requests state.gov/things/A, it gets one 
representation of A, the one that best matches its profile negotiation 
settings, and per Ruben and Lars's IETF draft, it gets a list of 
alternates. Getting info about which representations are available thus 
depends on the client getting a list and doing something with it, much 
as it would do something with a list of available links. The harvesting 
site would still need to interpret and act on that list of 
representations, unless they don't care to relay that information to 
their own clients. Are you thinking that lotsofstates.org would just get 
the one URL and publish that without indicating what profiles are 
available? This does make life easier for the catalog publisher, but it 
leaves the client having to figure out what's available and whether they 
can use it.

I suspect that most publishers of datasets will only use a single 
profile, so the negotiation part is likely to just return that, with no 
real negotiation. And if there are multiple profile options available, 
with negotiation, you may get what you expect, and you may get your 
second choice, so the end user will need to deal with that as well.

Setting up a web site to send the correct representation upon 
negotiation requires some work, too. You aren't maintaining links, but 
you are maintaining server configuration to deliver the required 
responses. Updating server configuration is at least as much of a 
headache as updating links, more if you're not also a web server admin. 
Then there is the fact that commercial browsers don't provide any means 
for users to set their negotiation preferences. So the original 
publisher will still need to offer the same datasets with different 
profiles via links.

-Annette


On 6/4/18 3:14 PM, Rob Atkinson wrote:
> The practical reason is that without profile negotiation, a client 
> wanting a particular representation of a thing A must be able to find, 
> interpret and act on canonical metadata about what representations 
> are. this is a huge leap and barrier.
>
> If you think about this a bit deeper the alternative is actually worse 
> - everyone publishing data and wanting to cite A, but only having 
> options of URLS of representations b,c,d,e,f,g,h,i,j,k... and unknown 
> future representations needs to continually maintain their data to 
> have all the links, or know what all the clients might want, and embed 
> qualification metadata  (i.e all the content and mechanisms of the 
> "alternates" view Nick was talking about, embedded in every resource.
>
> In  a nutshell, we don't have a "Web of Data" or a "Semantic Web" of 
> any great depth relative the amount of "data on the web" partly 
> because this is currently broken. We can provide two canonical 
> mechanisms to help - negotiation and description of how 
> profile-conformant resources relate. It may not solve the problem but 
> it addresses a major barrier.
>
>
>
>
> On Tue, 5 Jun 2018 at 05:06 Annette Greiner <amgreiner@lbl.gov 
> <mailto:amgreiner@lbl.gov>> wrote:
>
>     Sorry, but I need an answer that is not tautological.
>
>     I imagine the IETF will be asking the same question. Why do you think
>     you need to enable this type of negotiation versus allowing discovery
>     via links? Clients can get from one representation to another by
>     following links (either in a browser or in an API). That is plenty
>     webby. Why is automated discovery needed? There are plenty of
>     differentiating features of web data resources that a user could
>     want;
>     why make this particular level of differentiation negotiated? Do you
>     have a real need to require profile creators to register their
>     profiles
>     with IETF? This is more work for IETF and for profile creators.
>     (If you
>     have a way around that, it would help to hear it.)
>
>     Don't get me wrong. I'm not trying to shut down discussion of profile
>     negotiation. I'm trying to stimulate the production of actual use
>     cases
>     that can guide the generation of realistic requirements.
>     Reiterating the
>     solution doesn't address that.
>
>     -Annette
>
>
>     On 6/1/18 11:28 PM, Ruben Verborgh via GitHub wrote:
>     >> I'm talking about the motivation to use negotiation.
>     >
>     > Negotiation is what gets clients to the representation with the
>     > preferred profile.
>     >
>     >> If the only motivation is to have the same resource available in
>     >> conformance to different profiles
>     >
>     > No, that's not the motivation. We can do that with existing
>     > technologies already.
>     >
>     > What existing technologies don't do, is automatically getting a
>     > resource in a profile the client understands.
>     >
>     >> I don't see any particular reason to have profile negotiation that
>     >> works like content negotiation.
>     >
>     > It's just like negotiating between XML or JSON, except more
>     fine-grained:
>     >
>     https://ruben.verborgh.org/articles/fine-grained-content-negotiation/
>     >
>     >> Having multiple profiles available is realized already by just
>     >> offering a version of the dataset that conforms to one profile
>     under
>     >> one URL and a version that applies to another under another URL.
>     >
>     > But how does the client get from one to the other?
>     > Our answer: content negotiation.
>     >
>     >
>     >
>
>     -- 
>     Annette Greiner
>     NERSC Data and Analytics Services
>     Lawrence Berkeley National Laboratory
>
>

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory