Re: [dxwg] Profile negotiation [RPFN]

Hi Annette

At this stage I'm not trying to narrow down the implementation choices here
- just making sure that real-world requirements dont get lost. Your points
are valid - at some point in the chain of publishing, cataloguing,
discovery , access and use there is a need to cope with the informational
problem of describing what a client can assume about the data, and this
always involves different degrees of abstraction.  Publishers are always
more specific than service software which are more specific than APIs which
are more specific than catalogs which are more specific than (most)
clients... Having implemented interoperability standards across servers,
catalogs, brokers, portals and clients I see pros and cons for pretty much
every implementation pattern, and little chance we can force every
community to push the burden on interpretation to the same layer. Hence the
focus on an informational pattern, which can be deployed anywhere in the
chain.


The only point I would clarify are your assumptions about server
responsibilities and effort. Generally speaking, server side support for
negotiation would be driven by data descriptions in a catalog and not
server-admin style configuration (and thats exactly how I'm building the
OGC Linked Data infrastructure, and why the updated DCAT and profileDesc
are needed).  This is a lot easier than maintaining links manually - but I
still havent decided if the reasoning to generate links is going to be done
on the fly or by forwards-chaining and caching inferences. This may depend
on some of those questions about how many dimensions we need to negotiate
on and how fine grained negotiation may be.


On Wed, 6 Jun 2018 at 05:23 Annette Greiner <amgreiner@lbl.gov> wrote:

> 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> 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
>
> To
> Annette Greiner
> Cc
> Rob Atkinson
> public-dxwg-wg@w3.org
>
>