How does SELFIE relate to the implementation of resolvers?

[dblodgett-usgs]

BRGM, and NRCAN have two different approaches and there are plenty more. Some have basic redirection (BGRM and others) but there is another approach (GSIP implemented by NRCAN) that leverages "sameAs" relationships directly.

In the IE, we would probably implement a few resolvers to test this slightly more involved kind of URI resolution.

We will develop some guidance on how resolvers should behave in this arrangement.

We should narrow this discussion in the comments below in preparation for meeting in Leuven.

[dblodgett-usgs]

Per the outcome of the face to face, we will test two approaches. 1) id URL -> 303 response -> info URL -> hypermedia or landing page -> data URL -> data content In this case, an id URL returns a 303 seeOther to an info URL which returns hypermedia or a linked-data landing page depending on content negotiation at that stage. 2) id URL + content negotiation -> data content In this case, if content negotiation indicates data is desired (geojson, application/xml) and a single resource of that type is known, data could be returned directly at the id URL. Additionally, in the case the content negotiation is a hypermedia media type (html, json-ld, ??) the expected behavior is to return the info resource at the id URL.

@afeliachi and @denevers -- does this align with what you remember from our conversation?

[denevers]

case 1 is id -> conneg -> 303 -> info-hypermedia -> data the hypermedia contains links that might also go through content negotiation . The info-hypermedia list the supported format explicitly, but it's a convenience for developpers (prevent asking each data resource for a specific mime type). Th

[dblodgett-usgs]

Updated description.

In both cases, resources of type id, info, and data are available to the client, it's just that in case 2 they are all available from the same resource depending on client behavior? @sgrellet and @afeliachi is this capturing the workflow you want to support? I wonder if there is a hybrid that could bridge the two by optionally putting the content type into a key/value pair like: http://foo.com/thing?f="bar_mimetype" or a file extension like: http://foo.com/thing.html

In that approach a naive client would get an html info resource listing available representations etc. with an appropriate string appended to the id base URL to get particular representations in their browser. A "smart" client would get the content they are looking for from content negotiation directly.

The real distinction here is that the id URL would display in a browser for a naive user and return content directly for a content-negotiation request. However, in hyper-media returned, f=mimetype or .format would be appended to the id url to distinguish between the actual resources. I'm sure this breaks some important aspect of the semantic web, but I think it would work fine?

[dblodgett-usgs]

I spent the afternoon working on the engineering report section for this issue, #19, and to some extent #66. See: https://docs.google.com/document/d/1b-TdqWl3jf2jJD7dYvLkxTa6JEGxtUJAue7jSiaEE2s/edit#bookmark=id.4jz1auefxx7f