Re: 200 OK with Content-Location might work
Niklas, In general I am supportive of Ian's thinking and 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 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
Re: 200 OK with Content-Location might work
Hi Niklas,
On Sun, 2010-11-07 at 16:57 +0100, Niklas Lindström wrote:
Hi John!
I understand your points. I also don't think that 303 is a poor
solution in any fundamental way. In fact, given the use-case you
described, having a stable URI which delegates to the current
location is perfectly fine, and in many cases preferable to the
alternative (demanding persistent, permanent hosting of all the data
in a dynamic organizational environment).
My first mail with this use case didn't make the list (I made a mistake
with the posting). For completeness, I repeat it below, so others can
follow how we are starting to use 303s across domains, in the hope of
improving the chances of persistent URIs for NIRs.
The use-case was with the Linked Data for UK Government, 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.
eg http://reference.data.gov.uk/id/open-government-licence 303s to a web
page or RDF document published on The National Archives 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.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for the NIR is going to want to publish the IR about that on
its own website, and should be encouraged to do so.
We are thinking about using this pattern to create URIs for local
authorities, where each publishes their own IR on their own website,
303ing from a consistent URI Set for all local authorities, say at
http://local.data.gov.uk/id/local-authority-id
The 303 helps enable this pattern, is easy to implement (eg on Apache,
we can use regular expression based rules), and fits well in general
with some of the challenges on Linked Data in the public sector.
It could be a useful pattern more widely.
In our own work with gov data I can see our current central data
repo solution being turned into a PURL-like service for resources
like agency descriptions which should in time be put at more
appropriate, stable URL:s (combined with judicious owl:sameAs
assertions).
I just think that the demand on NIR:s w/o hashes to be directly
unavailable may be a hard hurdle to overcome when hosting data about
them (and as said elsewhere, can be an unnecessary strain on servers).
Milages certainly varies a lot, and simplifying the demand of 303:ing
from /concept to /concept.{dataformat} to a baseline where conneg
giving a Content-Location is formally enough can be very beneficial.
In fact, this makes the distinction of NIR vs. IR less technical (and
left to the descriptions of the resource to clarify), and just leaves
us with the importance of distinguishing between a resource and its
representations.
I basically think that the HTTP mechanics of 301, 302, 303 and 307
etc. are great tools for sustainable Linked Data deployment. But
having them dictate the fact that a URI represents a NIR or IR is
putting a lot of conceptual design directly into a day-to-day
protocol..
I have a lot of sympathy with this point.
Of course, Content-Location doesn't remove the distinction
either, but it puts more emphasis on the resource vs representation
question, which holds for both resource kinds (AFAIK).
.. I usually steer away from discussions of the NIR vs. IR topic at
least publically (though I love to discuss it in person), since it
touches upon a very philosophical distinction which, taken to the
extreme, can be an eternal discussion (of epistemology, phenomenology
and whatnot).
Off topic, try discussing whether a boundary for an administrative area,
defined by a line drawn *on* a map, is a NIR or an IR :)
I hope that it is enough to say: if the resource does
not intrinsically have the mimetype X (represents itself, is the
record...), use HTTP mechanics (30x, or 200 + Content-Location) to
make it clear that the response body (having mimetype X) is not the
resource itself, but a representation thereof)...
Best regards,
Niklas
[For those wanting more things to ponder: consider the role and nature
of a packet, or the essence of a byte.. ;) ]
2010/11/7 John Sheridan johnlsheri...@yahoo.com:
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
Re: 200 OK with Content-Location might work
Hi Tore, I think your point is in line with one of Ian's motives. At the end of the day, it's pretty obvious that a Toucan ain't going to fly down the wire and pop out of your screen so the distinction between IR and NIR is one that only those at the nerd end of the geek-nerd continuum are ever going to care about. Also, it seems that Content-Location, *if* implemented properly, does maintain the distinction. Halving the number of HTTP requests to get the data you probably want is no bad thing. As others have said, most folk don't see and couldn't care less about the HTTP headers. It's that aspect that makes me wary of, but not actually opposed to, 200 with C-L - it's easier to get away with mistakes if most people don't see them. 303 is more open as it affects the address bar in the browser (assuming it's visible). But, as the scammers and spammers know very well, most people don't look at that either. This thread has probably run long enough. I unsubscribed from the TAG mailing list mainly because I couldn't stand any more debate about IRs vs NIRs. So, I'm going to shut up and go with the flow (and I have to sort out wdrs:describedby this morning too!) Cheers Phil. On 08/11/2010 03:21, Tore Eriksson wrote: Hi Phil! Phil Archer wrote: 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. Since this distinction is, and has been for many years, debatable, why not be pragmatic and leave this choice to the users themselves? If someone thinks that a web page consisting of a picture and a textual description is an adequate represenation of a Toucan, let them return one over HTTP (as long as they are aware that the web page itself is a different resource yada yada...). People expecting the Toucan to fly down the wire and appear at their desk might me disappointed but most users will probably be happy with the low-fidelity version. Tore Eriksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp] 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
Re: 200 OK with Content-Location might work
Hi John, On Sun, 2010-11-07 at 15:12 +, John Sheridan wrote: 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?). +1 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. -0.5 People grok the point of normal 30x for redirection, you can have nice stable URIs but implement them from unstable organizations. Tying them up with NIR v. IR, especially since no one has a clear cut way of distinguishing IR/NIR, is a problem at least in my experience. In our work on local authorities self-publishing URIs/descriptions this issue was a significant barrier. [Though I'm not certain the current outcome (use content-location) helps that much for that case.] Dave
Re: 200 OK with Content-Location might work
On 11/7/10 10:21 PM, Tore Eriksson wrote: Hi Phil! Phil Archer wrote: 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. Since this distinction is, and has been for many years, debatable, why not be pragmatic and leave this choice to the users themselves? If someone thinks that a web page consisting of a picture and a textual description is an adequate represenation of a Toucan, let them return one over HTTP (as long as they are aware that the web page itself is a different resource yada yada...). People expecting the Toucan to fly down the wire and appear at their desk might me disappointed but most users will probably be happy with the low-fidelity version. Tore Eriksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp] Tore, Does the painting of a Toucan -- on some canvas -- infer that the Painter or Painting Viewers expect physical manifestation? Methinks, the Painter (an expressionist) uses signs to project observed attributes of his/her subject (the Toucan), on a canvas, in a manner that stimulates the minds of the Paintings Viewers. Thus, in the minds of the Viewers, the sensation could be such that flight does occur, it just happens in their mind. BTW - Animation is old, so Tucan flight (in our minds) as a result of representation is something that's been happening long before the World Wide Web :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
+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
Re: 200 OK with Content-Location might work
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 +, 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
Re: 200 OK with Content-Location might work
Hi John!
I understand your points. I also don't think that 303 is a poor
solution in any fundamental way. In fact, given the use-case you
described, having a stable URI which delegates to the current
location is perfectly fine, and in many cases preferable to the
alternative (demanding persistent, permanent hosting of all the data
in a dynamic organizational environment).
In our own work with gov data I can see our current central data
repo solution being turned into a PURL-like service for resources
like agency descriptions which should in time be put at more
appropriate, stable URL:s (combined with judicious owl:sameAs
assertions).
I just think that the demand on NIR:s w/o hashes to be directly
unavailable may be a hard hurdle to overcome when hosting data about
them (and as said elsewhere, can be an unnecessary strain on servers).
Milages certainly varies a lot, and simplifying the demand of 303:ing
from /concept to /concept.{dataformat} to a baseline where conneg
giving a Content-Location is formally enough can be very beneficial.
In fact, this makes the distinction of NIR vs. IR less technical (and
left to the descriptions of the resource to clarify), and just leaves
us with the importance of distinguishing between a resource and its
representations.
I basically think that the HTTP mechanics of 301, 302, 303 and 307
etc. are great tools for sustainable Linked Data deployment. But
having them dictate the fact that a URI represents a NIR or IR is
putting a lot of conceptual design directly into a day-to-day
protocol.. Of course, Content-Location doesn't remove the distinction
either, but it puts more emphasis on the resource vs representation
question, which holds for both resource kinds (AFAIK).
.. I usually steer away from discussions of the NIR vs. IR topic at
least publically (though I love to discuss it in person), since it
touches upon a very philosophical distinction which, taken to the
extreme, can be an eternal discussion (of epistemology, phenomenology
and whatnot). I hope that it is enough to say: if the resource does
not intrinsically have the mimetype X (represents itself, is the
record...), use HTTP mechanics (30x, or 200 + Content-Location) to
make it clear that the response body (having mimetype X) is not the
resource itself, but a representation thereof)...
Best regards,
Niklas
[For those wanting more things to ponder: consider the role and nature
of a packet, or the essence of a byte.. ;) ]
2010/11/7 John Sheridan johnlsheri...@yahoo.com:
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 +, 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
Re: 200 OK with Content-Location might work
Hi John
Your points are good ones and some care should certainly be taken in how a
possible 200-with-content-location option should be presented to the 'outside
world'.
1) the public-lod forum is mostly aimed at practitioners, so hopefully not too
many new LODers will have been alarmed by the recent discussion. Maybe it's 5
to midnight, but better now than 5 after midnight!
2) I think you're right that it's not that hard to understand the 303 stuff,
but it *is* a pain to implement in a web server and I think that's an obstacle
to wider adoption of linked data.
3) Most on this list seem to be in agreement that the new option should be in
addition to 303 as a way of doing LOD with slash URIs and the different
approach doesn't make a great deal of difference to most LOD consuming
applications. I agree that we should try to make a quick decision on whether
to start implementing this approach. In due course it would probably be worth
reconsidering guidance notes like http://data.gov.uk/resources/uris. The
pattern of id/doc URI pairs is not needed in the 200 approach, but it may be
best to stick to recommending the /id/ pattern for data.gov.uk URIs for the
sake of consistency and continuity - not sure about that, needs some thought.
Cheers
Bill
On 7 Nov 2010, at 16: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 +, 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
Re: 200 OK with Content-Location might work
On 11/7/10 10:07 AM, 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?).
+1
We must put concept (and value prop. demonstration) before mechanics.
This mailing list isn't private, it has google-juice, and its an early
point of call re. Linked Data.
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD.
And when the dust settles, it will remain. Ian's efforts will have the
net effect of a new option, no more no less. Just an option.
Loose coupling (non authoritative) resource descriptors (information
resources) are going to be important forever.
Pubby and Virtuoso have always demonstrated the above. In the beginning
Pubby (Linked Data Document middleware) was in Berlin and the DBpedia
Quad Store in Burlington, MA. Today, via Virtuoso we still have all
sorts of options re. location of the Linked Data Docs relative to the
actual DBpedia Quad Store. This kind of flexibility is vital to Linked
Data in general.
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.
The Descriptor Document URL and Subject Name dichotomy is intuitive. It
does help new users and anyone else that's concept comprehension
oriented re. Linked Data.
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?).
This is just an option, it can never be more than an option.
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s.
I don't think 303 indirection can be depreciated. We just have another
option that full leverages the self-describing nature of RDF resources.
The mechanism for disambiguating Entity (Non Information Resource) Name
and Descriptor (Information Resource) Address is adjudicated by the data
itself.
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.
An optional evolutionary path. This is something platforms you handle
without distraction to users.
Hope these thoughts help,
Very much so :-)
Kingsley
John.
On Sun, 2010-11-07 at 14:42 +, 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
Re: 200 OK with Content-Location might work
On 11/7/10 11:17 AM, Bill Roberts wrote:
Hi John
Your points are good ones and some care should certainly be taken in how a
possible 200-with-content-location option should be presented to the 'outside
world'.
1) the public-lod forum is mostly aimed at practitioners, so hopefully not too
many new LODers will have been alarmed by the recent discussion. Maybe it's 5
to midnight, but better now than 5 after midnight!
2) I think you're right that it's not that hard to understand the 303 stuff,
but it *is* a pain to implement in a web server and I think that's an obstacle
to wider adoption of linked data.
Implementation cannot be the reason for making these changes. Linked
Data isn't about the limitations of Apache or any other server platform.
The core problem is that we have an ambiguity that needs to be resolved.
The current 303 indirection heuristic boils down to a human agreement
re., when a URI is a Name or Address. Leveraging triples in an RDF
resource basically illustrates the value of self-describing structured
data, a critical component of Linked Data value prop.
3) Most on this list seem to be in agreement that the new option should be in
addition to 303 as a way of doing LOD with slash URIs and the different
approach doesn't make a great deal of difference to most LOD consuming
applications.
Yes.
I agree that we should try to make a quick decision on whether to start
implementing this approach.
Support this approach as an option via implementation across current
handful of platforms, why not, but we still need to invest energy in:
1. emphasizing this is an option
2. non disruptive addition to existing Linked Data products
3. not making this a distraction .
In due course it would probably be worth reconsidering guidance notes like
http://data.gov.uk/resources/uris. The pattern of id/doc URI pairs is not
needed in the 200 approach, but it may be best to stick to recommending the
/id/ pattern for data.gov.uk URIs for the sake of consistency and continuity -
not sure about that, needs some thought.
Wouldn't suggest touching that at all. The URIs are in place and fully
functional.
Kingsley
Cheers
Bill
On 7 Nov 2010, at 16: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 +, 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
Re: 200 OK with Content-Location might work
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 +, 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
Re: 200 OK with Content-Location might work
On Sun, Nov 7, 2010 at 7:35 PM, Phil Archer ph...@w3.org wrote: 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. The content-location header says that the entity being sent in the response is not a representation of the resource. I don't want to get into a heavy what is a representation really debate because those have been done to minute detail over on the TAG list for many years. Suffice to say that http://www.google.com/ has a representation that is not the entire experience of the google website get that URI denotes the google website for the majoriity of people. I've been toying with the idea of including a substitution rule in a 200 header. I'd prefer not to invent anything new, e.g. new headers or status codes. I'm just looking to simplify an existing set of patterns. 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'. My proposal keeps the two separate with distinct URIs. With clear guides, education and testing tools we can encourage people to do the right thing, just like we currently do with any standard. However, philosophically I wonder whether there are any practical consequences of them being indistinguishable. When i read my email in gmail it is hard to separate the email from the webpage allowing me to read the email yet it still works. 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. It would still be available. My proposal is to provide a streamlined alternative, one that is more in line with what millions of webmasters are doing already. Ian
Re: 200 OK with Content-Location might work
moniker.
Kingsley
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 +, 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, Nathannat...@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
Re: 200 OK with Content-Location might work
How to present to the outside world? In fact, perhaps why are we doing this? People *are* doing conneg and returning 200 rdf right now, and many of us expect that this will continue and even increase, despite any instructions/recommendations to the contrary from the LOD community. So it is incumbent on us as a community to respond to this situation. Suggesting Best Practice for a 200 approach this does not undermine 303 or hash, and we continue to recommend this, especially for sites like data.gov.uk. But a clear statement about 200 helps to improve the situation by offering a common approach and preserving the distinction between NIR and IR. Clearly we are a stable community and LOD is ready for adoption if we can respond to such changes in the envirnment without breaking the existing world, while embracing new users ;-) Best Hugh
Re: 200 OK with Content-Location might work
Hi Phil! Phil Archer wrote: 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. Since this distinction is, and has been for many years, debatable, why not be pragmatic and leave this choice to the users themselves? If someone thinks that a web page consisting of a picture and a textual description is an adequate represenation of a Toucan, let them return one over HTTP (as long as they are aware that the web page itself is a different resource yada yada...). People expecting the Toucan to fly down the wire and appear at their desk might me disappointed but most users will probably be happy with the low-fidelity version. Tore Eriksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]
Re: 200 OK with Content-Location might work
On Fri, Nov 5, 2010 at 4: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! +1 This is precisely what we need. Ian
Re: 200 OK with Content-Location might work
Ian Davis wrote: On Fri, Nov 5, 2010 at 4: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! +1 This is precisely what we need. The jury's still you on this one though, see: http://markmail.org/message/u4yctkaj2i3pms2o
Re: 200 OK with Content-Location might work
On 11/6/10 8:11 AM, Ian Davis wrote: On Fri, Nov 5, 2010 at 4:55 PM, Nathannat...@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! +1 This is precisely what we need. Ian All, So we have arrived at a destination that's mutually inclusive re. 303 indirection. Basically, an additional technique that uses Content-Location as the switch. Nice, simple, clean, and shouldn't break a thing, as long as people stop producing old school RDF resources. In addition, I think we've also triggered a POWDER fix that's been long overlooked. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
On 11/6/10 9:05 AM, Nathan wrote: Ian Davis wrote: On Fri, Nov 5, 2010 at 4: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! +1 This is precisely what we need. The jury's still you on this one though, see: http://markmail.org/message/u4yctkaj2i3pms2o Nathan, Aren't juries about peers? In this case, aren't the peers those that publish and consume Linked Data? I think practitioners make this call :-) Leigh: yes, indeed, Linked Data Practitioners :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
On 11/6/10 12:41 PM, Bill Roberts wrote: On 6 Nov 2010, at 17:25, Kingsley Idehen wrote: All, So we have arrived at a destination that's mutually inclusive re. 303 indirection. Basically, an additional technique that uses Content-Location as the switch. Nice, simple, clean, and shouldn't break a thing, as long as people stop producing old school RDF resources. In addition, I think we've also triggered a POWDER fix that's been long overlooked. +1. (just to clarify: what do you mean exactly by old school RDF resources?) Defining attributes: 1. missing isDefinedby, isDescribedBy, describedBy assertions 2. do not use resolvable URIs (in Subject or Predicate slots) :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
POWDER Fix on wdrs:describedby (was Re: 200 OK with Content-Location might work)
On 06/11/2010 16:25, Kingsley Idehen wrote: [snip] In addition, I think we've also triggered a POWDER fix that's been long overlooked. And I'm grateful that it's come to my attention (wish I'd recognised the problem a lot earlier :-() I've made a proposal internally (at W3C) that I want to run past at least one or two of the former POWDER WG members to make sure they're happy (one in particular). If that goes as hoped then there could be an erratum published as soon as Monday (8th) that would be become part of an edited Recommendation before long (maybe in the new year). Bottom line is that wdrs:describedby was intended to be semantically identical to @rel describedby, i.e. with no range restriction. Since the Recommendation and namespace doc in the their present form are ambiguous it's clearly an error so making an entry on the errata page [1] is pretty straightforward. Once that's done there'll be a bit of outreach work to do on that. Getting the actual Rec edited takes a bit more 'process' but it's doable. (Fundamental rule about docs published in TR space at w3.org is that the bytes don't change. Editing means publishing a new version.) I think the chances of there being an implementation that infers that the object of a wdrs:describedby predicate is a wdrs:Document is vanishingly small but, on the off chance anyone knows of such an implementation, please let me know. (Incidentally, editing the Rec should also help us get the POWDER MIME type registered but that's orthogonal to the current discourse). Phil [1] http://www.w3.org/2007/powder/powder-errata -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org @philarcher1
200 OK with Content-Location might work
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
200 OK with Content-Location might work: But maybe it can be simpler?
How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. as a baseline think someone wanting to annotate with RDFa a hand crafted, apached served html file. really.. as simple as serving this people. as simple as anyone who's using opengraph just copy pastes into their HTML template.. as simple as this really, please, its the only thing that can work? Giovanni 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
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
Le 05/11/2010 18:25, Giovanni Tummarello a écrit : How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. Solutions to technical problems are not for little kids, grandmothers and casual Web users. Getting a Web page on the Web is actually really complex, you have to do a lot of stuff with the header, maybe content-negociate etc. Yet, little kids and grandmothers can jump from webpages to webpages. as a baseline think someone wanting to annotate with RDFa a hand crafted, apached served html file. really.. as simple as serving this people. Yep, implement the HTTP header stuff in the RDFa editor and it becomes as simple as web browsing 101. as simple as anyone who's using opengraph just copy pastes into their HTML template.. as simple as this really, please, its the only thing that can work? The complexity of a technical solution has really nothing to do with the difficulty of using the solution. Don't worry Gio, this technicality (if it's ever implemented) won't make Sindice and Sig.ma less user-friendly ;) Giovanni Cheers, AZ. On Fri, Nov 5, 2010 at 5:55 PM, Nathannat...@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 -- Antoine Zimmermann Researcher at: Laboratoire d'InfoRmatique en Image et Systèmes d'information Database Group 7 Avenue Jean Capelle 69621 Villeurbanne Cedex France Lecturer at: Institut National des Sciences Appliquées de Lyon 20 Avenue Albert Einstein 69621 Villeurbanne Cedex France antoine.zimmerm...@insa-lyon.fr http://zimmer.aprilfoolsreview.com/
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
On 05/11/10 17:26, Nathan wrote: Giovanni Tummarello wrote: How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. as a baseline think someone wanting to annotate with RDFa a hand crafted, apached served html file. really.. as simple as serving this people. as simple as anyone who's using opengraph just copy pastes into their HTML template.. as simple as this really, please, its the only thing that can work? +1 from me - all this /slash uri and 303 nonsense, now other codes and any form of HTTP awareness is best completely removed. uri#frag gives us that semantic indirection we need, without anybody even noticing (and allows 200 OK). What about 404 ;-) ? What about http://iandavis.com/2010/303/toucan#FredFlintstone Best, Nathan -- Robert Fuller Research Associate Sindice Team DERI, Galway http://sindice.com/
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
Robert Fuller wrote: On 05/11/10 17:26, Nathan wrote: Giovanni Tummarello wrote: How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. as a baseline think someone wanting to annotate with RDFa a hand crafted, apached served html file. really.. as simple as serving this people. as simple as anyone who's using opengraph just copy pastes into their HTML template.. as simple as this really, please, its the only thing that can work? +1 from me - all this /slash uri and 303 nonsense, now other codes and any form of HTTP awareness is best completely removed. uri#frag gives us that semantic indirection we need, without anybody even noticing (and allows 200 OK). What about 404 ;-) ? What about http://iandavis.com/2010/303/toucan#FredFlintstone both equate to afaict - no information about whatever, or whether whatever exists yet another benefit, all status codes have no meaning since 'frags aren't in the domain of HTTP, and if you don't have a description in RDF you don't a description, nothing said nothing known, no problem.
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
I'm wondering about the implications of the httpRange-14 decision. In summary, it says: a) if it's 2xx, then it's an information resource; b) if it's 303, then it's whatever; c) if it's 4xx, then it's whatever. First, I'm wondering what is the difference between b) and c). Second, I'm wondering what it implies for other codes, such as 3xx and 5xx. And what about URIs that do not resolve (like hash-URIs)? It seems to me that the absence of specification for these codes means that the URIs may mean whatever. So, is it correct to interpret httpRange-14 as follows: a) if a GET request returns 2xx on a URI then the URI denotes an information resource; b) a URI can be any kind of resource otherwise. Regards, -- Antoine Zimmermann Researcher at: Laboratoire d'InfoRmatique en Image et Systèmes d'information Database Group 7 Avenue Jean Capelle 69621 Villeurbanne Cedex France Lecturer at: Institut National des Sciences Appliquées de Lyon 20 Avenue Albert Einstein 69621 Villeurbanne Cedex France antoine.zimmerm...@insa-lyon.fr http://zimmer.aprilfoolsreview.com/
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
On Fri, Nov 5, 2010 at 5:33 PM, Antoine Zimmermann antoine.zimmerm...@insa-lyon.fr wrote: Le 05/11/2010 18:25, Giovanni Tummarello a écrit : How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. Solutions to technical problems are not for little kids, grandmothers and casual Web users. Getting a Web page on the Web is actually really complex, you have to do a lot of stuff with the header, maybe content-negociate etc. Yet, little kids and grandmothers can jump from webpages to webpages. Apparently Ian achieved his example on Apache by simply dropping in toucan.rdf and letting apache handle the rest with +MultiViews m...@foobar:~$ curl -v http://iandavis.com/2010/303/toucan GET /2010/303/toucan HTTP/1.1 HTTP/1.1 200 OK Server: Apache/2.2.8 (Ubuntu) Content-Location: toucan.rdf Cheers, Mike
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
Mike Kelly wrote: On Fri, Nov 5, 2010 at 5:33 PM, Antoine Zimmermann antoine.zimmerm...@insa-lyon.fr wrote: Le 05/11/2010 18:25, Giovanni Tummarello a écrit : How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. Solutions to technical problems are not for little kids, grandmothers and casual Web users. Getting a Web page on the Web is actually really complex, you have to do a lot of stuff with the header, maybe content-negociate etc. Yet, little kids and grandmothers can jump from webpages to webpages. Apparently Ian achieved his example on Apache by simply dropping in toucan.rdf and letting apache handle the rest with +MultiViews m...@foobar:~$ curl -v http://iandavis.com/2010/303/toucan GET /2010/303/toucan HTTP/1.1 HTTP/1.1 200 OK Server: Apache/2.2.8 (Ubuntu) Content-Location: toucan.rdf Mike, that's the normal pattern for deploy #frag based linked data, stick it all in files, then Options +MultiViews to enable conneg. The main difference here is that HTTP denotes some meaning over all representations with status codes (its in HTTPs domain), other than 303 which cancels that and let's us say something is what we say it is. However, frag URIs completely skirt around and void this issue, you can whatever code you like with them, as they aren't the URIs you GET. Whereas /slash does not. Many have been doing the frag approach successfully and simply with zero issues and staying clear of HTTP semantics while getting the benefit for years by using frag URIs. Best, Nathan
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
On Nov 5, 2010, at 1:23 PM, Nathan wrote: Mike Kelly wrote: On Fri, Nov 5, 2010 at 5:33 PM, Antoine Zimmermann antoine.zimmerm...@insa-lyon.fr wrote: Le 05/11/2010 18:25, Giovanni Tummarello a écrit : How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. Solutions to technical problems are not for little kids, grandmothers and casual Web users. Getting a Web page on the Web is actually really complex, you have to do a lot of stuff with the header, maybe content-negociate etc. Yet, little kids and grandmothers can jump from webpages to webpages. Apparently Ian achieved his example on Apache by simply dropping in toucan.rdf and letting apache handle the rest with +MultiViews m...@foobar:~$ curl -v http://iandavis.com/2010/303/toucan GET /2010/303/toucan HTTP/1.1 HTTP/1.1 200 OK Server: Apache/2.2.8 (Ubuntu) Content-Location: toucan.rdf Mike, that's the normal pattern for deploy #frag based linked data, stick it all in files, then Options +MultiViews to enable conneg. The main difference here is that HTTP denotes some meaning over all representations with status codes (its in HTTPs domain), other than 303 which cancels that and let's us say something is what we say it is. However, frag URIs completely skirt around and void this issue, you can whatever code you like with them, as they aren't the URIs you GET. Whereas /slash does not. Many have been doing the frag approach successfully and simply with zero issues and staying clear of HTTP semantics while getting the benefit for years by using frag URIs. But others have had success using the 303 approach consistently, eg dbpedia with its /resource/foo redirecting to /page/foo. And the frag approach does have its issues, most notably that almost the entire Web machinery has a kind of blanket permission to strip off the frags, since they are supposed to have no meaning outside the state of the sender. True this doesn't seem to matter in practice, but it is slightly worrying. Pat Best, Nathan IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: 200 OK with Content-Location might work: But maybe it can be simpler?
Pat Hayes wrote: On Nov 5, 2010, at 1:23 PM, Nathan wrote: Mike Kelly wrote: On Fri, Nov 5, 2010 at 5:33 PM, Antoine Zimmermann antoine.zimmerm...@insa-lyon.fr wrote: Le 05/11/2010 18:25, Giovanni Tummarello a écrit : How about something that's totally independant from HEADER issues? think normal people here. absolutely 0 interest to mess with headers and http responses.. absolutely no business incentive to do it. Solutions to technical problems are not for little kids, grandmothers and casual Web users. Getting a Web page on the Web is actually really complex, you have to do a lot of stuff with the header, maybe content-negociate etc. Yet, little kids and grandmothers can jump from webpages to webpages. Apparently Ian achieved his example on Apache by simply dropping in toucan.rdf and letting apache handle the rest with +MultiViews m...@foobar:~$ curl -v http://iandavis.com/2010/303/toucan GET /2010/303/toucan HTTP/1.1 HTTP/1.1 200 OK Server: Apache/2.2.8 (Ubuntu) Content-Location: toucan.rdf Mike, that's the normal pattern for deploy #frag based linked data, stick it all in files, then Options +MultiViews to enable conneg. The main difference here is that HTTP denotes some meaning over all representations with status codes (its in HTTPs domain), other than 303 which cancels that and let's us say something is what we say it is. However, frag URIs completely skirt around and void this issue, you can whatever code you like with them, as they aren't the URIs you GET. Whereas /slash does not. Many have been doing the frag approach successfully and simply with zero issues and staying clear of HTTP semantics while getting the benefit for years by using frag URIs. But others have had success using the 303 approach consistently, eg dbpedia with its /resource/foo redirecting to /page/foo. And the frag approach does have its issues, most notably that almost the entire Web machinery has a kind of blanket permission to strip off the frags, since they are supposed to have no meaning outside the state of the sender. True this doesn't seem to matter in practice, but it is slightly worrying. Issue or semantic-indirection enabling feature? is the big question I guess, yet to see any evidence that is an issue, however many people who's judgement I trust seem to have a gut instinct frags aren't good. But perhaps that's for another day. I've hit my bandwidth + signal to noise ratio for today about 5 hours ago. Best, Nathan
