I share John's unease here. And I remain uneasy about the 200 C-L solution.
I know I sound like a fundamentalist in a discussion where we're trying
to find a practical, workable solution, but is a description of a toucan
a representation of a toucan? IMO, it's not. Sure, one can imagine an
HTTP response returning a very rich data stream that conveys the entire
experience of having a toucan on your desk - but the toucan ain't
actually there.
I've been toying with the idea of including a substitution rule in a 200
header.
Following the practice of using /id/ for NIRs and /doc/ for their
descriptions, suppose a GET on http://example.com/id/toucan returned:
200 OK
Apply-URI-substitution: s/id/doc/
Content-type: text/html
Blah blah...
In just one trip, user agents would then be able to interpret this as a
document whose URI can be derived by performing the substitution,
knowing that the returned data describes the thing identified by the
original URI.
This approach, and C-L approach, both require client side implementation
of course.
My worry is that any 200-based solution is going to be poorly
implemented in the real world by both browsers and LOD publishers (Talis
excepted of course!) so that IRs and NIRs will be indistinguishable 'in
the wild'.
303 works already, and that is still the one that feels right to me. I'm
happy that the discussion here is centred on adding a new method cf.
replacing 303, especially as the HTTP-Bis group seems to have made its
use for LOD and explicit part of the definition.
Phil.
On 07/11/2010 15:07, John Sheridan wrote:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +0000, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
local.data.gov.uk/id/{local-council-identifier} which would 303 to IR
about that Council on the Council's own website.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for (say) the Open Government Licence is always going to
want to publish the IR about that on its own website, and should be
encouraged to do so.
The 303 pattern helps enable this pattern, which fits well in general
with some of the challenges on Linked Data in the public sector.
I would like to understand a little better how Ian's proposal maps to
this use case.
Grateful for comments,
John.
On Sun, 2010-11-07 at 12:11 +0100, Niklas Lindström wrote:
+1 indeed. Content-Location has definitely been overlooked. During
conneg, it is used to differ between a resource and its
representation(s), which are obviously different resources (well, not
necessarily the same). This distinction could certainly be enough to
remove the fundamental need for 303:ing on NIR:s (provided consensus
and some formal resolution).
(I pondered on a similar issue in
<http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2010Feb/0007.html>,
regarding the identity of fragments. Perhaps that discussion would be
worth revisiting again in light of this?)
Best regards,
Niklas
On Fri, Nov 5, 2010 at 5:55 PM, Nathan<nat...@webr3.org> wrote:
Mike Kelly wrote:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14
snipped and fuller version inserted:
4. If the response has a Content-Location header field, and that URI
is not the same as the effective request URI, then the response
asserts that its payload is a representation of the resource
identified by the Content-Location URI. However, such an
assertion cannot be trusted unless it can be verified by other
means (not defined by HTTP).
If a client wants to make a statement about the specific document
then a response that includes a content-location is giving you the
information necessary to do that correctly. It's complemented and
further clarified in the entity body itself through something like
isDescribedBy.
I stand corrected, think there's something in this, and it could maybe
possibly provide the semantic indirection needed when Content-Location is
there, and different to the effective request uri, and complimented by some
statements (perhaps RDF in the body, or Link header, or html link element)
to assert the same.
Covers a few use-cases, might have legs (once HTTP-bis is a standard?).
Nicely caught Mike!
Best,
Nathan
Please consider the environment before printing this email.
Find out more about Talis at http://www.talis.com/
shared innovation™
Any views or personal opinions expressed within this email may not be those of
Talis Information Ltd or its employees. The content of this email message and
any files that may be attached are confidential, and for the usage of the
intended recipient only. If you are not the intended recipient, then please
return this message to the sender and delete it. Any use of this e-mail by an
unauthorised recipient is prohibited.
Talis Information Ltd is a member of the Talis Group of companies and is
registered in England No 3638278 with its registered office at Knights Court,
Solihull Parkway, Birmingham Business Park, B37 7YB.
--
Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile
http://philarcher.org
@philarcher1
