On Thu, 2012-03-29 at 11:55 +0900, トーレ エリクソン wrote:
[ . . . ]
If we agree that
_:a a rdfs:Class;
rdfs:comment the set of things which can have
their representations retrieved via HTTP;
owl:equivalentClass rdfs:Resource.
the interface between the web and the
Jeni Tennison wrote:
# Details
In section 4.1, in place of the second paragraph and following list, substitute:
There are three ways to locate a URI documentation link in an HTTP response:
* using the Location: response header of a 303 See Other response [httpbis-2],
e.g.
Nathan wrote:
Jeni Tennison wrote:
# Details
In section 4.1, in place of the second paragraph and following list,
substitute:
There are three ways to locate a URI documentation link in an HTTP
response:
* using the Location: response header of a 303 See Other response
[httpbis-2],
Nathan,
Yes, that's correct. With no constraining Accept headers, it could
alternatively return HTML with embedded RDFa with a link rel=describedby
element, for example.
Either way, there is no implication that what you've got from
http://example.org/uri is the content of
Jeni Tennison wrote:
Nathan,
Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML
with embedded RDFa with a link rel=describedby element, for example.
Is that universally true?
Suppose /uri identified a PDF formatted ebook, or a digital image of a
Nathan,
On 28 Mar 2012, at 16:07, Nathan wrote:
Jeni Tennison wrote:
Yes, that's correct. With no constraining Accept headers, it could
alternatively return HTML with embedded RDFa with a link rel=describedby
element, for example.
Is that universally true?
Suppose /uri identified a
Jeni Tennison wrote:
Nathan,
On 28 Mar 2012, at 16:07, Nathan wrote:
Jeni Tennison wrote:
Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML
with embedded RDFa with a link rel=describedby element, for example.
Is that universally true?
Suppose /uri
On 3/28/12 12:12 PM, Jeni Tennison wrote:
The fact that a 200 OK determines whether something is a member of Set-A or
Set-B is a design choice made by httpRange-14, not a fundamental truth of the universe.
The proposal makes a different design choice, in saying that you need more than just a
Nathan,
The server *can* return the same content from the /uri URI and from the
/uri-documentation URI, but it does not have to, and it wouldn't be sensible to
do so for an image. Your first question asked if the server could return the
same content, your second asked if it must.
Jeni
--
Sent
Jeni,
First, thanks for confirming - many responses in line from here:
Jeni Tennison wrote:
The server *can* return the same content from the /uri URI and from
the /uri-documentation URI, but it does not have to, and it wouldn't
be sensible to do so for an image. Your first question asked if
Apologies but I have to disagree completely here, I can say I'm a
goldfish but I have the properties of a human and belong in the Set of
Humans, no matter how much I say, I'm never going to be a goldfish -
there's no design choice there, similarly if something a representation
of
Thus far the posts on this subject (at least, those I have taken the
time to scan/read) concentrate on the issue from the publisher's
perspective. Is there a description anywhere of how this change will
impact on clients for this data?
For example, in order to be able to access Linked Data
Hi,
Please find below a Change Proposal for the consideration of the TAG in
response to [1] on behalf of (alphabetically):
Ian Davis
Leigh Dodds
Nick Gibbins (University of Southampton)
Hugh Glaser
Steve Harris
Masahide Kanzaki
Gregg Kellogg
Niklas Lindström
Jerry Persons
Dave Reynolds
Bill
Noah,
On 25 Mar 2012, at 19:39, Noah Mendelsohn wrote:
(commenting now as a technical contributor to the TAG)
On 3/25/2012 5:47 AM, Jeni Tennison wrote:
a 200 response to a probe URI no longer by itself implies that the probe
URI identifies an information resource or that the response is a
On 2012-03 -25, at 14:39, Noah Mendelsohn wrote:
(commenting now as a technical contributor to the TAG)
On 3/25/2012 5:47 AM, Jeni Tennison wrote:
a 200 response to a probe URI no longer by itself implies that the probe
URI identifies an information resource or that the response is a
On 3/25/2012 3:29 PM, Jeni Tennison wrote:
I assume it's the most common case, but my reading of 303 is that it's intentionally
pretty vague. I read it as: you might find something useful over here -- feel free
to do a GET and see what happens. In fact, I'm not sure it's even clear that 303
On 3/25/2012 3:37 PM, Tim Berners-Lee wrote:
x 303 - y means y is a description of x and therefore y is an
information resource.
My point is: that's a perfectly coherent definition for 303 in principle,
but I don't read RFC 2616 as saying that. I read RFC 2616 as saying, If
you were
On Sun, Mar 25, 2012 at 4:50 PM, Noah Mendelsohn n...@arcanedomain.com wrote:
On 3/25/2012 3:29 PM, Jeni Tennison wrote:
I assume it's the most common case, but my reading of 303 is that it's
intentionally pretty vague. I read it as: you might find something useful
over here -- feel free to
On 3/25/2012 5:15 PM, Jonathan A Rees wrote:
The baseline starts from HTTPbis, not 2616.
OK.
I have confidence in HTTPbis. It is the wave of the future.
Yes, but I'm suggesting that the definition of 303 in HTTPbis should
(maybe) clarify, but not incompatibly change the definition from
Noah,
As far as I can tell, the latest version of the relevant part of RFC2616bis is
at [1] and contains the definition for 303 that is:
---
7.3.4 303 See Other
The 303 status code indicates that the server is redirecting the user agent to
a different resource, as indicated by a URI in the
On 2012-03 -25, at 16:53, Noah Mendelsohn wrote:
On 3/25/2012 3:37 PM, Tim Berners-Lee wrote:
x 303 - y means y is a description of x and therefore y is an
information resource.
My point is: that's a perfectly coherent definition for 303 in principle, but
I don't read RFC 2616 as
21 matches
Mail list logo
