How to present the different elfie profiles?

[jkreft-usgs]

So if there is a single elfie profile for a given endpoint (waterdata.usgs.gov/monitoring-location/08279500), it is easy enough to just add a header to the request (Accept:application/ld+json). But what if the same endpoint can generate multiple views/profiles? What would be the best way to do this?

[jkreft-usgs]

I am leaning towards something like this: waterdata.usgs.gov/monitoring-location/{monitoring_location_id}/views/{some_view}

It would be caching friendly, restful and would make it easy to make pretty html as well as straight json-ld versions of the views via content negotiation

[dblodgett-usgs]

This is the kind of stuff we said we did not want to deal with in ELFIE -- but the approach you suggest makes sense. The Linked Data API has handling for a pretty broad set of options that may be of interest to specify from the client to get various "views" of a thing. https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Query_Parameters.md

[ByronCinNZ]

Jim,

My first reaction to this suggested approach is that it feels a bit kludgy but I am not sure why. But the more I look at it the more I like it. It neatly demonstrates how the data can be decoupled from presentation and content type decoupled from schema. Much more a RESTful approach than using query parameters. This seems very close to the work Rob is doing in DXWG content negotiation by schema. If it is the best way to do this I do not know. At least it illustrates the principle and that is all we need for this ELFIE.

Rob, what do you think?

Dave, I think it important to deal with this to at least a limited extent. This at least gets across the point that an ELFIE view is just one of many possible views. While we are not solving the problem of content negotiation by schema and related issues, we need to present this as a solution that is compatible with future implementation of such tech. Otherwise ELFIE starts to give the impression of being too monolithic - to tightly coupled to a particular way of describing data through an api.

Does this make sense? Anyone?

Byron

On 19/01/2018, at 2:49 AM, David Blodgett notifications@github.com wrote:

This is the kind of stuff we said we did not want to deal with in ELFIE -- but the approach you suggest makes sense. The Linked Data API has handling for a pretty broad set of options that may be of interest to specify from the client to get various "views" of a thing. https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Query_Parameters.md https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Query_Parameters.md — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ELFIE/issues/115#issuecomment-358651323, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCRPPTDQfTeg6vj8512R3O5HMsebgMsks5tL0vWgaJpZM4RiBgX.

[dblodgett-usgs]

Guys, don't take the short-and-cute nature of my response as resistance to the suggestion. I did say it makes sense. I feel that way for all the reasons you describe, @ByronCinNZ. I think the key is that it "neatly demonstrates". And following a "it's just REST stupid" convention for the purposes of such a demonstration just -- seems to make sense.

What I mean by we don't want to deal with it in ELFIE is that we are not really in a position to have a strong recommendation on this in ELFIE. What we are in a position to recommend is a useful and adoptable way to encode the content you would get back from such a URI/API convention.

So -- should I implement the simplified ELFIE views for the example content following this convention? What I've done to date is just "the kitchen sink" of ELFIE views. It's not "all" per se, just "all that we have". I could strip out the ones that don't match specific contexts and dump those to secondary files pretty easily.

So I guess we are hoping for some feedback from @rob-metalinkage?

[dblodgett-usgs]

I'd like to bring some closure to this issue. I think we'll be including this stuff in the recommendations / future work section. https://github.com/opengeospatial/ELFIE/blob/master/er/10-recommendations.adoc as part of our write up of https://github.com/opengeospatial/ELFIE/issues/32.

Some demonstrations may implement multiple views, others may just do the kitchen sink. IMHO, further implementation and experimentation is needed to know whether there is significant utility in simple vs complex graph views. Adding the choice adds complexity, but simplifying the content makes using the result easier... you gotta love trade offs. Thoughts here?

[dblodgett-usgs]

@rob-metalinkage -- this issue was what we were talking about on the phone.

[jkreft-usgs]

I am also totally down with the concept of a _view parameter like what @rob-metalinkage linked to I see the value there as well

[rob-metalinkage]

OK - will write up a para or two on the approach will take (adopt) in the OGC-NA infrastructure.

Here is a link to a django URI redirect module that supports the _view model

https://github.com/rob-metalinkage/uriredirect

Note: I will update this to support any DXWG emerging standards for this

(I have a set of SKOS rules for this - its API centric so we can easily build re-usable rule sets for standard APIs and apply them to endpoints without fiddling with complex rules.)

[rob-metalinkage]

First cut of issue description for jim, then will get examples from his implementation and work into input to ER...

For a given object on the web, different clients and different applications may want different forms of information, with different levels of detail. The "dimensions" of this - i.e. the ways things may vary - are already partially supported in the Web using MIME-type (encoding) and locale (language) preference headers. The Data Exchange Working Group is currently exploring description and negotiation by "profiles" - i.e. content choices bound to underlying data models (schema, shapes).

Three ways of accessing a profile given an object identifier are: 1) use of extended HTTP headers 2) embedding the view choice in URLs (REST path patterns) 3) using query paramers (?_view=X)

All have pros and cons - but are not mutually exclusive.

For each case, a challenges include:

• how to advertise the availability of the profile
• how to machine-test the profile is available
• how to find out what a view actually means

In all cases, views are likely to be designated by tokens - eg "timeseriesML" - and something needs to be done to define what these mean, and how clients are supposed to know this.

In the OGC-NA, as an interim solution" we will provide a number of views and support the _view= paradigm, but also provide a specific view that documents all available views "_view=alternates" and embed key views as links in data.

REST patterns may also be provided - but it get tricky to guess which dimensions must be present in the path in which order:

imagine negotiation over time, view, spatial resolution and coordinate system /mything/latest/polygon/utm17/10m or mything/polygon/10m/utm17/latest etc

REST requires parsing of paths, and construction of paths at both client and server, whereas query parameters are already separated out into form elements and request models at the client and server respectively. Both work the same as embedded URLs however.

It is also easier to document what options exist for what query parameters (in an alternates view for example, or as annotations in Linked Data) - than it is to describe the components of a URL path.

Finally, there may be an opportunity to use context documents to define namespaces to make views into dereferencable identifiers - so machine discovery of what they mean is required, tokens can be interpreted as CURIEs based on the namespaces declared in a default view, perhaps. (needs more thinking, but avoids a central register of view names)

[rob-metalinkage]

also - possible cascading hierarchy when multiple methods co-exist

REST path overides query parameters overrides header (preferences)

[dblodgett-usgs]

Thanks for this @rob-metalinkage -- I feel like I understood most of that but not with quite that much clarity. I linked this to one of the ER issues. I'm going to move this issue to done and @jkreft-usgs can refer to it for implementation.