Re: Is 303 really necessary?
Hi, I found Alternative to 303 response: Description-ID: header[1] in the TAG mailing list archive. Are there any parallels? ;) Cheers, Bob PS: maybe someone has already mentioned this source here, however, I didn't find any reference [1] http://lists.w3.org/Archives/Public/www-tag/2007Dec/0024.html
Re: Is 303 really necessary?
On Sat, 2010-11-27 at 15:24 -0500, Tim Berners-Lee wrote: Sorry, this thread has been around but the public-lod list snuck up on me without my getting on it, so I have missed some of the fray! I am happy to look at improvements in the current HTTPRange 14 architecture as I know that 303 is a pain. But I don't want to break the web. Looking at http://bnb.bibliographica.org/entry/GB8102507 the tabulator concludes that the thing identified by it is both a book and an RDF document, and it shows me, by default, the triples it contains instead of the information about it, because that is what as a user I want. It doesn't use this new idea from IanD of using the content-location header as flag to indicate that the URI you used in the GET request may NOT be used to refer to the document returned. Suppose we go along with this new idea. Then, it will end up with (ignoring namespaces) in N3 the information we get from that fetch includes: http://bnb.bibliographica.org/entry/GB8102507 a Book; contributor [name Boyd, William]. http://bnb.bibliographica.org/entry/GB8102507.rdf a DataDocument; foaf:primaryTopic http://bnb.bibliographica.org/entry/GB8102507. Ok, I understand the system. But if you introduce this as the architecture of the web, then it applies all the time. You can't chose when it applies and when it doesn't. Now look at http://www.w3.org/2008/site/images/logo-w3c-mobile-lg This dereferenced to give you a content-location of http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png What do we know then? http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png we know we can use to refer to the image in its PNG version. http://www.w3.org/2008/site/images/logo-w3c-mobile-lg we know nothing about. Because the fetch returned a content-location header, we are now not allowed to use that URI to refer to anything -- it could after all refer to the Eiffel Tour, or the W3C as an organization according to the new system. Does this make sense? If you look that up in a browser, you will see the image in the window and the URI in the title bar. We in fact really expect that people SHOULD use the generic URI http://www.w3.org/2008/site/images/logo-w3c-mobile-lg; to refer to the logo, not the .png URI, as people may need the content negotiation, and we may introduce a new version in a new graphics format some time. So all across the web, people are, and should use the original URI to refer to the image. Tthey see something in the URI bar and a document (image, etc) in the window and they assume rightly they can use that URI to refer to that image. The bookmarking system works like this. Emailing a friend a URI of something you are looking at works like this. Making a link to something you think it cool works like this. Putting a image in your page someone else has in their page works like this. The web works like this. We can't make the semantic web work in a way that actually leaves the web not working. We can't leave the WWW working one way and the LOD web working another, as they are inextricably interconnected. Now Someone in the the thread somewhere at one point suggested a friendly amendment to the original proposal, where a new status code is sent for semantic web data being returned *about* the object identified by the request URI, rather than information *in* it. I think 208 was suggested, I.e, the next unused one. With that modification, I can't see a snag. - It is only used for data so old web browsers are not going to be seeing it - The data world is young enough for us to slide it in, maybe, without too much harm to existing clients, which would all have to be recoded, but it might be worth it to relieve this tension. - the rest of the web continue to use 200 Tim Hi Tim, I think much of your argument against using 200 can be extended for using any 200 series status code. Representations that merely describe a resource (and don't completely represent it) cause ambiguity because Web browsers today interpret all 200 series responses (from a GET request) as containing an complete representation of the resource identified in the request URL. Even though this behaviour is not in the spec, Web browser behave this way today. As you said, people (and browsers) use the URL in the address bar as an identifier for the document below it (in GET requests). Even if tomorrow the spec said responses with status code 208 do not represent the resource identified in the GET request URL, it would leave today's browsers not working. Furthermore, Web browser vendors would never agree to show the Content-Location URL in the address bar due to security/authority concerns. Any solution that causes today's Web browsers to show a URL in the address bar (from a GET request) which does not identify the document below,
Re: Is 303 really necessary?
* [2010-11-27 15:24:53 -0500] Tim Berners-Lee ti...@w3.org écrit: ] http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png ] we know we can use to refer to the image in its PNG version. ] http://www.w3.org/2008/site/images/logo-w3c-mobile-lg ] we know nothing about. ] ] Because the fetch returned a content-location header, ] we are now not allowed to use that URI to refer to anything -- it could ] after all refer to the Eiffel Tour, or the W3C as an organization ] according to the new system. ] ] Does this make sense? Yes and no. I see the distinction between representation and description, but I don't think the line is necessarily so sharp. For example, you could make http://www.w3.org/2008/site/images/logo-w3c-mobile-lg respond with, The W3C logo, white text on a teal background the characters W and 3 apparently raised and C apparently sunken. It is the large version of the logo intended for use with mobile browsers. when asked for text/plain (pace alt). Maybe this is useful for blind people. For them it functions as a representation but is written using descriptive language. I could imagine formalising the descriptive language in RDF and returning that when asked for a different content-type. Maybe I should do some background reading in semiotics to get this clearer in my mind. In the meantime, % curl -I http://bnb.bibliographica.org/entry/GB5105626 HTTP/1.0 303 See Other Server: nginx/0.7.65 Date: Sat, 27 Nov 2010 23:44:54 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 0 Pragma: no-cache Cache-Control: no-cache Vary: Accept Location: http://bnb.bibliographica.org/entry/GB5105626.rdf X-Cache: MISS from localhost X-Cache-Lookup: MISS from localhost:80 Via: 1.0 localhost (squid/3.0.STABLE19) Connection: close Cheers, -w -- William Waites http://eris.okfn.org/ww/foaf#i 9C7E F636 52F6 1004 E40A E565 98E3 BBF3 8320 7664
Re: Is 303 really necessary?
- the rest of the web continue to use 200 Tim yes but the rest of the web will use 200 also to show what we would consider 208, e.g. http://www.rottentomatoes.com/celebrity/antonio_banderas/ see the trilples http://inspector.sindice.com/inspect?url=http://www.rottentomatoes.com/celebrity/antonio_banderas/#TRIPLES http://www.rottentomatoes.com/celebrity/antonio_banderas/ is clearly a web page but its also an actor, it is pointed by their graph in other pages as such and the same page contains the opengraph triple type actor We should not get ourself in the position to have to try to evangelize all to change something for reasons that are really not apparent to your normal web world. I think the solution we should be seeking consider RDFa publishing via normal 200 code as the example above absolutely ok an agent would then be able to distinguish which properties apply to the page and which to the actor looking at the.. properties themselves i guess? sad but possibly unavoidable? Giovanni
Re: Is 303 really necessary?
On 11/28/2010 02:52 PM, Giovanni Tummarello wrote: - the rest of the web continue to use 200 Tim yes but the rest of the web will use 200 also to show what we would consider 208, e.g. http://www.rottentomatoes.com/celebrity/antonio_banderas/ see the trilples http://inspector.sindice.com/inspect?url=http://www.rottentomatoes.com/celebrity/antonio_banderas/#TRIPLES http://www.rottentomatoes.com/celebrity/antonio_banderas/ is clearly a web page but its also an actor, it is pointed by their graph in other pages as such and the same page contains the opengraph triple type actor We should not get ourself in the position to have to try to evangelize all to change something for reasons that are really not apparent to your normal web world. I think the solution we should be seeking consider RDFa publishing via normal 200 code as the example above absolutely ok an agent would then be able to distinguish which properties apply to the page and which to the actor looking at the.. properties themselves i guess? sad but possibly unavoidable? Giovanni Hi, I agree with this. This problem is caused that Linked Data conflates identifiers with locators - important is that one can get information about a unique name, by using it as a locator. The issue whether some events in the process or outcome of the information retrieval somehow should affect users perception of the name (is it a document or xyz?) is a can of worms most implementers don't want to tackle and they have a point. I don't want to maintain all apps I once coded so they support whatever is the latest HTTP semantics trend is, when there is a widely used standard for extensible, *evolvable* information representation (RDF) which I am already expecting to receive about the name I am retrieving info about. So lets not presume that by dereferencing an URI and getting back a document, the URI is the documents identifier - it is its locator. It can be its identifier too, but lets leave that for publishers to decide - that has been the point of my previous post on the topic ( http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html ) Best regards, Jiří Procházka signature.asc Description: OpenPGP digital signature
Facebook OpenGraphProtocol (was Re: Is 303 really necessary?)
Giovani,
When you say the rest of the web, this issue is specifically one
with Facebook Open Graph Protocol, which i a new development.
When you look at the triples
http://inspector.sindice.com/inspect?url=http://www.rottentomatoes.com/celebrity/antonio_banderas/#TRIPLES
(Nice view)
the you get many triples about the page, like
http://www.rottentomatoes.com/celebrity/antonio_banderas/
http://www.w3.org/1999/xhtml/vocab#stylesheet
http://images.rottentomatoescdn.com/files/inc_beta/css/2.0.0/header_v2.css?v=glo20101121
.
This clearly is about the document.
(I don' think it is very interesting as data, so defining it to be part of the
RDF triples of a document without the alternative of a more constrained set
is another issue.)
The ones which are from the OGP are like
http://www.rottentomatoes.com/celebrity/antonio_banderas/
http://opengraphprotocol.org/schema/type actor .
There are of course various ways of mapping this to what you and
would have probably coded up.
1) One way if to just recognize that the
predicates in the OGP are relations to the page.
{ ?page fb:image ?x. ?page foaf:primarySubject ?y } = { ?y foaf:image ?x }.
and that is not the end of the world.
But it is consistent.
2) There is another way, and that is to make a new RDFA syntax really easy to
add triples specifically about the subject of the page.
Note that the 303/208 issue is separate to this. This OGP problem remains if
you use 208 or 200)
Tim
On 2010-11 -28, at 08:52, Giovanni Tummarello wrote:
- the rest of the web continue to use 200
Tim
yes but the rest of the web will use 200 also to show what we would
consider 208, e.g.
http://www.rottentomatoes.com/celebrity/antonio_banderas/
see the trilples
http://inspector.sindice.com/inspect?url=http://www.rottentomatoes.com/celebrity/antonio_banderas/#TRIPLES
http://www.rottentomatoes.com/celebrity/antonio_banderas/
is clearly a web page but its also an actor, it is pointed by their
graph in other pages as such and the same page contains the opengraph
triple type actor
We should not get ourself in the position to have to try to evangelize
all to change something for reasons that are really not apparent to
your normal web world. I think the solution we should be seeking
consider RDFa publishing via normal 200 code as the example above
absolutely ok
an agent would then be able to distinguish which properties apply to
the page and which to the actor looking at the.. properties
themselves i guess? sad but possibly unavoidable?
No, absolutely horrible.
A total disaster IMHO.
Think how many properties of a library catalog card and a book both have.
What do you do with these triples
a Book.
a CardCatalog.
creator people:AGEdelan3.
creator people:HSWhite23.
length 1052.
length 105675.
That way lies madness.
Giovanni
Re: Is 303 really necessary?
On 11/28/10 9:46 AM, Jiří Procházka wrote: On 11/28/2010 02:52 PM, Giovanni Tummarello wrote: - the rest of the web continue to use 200 Tim yes but the rest of the web will use 200 also to show what we would consider 208, e.g. http://www.rottentomatoes.com/celebrity/antonio_banderas/ see the trilples http://inspector.sindice.com/inspect?url=http://www.rottentomatoes.com/celebrity/antonio_banderas/#TRIPLES http://www.rottentomatoes.com/celebrity/antonio_banderas/ is clearly a web page but its also an actor, it is pointed by their graph in other pages as such and the same page contains the opengraph triple type actor We should not get ourself in the position to have to try to evangelize all to change something for reasons that are really not apparent to your normal web world. I think the solution we should be seeking consider RDFa publishing via normal 200 code as the example above absolutely ok an agent would then be able to distinguish which properties apply to the page and which to the actor looking at the.. properties themselves i guess? sad but possibly unavoidable? Giovanni Hi, I agree with this. This problem is caused that Linked Data conflates identifiers with locators - important is that one can get information about a unique name, by using it as a locator. Linked Data (meme or actual concept) doesn't conflate Locators with Identifiers. A URI is a generic Identifier. A URL (a Locator / Address) is an Identifier. The problem remains in not understanding the URI abstraction. One issue you can't tack on Linked Data is failure to distinguish between a Name Reference and an Address Reference implemented via elegance of URI abstraction. The issue whether some events in the process or outcome of the information retrieval somehow should affect users perception of the name (is it a document or xyz?) is a can of worms most implementers don't want to tackle and they have a point. It wasn't a can of worms before the Web. The issue of Resource in URI [1] has lead to overloading that creates the illusion you describe, across many quarters and their associated commentators. I don't want to maintain all apps I once coded so they support whatever is the latest HTTP semantics trend is, when there is a widely used standard for extensible, *evolvable* information representation (RDF) which I am already expecting to receive about the name I am retrieving info about. So lets not presume that by dereferencing an URI and getting back a document, the URI is the documents identifier - it is its locator. Yes, it's the URL of a Document, and if the content-type is one of the RDF formats, or any other syntax for representing EAV model structured data -- via hypermedia -- then its the URL of a Entity Descriptor Document -- a document that provides a full representation of its Subject via a Description expressed in a Graph Pictorial comprised of Attribute=Value pairs coalesced around Subject Name (an Resolvable Identifier e..g an HTTP URI). It can be its identifier too, but lets leave that for publishers to decide - that has been the point of my previous post on the topic ( http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html ) If you mean, let the publisher decide via Content and Mime Type what this is about, then emphatic YES!! Tim: if we add 208 to the mix, it still doesn't break anything. Personally, it just adds an option for Linked Data Server developers that balances out the User Agent oriented nature (heuristics wise) of Ian's suggestion. Thus, I can easily have 208 handling added to Virtuoso to compliment what's being done on the client side re., content-type and eventual content interpretation re., Linked Data document generation i.e., browse-able pages and hypermedia based structured data representation . Links: 1. http://lists.w3.org/Archives/Public/www-tag/2009Aug/.html -- TimBL's own account re. origins of Resource in URI. This is the problem!! Best regards, Jiří Procházka -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Simpler alternative of Linked Data semantics (was Re: Is 303 really necessary?)
On 11/28/2010 06:45 PM, Kingsley Idehen wrote: On 11/28/10 9:46 AM, Jiří Procházka wrote: snip This problem is caused that Linked Data conflates identifiers with locators - important is that one can get information about a unique name, by using it as a locator. Linked Data (meme or actual concept) doesn't conflate Locators with Identifiers. A URI is a generic Identifier. A URL (a Locator / Address) is an Identifier. The problem remains in not understanding the URI abstraction. One issue you can't tack on Linked Data is failure to distinguish between a Name Reference and an Address Reference implemented via elegance of URI abstraction. The issue whether some events in the process or outcome of the information retrieval somehow should affect users perception of the name (is it a document or xyz?) is a can of worms most implementers don't want to tackle and they have a point. It wasn't a can of worms before the Web. The issue of Resource in URI [1] has lead to overloading that creates the illusion you describe, across many quarters and their associated commentators. I don't want to maintain all apps I once coded so they support whatever is the latest HTTP semantics trend is, when there is a widely used standard for extensible, *evolvable* information representation (RDF) which I am already expecting to receive about the name I am retrieving info about. So lets not presume that by dereferencing an URI and getting back a document, the URI is the documents identifier - it is its locator. Yes, it's the URL of a Document, and if the content-type is one of the RDF formats, or any other syntax for representing EAV model structured data -- via hypermedia -- then its the URL of a Entity Descriptor Document -- a document that provides a full representation of its Subject via a Description expressed in a Graph Pictorial comprised of Attribute=Value pairs coalesced around Subject Name (an Resolvable Identifier e..g an HTTP URI). It can be its identifier too, but lets leave that for publishers to decide - that has been the point of my previous post on the topic ( http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html ) If you mean, let the publisher decide via Content and Mime Type what this is about, then emphatic YES!! That is the option which was promoted till now, but some people chose not to oblige for whatever reason and judging by the amount of discussions about it, it is a problem. If publisher makes available structured data about some concept at an URI he probably means the URI identifies the concept, not the data documents, and I think if one wants to use that data, he needs to try to understand the publisher, not tell him he is wrong because [insert XX pages of HTTP URI semantics], however flawed neglecting the standards you may consider to be - welcome the Linked Data (tag^H^H^Hstatus-code-)soup. I'm fond of RDFs take on URIs == names. What I mean is: a) letting publisher decide which name is for document and relations between them, which for concepts. On dereferencing (200 returned), not to think hmm yup, this definitely must be name for a document, but hmm I dereferenced this URI and got back some document - the document exists, but it's name isn't specified - like blank node, with similar drawbacks, thus: b) letting the publisher decide that not via Content and Mime Type, but in the structured data itself, because that is most probably what the consumer will be able to parse and understand anyway and there exists a well established standard Resource Description Framework for it which fulfills more of this great document ( http://www.w3.org/DesignIssues/Evolution.html ) than HTTP, which isn't a one ring to rule the all transport protocols. (Other data formats than RDF should have equivalent ways of expressing that too.) This practice doesn't need to be standardized. You and me can use it now if we wish. It has both advantages, covering wider quality range of linked data, and disadvantages - suddenly all documents with no data about them have no names! Tragedy? No, we have their locators and if there is something said about the locators, we can assume it is about the document stored there, unless said otherwise by the publisher (this is the difference from the standard Linked Data perspective). This doesn't make ambiguity to go away, that is impossible since it depends on the publisher, but I believe it is a simpler, more forward compatible way to go around it, fitting more world-views. Best, Jiri snip Links: 1. http://lists.w3.org/Archives/Public/www-tag/2009Aug/.html -- TimBL's own account re. origins of Resource in URI. This is the problem!! signature.asc Description: OpenPGP digital signature
Re: Is 303 really necessary?
On Sun, 28 Nov 2010 14:52:21 +0100 Giovanni Tummarello giovanni.tummare...@deri.org wrote: is clearly a web page but its also an actor, it is pointed by their graph in other pages as such and the same page contains the opengraph triple type actor That's consistent with the definition of the og:type property. og:type is roughly equivalent to the following property chain in N3: foaf:primaryTopic!rdf:type!rdfs:label So if a page contains: og:type actor . That's equivalent to: foaf:primaryTopic [ a [ rdfs:label actor ] ] . This is similar in spirit to foaf:workplaceHomepage which could be written as a chain of ex:workplace!foaf:homepage. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Simpler alternative of Linked Data semantics (was Re: Is 303 really necessary?)
On 11/28/10 3:52 PM, Jiří Procházka wrote: On 11/28/2010 06:45 PM, Kingsley Idehen wrote: On 11/28/10 9:46 AM, Jiří Procházka wrote: snip This problem is caused that Linked Data conflates identifiers with locators - important is that one can get information about a unique name, by using it as a locator. Linked Data (meme or actual concept) doesn't conflate Locators with Identifiers. A URI is a generic Identifier. A URL (a Locator / Address) is an Identifier. The problem remains in not understanding the URI abstraction. One issue you can't tack on Linked Data is failure to distinguish between a Name Reference and an Address Reference implemented via elegance of URI abstraction. The issue whether some events in the process or outcome of the information retrieval somehow should affect users perception of the name (is it a document or xyz?) is a can of worms most implementers don't want to tackle and they have a point. It wasn't a can of worms before the Web. The issue of Resource in URI [1] has lead to overloading that creates the illusion you describe, across many quarters and their associated commentators. I don't want to maintain all apps I once coded so they support whatever is the latest HTTP semantics trend is, when there is a widely used standard for extensible, *evolvable* information representation (RDF) which I am already expecting to receive about the name I am retrieving info about. So lets not presume that by dereferencing an URI and getting back a document, the URI is the documents identifier - it is its locator. Yes, it's the URL of a Document, and if the content-type is one of the RDF formats, or any other syntax for representing EAV model structured data -- via hypermedia -- then its the URL of a Entity Descriptor Document -- a document that provides a full representation of its Subject via a Description expressed in a Graph Pictorial comprised of Attribute=Value pairs coalesced around Subject Name (an Resolvable Identifier e..g an HTTP URI). It can be its identifier too, but lets leave that for publishers to decide - that has been the point of my previous post on the topic ( http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html ) If you mean, let the publisher decide via Content and Mime Type what this is about, then emphatic YES!! That is the option which was promoted till now, but some people chose not to oblige for whatever reason and judging by the amount of discussions about it, it is a problem. If publisher makes available structured data about some concept at an URI he probably means the URI identifies the concept, not the data documents, and I think if one wants to use that data, he needs to try to understand the publisher, not tell him he is wrong because [insert XX pages of HTTP URI semantics], however flawed neglecting the standards you may consider to be - welcome the Linked Data (tag^H^H^Hstatus-code-)soup. I'm fond of RDFs take on URIs == names. What I mean is: a) letting publisher decide which name is for document and relations between them, which for concepts. On dereferencing (200 returned), not to think hmm yup, this definitely must be name for a document, but hmm I dereferenced this URI and got back some document - the document exists, but it's name isn't specified - like blank node, with similar drawbacks, thus: b) letting the publisher decide that not via Content and Mime Type, but in the structured data itself, because that is most probably what the consumer will be able to parse and understand anyway and there exists a well established standard Resource Description Framework for it which fulfills more of this great document ( http://www.w3.org/DesignIssues/Evolution.html ) than HTTP, which isn't a one ring to rule the all transport protocols. (Other data formats than RDF should have equivalent ways of expressing that too.) Yes-ish, but my point is this: 1. Publisher (owner of Linked Data Server) serves up data via Documents at URLs 2. Linked Data Client (agents) accesses data by exploiting content negotiation when de-referencing URIs (Name or Address) 3. Publisher sends Document Content to client with metadata (HTTP response headers and/or within the content via triples or head/link/ exploitation re. HTML) -- this is where Mime Type comes into play too 4. Linked Data Client processes metadata and content en route to understanding what its received. This practice doesn't need to be standardized. You and me can use it now if we wish. It has both advantages, covering wider quality range of linked data, and disadvantages - suddenly all documents with no data about them have no names! Tragedy? No, we have their locators and if there is something said about the locators, we can assume it is about the document stored there, unless said otherwise by the publisher (this is the difference from the standard Linked Data perspective). This doesn't make ambiguity to go away, that is impossible since it depends on the publisher, but
Re: Simpler alternative of Linked Data semantics (was Re: Is 303 really necessary?)
On 11/29/2010 12:48 AM, Kingsley Idehen wrote: On 11/28/10 3:52 PM, Jiří Procházka wrote: On 11/28/2010 06:45 PM, Kingsley Idehen wrote: On 11/28/10 9:46 AM, Jiří Procházka wrote: snip This problem is caused that Linked Data conflates identifiers with locators - important is that one can get information about a unique name, by using it as a locator. Linked Data (meme or actual concept) doesn't conflate Locators with Identifiers. A URI is a generic Identifier. A URL (a Locator / Address) is an Identifier. The problem remains in not understanding the URI abstraction. One issue you can't tack on Linked Data is failure to distinguish between a Name Reference and an Address Reference implemented via elegance of URI abstraction. The issue whether some events in the process or outcome of the information retrieval somehow should affect users perception of the name (is it a document or xyz?) is a can of worms most implementers don't want to tackle and they have a point. It wasn't a can of worms before the Web. The issue of Resource in URI [1] has lead to overloading that creates the illusion you describe, across many quarters and their associated commentators. I don't want to maintain all apps I once coded so they support whatever is the latest HTTP semantics trend is, when there is a widely used standard for extensible, *evolvable* information representation (RDF) which I am already expecting to receive about the name I am retrieving info about. So lets not presume that by dereferencing an URI and getting back a document, the URI is the documents identifier - it is its locator. Yes, it's the URL of a Document, and if the content-type is one of the RDF formats, or any other syntax for representing EAV model structured data -- via hypermedia -- then its the URL of a Entity Descriptor Document -- a document that provides a full representation of its Subject via a Description expressed in a Graph Pictorial comprised of Attribute=Value pairs coalesced around Subject Name (an Resolvable Identifier e..g an HTTP URI). It can be its identifier too, but lets leave that for publishers to decide - that has been the point of my previous post on the topic ( http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html ) If you mean, let the publisher decide via Content and Mime Type what this is about, then emphatic YES!! That is the option which was promoted till now, but some people chose not to oblige for whatever reason and judging by the amount of discussions about it, it is a problem. If publisher makes available structured data about some concept at an URI he probably means the URI identifies the concept, not the data documents, and I think if one wants to use that data, he needs to try to understand the publisher, not tell him he is wrong because [insert XX pages of HTTP URI semantics], however flawed neglecting the standards you may consider to be - welcome the Linked Data (tag^H^H^Hstatus-code-)soup. I'm fond of RDFs take on URIs == names. What I mean is: a) letting publisher decide which name is for document and relations between them, which for concepts. On dereferencing (200 returned), not to think hmm yup, this definitely must be name for a document, but hmm I dereferenced this URI and got back some document - the document exists, but it's name isn't specified - like blank node, with similar drawbacks, thus: b) letting the publisher decide that not via Content and Mime Type, but in the structured data itself, because that is most probably what the consumer will be able to parse and understand anyway and there exists a well established standard Resource Description Framework for it which fulfills more of this great document ( http://www.w3.org/DesignIssues/Evolution.html ) than HTTP, which isn't a one ring to rule the all transport protocols. (Other data formats than RDF should have equivalent ways of expressing that too.) Yes-ish, but my point is this: 1. Publisher (owner of Linked Data Server) serves up data via Documents at URLs 2. Linked Data Client (agents) accesses data by exploiting content negotiation when de-referencing URIs (Name or Address) 3. Publisher sends Document Content to client with metadata (HTTP response headers and/or within the content via triples or head/link/ exploitation re. HTML) -- this is where Mime Type comes into play too 4. Linked Data Client processes metadata and content en route to understanding what its received. This practice doesn't need to be standardized. You and me can use it now if we wish. It has both advantages, covering wider quality range of linked data, and disadvantages - suddenly all documents with no data about them have no names! Tragedy? No, we have their locators and if there is something said about the locators, we can assume it is about the document stored there, unless said otherwise by the publisher (this is the difference from the standard Linked Data
Re: Simpler alternative of Linked Data semantics (was Re: Is 303 really necessary?)
On 11/28/10 7:52 PM, Jiří Procházka wrote: [SNIP] Right, essentially I was pointing out the advantages of publishing the metadata in the content itself, in contrast to relying on HTTP. My bad for not realizing the role mime types can play as metadata outside of transport protocol. No problem, we're in sync :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
Sorry, this thread has been around but the public-lod list snuck up on me without my getting on it, so I have missed some of the fray! I am happy to look at improvements in the current HTTPRange 14 architecture as I know that 303 is a pain. But I don't want to break the web. Looking at http://bnb.bibliographica.org/entry/GB8102507 the tabulator concludes that the thing identified by it is both a book and an RDF document, and it shows me, by default, the triples it contains instead of the information about it, because that is what as a user I want. It doesn't use this new idea from IanD of using the content-location header as flag to indicate that the URI you used in the GET request may NOT be used to refer to the document returned. Suppose we go along with this new idea. Then, it will end up with (ignoring namespaces) in N3 the information we get from that fetch includes: http://bnb.bibliographica.org/entry/GB8102507 a Book; contributor [name Boyd, William]. http://bnb.bibliographica.org/entry/GB8102507.rdf a DataDocument; foaf:primaryTopic http://bnb.bibliographica.org/entry/GB8102507. Ok, I understand the system. But if you introduce this as the architecture of the web, then it applies all the time. You can't chose when it applies and when it doesn't. Now look at http://www.w3.org/2008/site/images/logo-w3c-mobile-lg This dereferenced to give you a content-location of http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png What do we know then? http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png we know we can use to refer to the image in its PNG version. http://www.w3.org/2008/site/images/logo-w3c-mobile-lg we know nothing about. Because the fetch returned a content-location header, we are now not allowed to use that URI to refer to anything -- it could after all refer to the Eiffel Tour, or the W3C as an organization according to the new system. Does this make sense? If you look that up in a browser, you will see the image in the window and the URI in the title bar. We in fact really expect that people SHOULD use the generic URI http://www.w3.org/2008/site/images/logo-w3c-mobile-lg; to refer to the logo, not the .png URI, as people may need the content negotiation, and we may introduce a new version in a new graphics format some time. So all across the web, people are, and should use the original URI to refer to the image. Tthey see something in the URI bar and a document (image, etc) in the window and they assume rightly they can use that URI to refer to that image. The bookmarking system works like this. Emailing a friend a URI of something you are looking at works like this. Making a link to something you think it cool works like this. Putting a image in your page someone else has in their page works like this. The web works like this. We can't make the semantic web work in a way that actually leaves the web not working. We can't leave the WWW working one way and the LOD web working another, as they are inextricably interconnected. Now Someone in the the thread somewhere at one point suggested a friendly amendment to the original proposal, where a new status code is sent for semantic web data being returned *about* the object identified by the request URI, rather than information *in* it. I think 208 was suggested, I.e, the next unused one. With that modification, I can't see a snag. - It is only used for data so old web browsers are not going to be seeing it - The data world is young enough for us to slide it in, maybe, without too much harm to existing clients, which would all have to be recoded, but it might be worth it to relieve this tension. - the rest of the web continue to use 200 Tim Some headers fro URIs above: $ curl -I http://www.w3.org/2008/site/images/logo-w3c-mobile-lg HTTP/1.1 200 OK Date: Sat, 27 Nov 2010 19:21:50 GMT Server: Apache/2 Content-Location: logo-w3c-mobile-lg.png Vary: negotiate,accept TCN: choice Last-Modified: Sun, 25 Apr 2010 15:27:07 GMT ETag: 11a9-485114b0e28c0;4876eed0c4800 Accept-Ranges: bytes Content-Length: 4521 Cache-Control: max-age=2592000 Expires: Mon, 27 Dec 2010 19:21:50 GMT P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml; Connection: close Content-Type: image/png; qs=0.7 This is odd -- doesn't support HEAD? $ curl -I http://bnb.bibliographica.org/entry/GB8102507 HTTP/1.0 406 Not Acceptable Date: Sat, 27 Nov 2010 19:29:24 GMT Server: Apache/2.2.14 (Ubuntu) Pragma: no-cache Cache-Control: no-cache Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Type: text/html; charset=UTF-8 X-Cache: MISS from localhost X-Cache-Lookup: MISS from localhost:80 Via: 1.0 localhost (squid/3.0.STABLE19) Connection: close $ curl -I -H Accept:application/rdf+xml http://bnb.bibliographica.org/entry/GB8102507 HTTP/1.0 406 Not Acceptable $ cwm
Re: Is 303 really necessary?
Bob Ferris wrote: Hello everybody, I wrote a note as an attempt to clarify a bit the terms Resource, Information Resource and Document and their relations (from my point of view). Maybe this helps to figure out the bits of the current confusion. Please have a look at: http://infoserviceonto.wordpress.com/2010/11/25/on-resources-information-resources-and-documents/ likewise: http://webr3.org/apps/notes/web#atypedlink partial story of creating /a/ semantic web, rather than /the/ semantic web.
Re: Is 303 really necessary?
Hi Bob, On Fri, 2010-11-26 at 15:15 +0100, Bob Ferris wrote: Hello everybody, I wrote a note as an attempt to clarify a bit the terms Resource, Information Resource and Document and their relations (from my point of view). Maybe this helps to figure out the bits of the current confusion. Please have a look at: http://infoserviceonto.wordpress.com/2010/11/25/on-resources-information-resources-and-documents/ To reduce confusion, I think it would be helpful to point out up front that you are using the term information resource quite differently than it is defined in the W3C Architecture of the World Wide Web: http://www.w3.org/TR/webarch/#id-resources -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
On Fri, 2010-11-26 at 14:30 +, Nathan wrote: http://webr3.org/apps/notes/web#atypedlink partial story of creating /a/ semantic web, rather than /the/ semantic web. Thanks for posting this. I like the reasoning, but one part I think is overstated to the point of being incorrect: It is critical to note, that you cannot name real world things with URIs, you cannot name the moon with a URI, just as you cannot send the moon through a computer. You later discuss the idea of using a URI to name something *as-described-by* a document, and this I think is a very good point to make. But I don't think it invalidates the idea that you can name real world things with URIs. I suggest toning down the above statement and further explaining the idea that the identity of a resource may not be unambiguously determined, but it is determined only to the extent that its description determines it. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
On 11/26/10 12:49 PM, David Booth wrote: On Fri, 2010-11-26 at 14:30 +, Nathan wrote: http://webr3.org/apps/notes/web#atypedlink partial story of creating /a/ semantic web, rather than /the/ semantic web. Thanks for posting this. I like the reasoning, but one part I think is overstated to the point of being incorrect: It is critical to note, that you cannot name real world things with URIs, you cannot name the moon with a URI, just as you cannot send the moon through a computer. You later discuss the idea of using a URI to name something *as-described-by* a document, and this I think is a very good point to make. But I don't think it invalidates the idea that you can name real world things with URIs. I suggest toning down the above statement and further explaining the idea that the identity of a resource may not be unambiguously determined, but it is determined only to the extent that its description determines it. Nathan, I have a URI. I don't have a URL. A document describing me has a URL. A description has to occur on a surface (Document) otherwise it cannot be perceived by any beholder. The Subject of a description has to be distinct from its projector otherwise beholders are stuck with low- or no-resolution style projection. The Moon can have a URI that indicates its the Subject of a documented description. There is a trinity that cannot be broken when it comes to structured descriptions: Referent, Identifier, Document . This has been so long before the WWW came into existence. Real World Entities have always had Identifiers. URIs don't change this reality. That's an accepted fact in a broad range of universes of discourse -- which includes AWWW . A description of the Moon with a URI for Moon never implies the moon will come zooming out of the Web. It just means: an observer of the Moon can use Attribute=Value pairs to describe the Moon (referent) via a Document by coalescing these Attribute=Value pairs around the Moon's Identifier (Name). If said observer performs the above in machine readable form, he/she is basically entering into the realm of EAV based structured data. Add hypermedia to the mix re., Documentation medium and we have Linked Data. I have never read a note by TimBL that's indicated that you can't give URIs to real world objects. Ditto W3C. I've never encountered any computer literature relating to Distributed Objects or Object Orientation that's indicated Data Objects, Entities, Data Items are devoid of Identity. Resource overloading bug continues to haunt Semantic Web and Linked Data communications and comprehension :-) Again, we can't break the trinity: Referent, Identifier, Document -- which is the container, disseminator, and projector of Content defined by a Model that is logic based re., hypermedia based structured data. Roy Fielding wasn't describing Linked Data (Distributed Data Objects) in his famous thesis. He was describing a better approach to Document Oriented Client-Server Middleware via HTTP. The Document Oriented Middleware vs Remote Procedure Calls Oriented middleware has been raging for eons, long before WWW. This subject matter is a vast realm on to itself re. history. Today, we talk about REST vs SOAP, without always knowing that they're just today's monikers for an age-old battle in the realm of Client-Server Middleware. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
* [2010-11-26 15:15:42 +0100] Bob Ferris z...@elbklang.net écrit: ] ] I wrote a note as an attempt to clarify a bit the terms Resource, ] Information Resource and Document and their relations (from my point of ] view). Maybe this helps to figure out the bits of the current confusion. So taking a cue from this thread, I've implemented something that I think is in line with the original suggestion for a new dataset that I'm working on. If you request, e.g. http://bnb.bibliographica.org/entry/GB8102507 with an Accept header indicating an interest in RDF data, you will get a 200 response with a Content-Location header indicating that what is returned is actually the GB8102507.rdf document. It seems to me that this is enough information that a client needn't be confused between the document and the book, A good man in Africa. There is foaf:primaryTopic linkage in the document that should also adequately explain the state of affairs. However it seems that some clients are confused -- tabulator for instance as was pointed out in irc the other day. My question is, should I change the behaviour to the standard 303 redirect or leave it as a stake in the ground saying that this is a reasonable arrangement? Cheers, -w -- William Waites http://eris.okfn.org/ww/foaf#i 9C7E F636 52F6 1004 E40A E565 98E3 BBF3 8320 7664
Re: Is 303 really necessary?
On 11/26/10 4:47 PM, William Waites wrote: * [2010-11-26 15:15:42 +0100] Bob Ferrisz...@elbklang.net écrit: ] ] I wrote a note as an attempt to clarify a bit the terms Resource, ] Information Resource and Document and their relations (from my point of ] view). Maybe this helps to figure out the bits of the current confusion. So taking a cue from this thread, I've implemented something that I think is in line with the original suggestion for a new dataset that I'm working on. If you request, e.g. http://bnb.bibliographica.org/entry/GB8102507 with an Accept header indicating an interest in RDF data, you will get a 200 response with a Content-Location header indicating that what is returned is actually the GB8102507.rdf document. It seems to me that this is enough information that a client needn't be confused between the document and the book, A good man in Africa. There is foaf:primaryTopic linkage in the document that should also adequately explain the state of affairs. However it seems that some clients are confused -- tabulator for instance as was pointed out in irc the other day. My question is, should I change the behaviour to the standard 303 redirect or leave it as a stake in the ground saying that this is a reasonable arrangement? Cheers, -w William, I see nothing wrong our client was able to extract a description by de-referencing your URI without being confused about Entity Name or Descriptor Document Address. Links: 1. http://linkeddata.uriburner.com/about/html/http/bnb.bibliographica.org/entry/GB8102507 -- a description of the resource 2. http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fbnb.bibliographica.org%2Fentry%2FGB8102507 -- ditto (if you follow type property values you will end up with a path to descriptions of other entities of type bibo:Book in this particular data space etc..) . -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
On 11/18/10 5:10 PM, David Booth wrote: Hi Ian, Although I applaud your efforts at finding a simpler solution, upon reflection I think I would vote against the 200 + Content-location proposal, http://iand.posterous.com/a-guide-to-publishing-linked-data-without-red for these reasons: 1. I think adding a third option to the use either hash URIs or 303 redirects guidance will cause more harm then good to the LOD community. There is already enough confusion over Should I use a hash URI or a 303 and why? question. A third option is likely to create even more confusion. 2. I don't see the extra network access of 303 as being such a big deal -- though YMMV -- since even though the 303 response itself is not supposed to be cached (per RDF 2616), the toucan description document returned in the following 200 response can (and should) be cached. In fact, if you have n slash URIs U1, U2, ... Un etc. that share the same description document, then with the 200+CL approach the entire description document would have to be returned n times, whereas with the 303 approach the description document would only be retrieved once: the rest of the n network access would be short 303 responses. 3. The proposed use of the Content-location header is not aligned with the RFC 2616 or HTTPbis definitions of its purpose: http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#page-24 That header does not indicate that the returned representation is *not* a representation corresponding to the effective request URI. Rather, it says that it is *also* a representation corresponding to the Content-location URI. I.e., the returned representation is *both* a representation of a generic *and* a more specific resource. Best wishes, David, What about the aspect of this idea that's based on the content of the self-describing description document? Basically, that a Linked Data aware user agent interprets the world view expressed in the content? I still believe there is a common ground here that isn't coming through i.e., nothing is broken, and people can drop description documents into data spaces on HTTP networks (e.g., WWW) where Subjects are identified using slash URIs, without any Linked Data aware user agent confusion re. Subject Name and Description Document Address confusion. Developers of Linked Data aware solutions (e.g. user agents and user agent extensions) are the ones that need to make a decision about semantic-fidelity i.e., do they stick with HTTP response codes, our use a combination of HTTP response codes, HTTP session metadata, and description document content, to disambiguate Names and Addresses. To conclude, I am saying: 1. No new HTTP response codes 2. Web Servers continue to return 200 OK for Document URLs 3. Linked Data Servers have option handle Name or Address disambiguation using 303 redirection for slash URIs 4. Linked Data Servers have option to be like Web Servers i.e. do no Name or Address disambiguation leaving Linked Data aware user agents to understand the content of Description Documents 5. Linked Data aware User Agents handle Name or Address disambiguation. IMHO: when the dust settles, this is what it boils down to. On our side, we're done re. 1-5 across our Linked Data server and client functionality, as delivered by our products :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
On Fri, 2010-11-19 at 07:26 -0500, Kingsley Idehen wrote: [ . . . ] To conclude, I am saying: 1. No new HTTP response codes 2. Web Servers continue to return 200 OK for Document URLs 3. Linked Data Servers have option handle Name or Address disambiguation using 303 redirection for slash URIs 4. Linked Data Servers have option to be like Web Servers i.e. do no Name or Address disambiguation leaving Linked Data aware user agents to understand the content of Description Documents 5. Linked Data aware User Agents handle Name or Address disambiguation. IMHO: when the dust settles, this is what it boils down to. On our side, we're done re. 1-5 across our Linked Data server and client functionality, as delivered by our products :-) I think the above reflects reality, regardless of what is recommended, because: - some Linked Data Servers *will* serve RDF with 200 response codes via slash URIs, regardless of what is recommended; - some User Agents *will* still try to use that data; - those User Agents may or may not care about the ambiguity between the toucan and its web page; - those that do care will use whatever heuristics they have to disambiguate, and the heuristic of ignoring the 200 response code is very pragmatic. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
On 11/19/10 4:55 PM, David Booth wrote: On Fri, 2010-11-19 at 07:26 -0500, Kingsley Idehen wrote: [ . . . ] To conclude, I am saying: 1. No new HTTP response codes 2. Web Servers continue to return 200 OK for Document URLs 3. Linked Data Servers have option handle Name or Address disambiguation using 303 redirection for slash URIs 4. Linked Data Servers have option to be like Web Servers i.e. do no Name or Address disambiguation leaving Linked Data aware user agents to understand the content of Description Documents 5. Linked Data aware User Agents handle Name or Address disambiguation. IMHO: when the dust settles, this is what it boils down to. On our side, we're done re. 1-5 across our Linked Data server and client functionality, as delivered by our products :-) I think the above reflects reality, regardless of what is recommended, because: - some Linked Data Servers *will* serve RDF with 200 response codes via slash URIs, regardless of what is recommended; - some User Agents *will* still try to use that data; - those User Agents may or may not care about the ambiguity between the toucan and its web page; - those that do care will use whatever heuristics they have to disambiguate, and the heuristic of ignoring the 200 response code is very pragmatic. David, Great! We're going to point back to this post repeatedly in the future :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
Kingsley Idehen wrote: On 11/19/10 4:55 PM, David Booth wrote: On Fri, 2010-11-19 at 07:26 -0500, Kingsley Idehen wrote: [ . . . ] To conclude, I am saying: 1. No new HTTP response codes 2. Web Servers continue to return 200 OK for Document URLs 3. Linked Data Servers have option handle Name or Address disambiguation using 303 redirection for slash URIs 4. Linked Data Servers have option to be like Web Servers i.e. do no Name or Address disambiguation leaving Linked Data aware user agents to understand the content of Description Documents 5. Linked Data aware User Agents handle Name or Address disambiguation. IMHO: when the dust settles, this is what it boils down to. On our side, we're done re. 1-5 across our Linked Data server and client functionality, as delivered by our products :-) I think the above reflects reality, regardless of what is recommended, because: - some Linked Data Servers *will* serve RDF with 200 response codes via slash URIs, regardless of what is recommended; - some User Agents *will* still try to use that data; - those User Agents may or may not care about the ambiguity between the toucan and its web page; - those that do care will use whatever heuristics they have to disambiguate, and the heuristic of ignoring the 200 response code is very pragmatic. David, Great! We're going to point back to this post repeatedly in the future :-) I truly hope not, recognizing that some people *will* do whatever the hell they please, doesn't make what they're doing a good idea, or something that should be accepted as best / standard practise. As David mentioned earlier, having two ways to do things is already bad enough (hash/303) without introducing a third. There's already been half a decade of problems/ambiguity/nuisance because of the httpRange-14 resolution, ranging from technical to community and via conceptual, why on earth would we want to compound that by returning to the messy state that prompted the range-14 issue in the first place? Fact is, the current reality is primarily due to the fact there is so much confusion with no single clear message coming through, and until that happens the future reality is only likely to get messier. Best, Nathan
Re: Is 303 really necessary?
On 11/19/10 5:57 PM, Nathan wrote: Kingsley Idehen wrote: On 11/19/10 4:55 PM, David Booth wrote: On Fri, 2010-11-19 at 07:26 -0500, Kingsley Idehen wrote: [ . . . ] To conclude, I am saying: 1. No new HTTP response codes 2. Web Servers continue to return 200 OK for Document URLs 3. Linked Data Servers have option handle Name or Address disambiguation using 303 redirection for slash URIs 4. Linked Data Servers have option to be like Web Servers i.e. do no Name or Address disambiguation leaving Linked Data aware user agents to understand the content of Description Documents 5. Linked Data aware User Agents handle Name or Address disambiguation. IMHO: when the dust settles, this is what it boils down to. On our side, we're done re. 1-5 across our Linked Data server and client functionality, as delivered by our products :-) I think the above reflects reality, regardless of what is recommended, because: - some Linked Data Servers *will* serve RDF with 200 response codes via slash URIs, regardless of what is recommended; - some User Agents *will* still try to use that data; - those User Agents may or may not care about the ambiguity between the toucan and its web page; - those that do care will use whatever heuristics they have to disambiguate, and the heuristic of ignoring the 200 response code is very pragmatic. David, Great! We're going to point back to this post repeatedly in the future :-) I truly hope not, recognizing that some people *will* do whatever the hell they please, doesn't make what they're doing a good idea, or something that should be accepted as best / standard practise. I am not implying that :-) I am trying to say that 1-5 represent the landscape, and solutions simply operate within that reality. Next time these matters arise we can save time returning to 1-5. As David mentioned earlier, having two ways to do things is already bad enough (hash/303) without introducing a third. There will always be many ways to skin a rat, Linked Data can't stop that reality. There's already been half a decade of problems/ambiguity/nuisance because of the httpRange-14 resolution, ranging from technical to community and via conceptual, why on earth would we want to compound that by returning to the messy state that prompted the range-14 issue in the first place? I don't see how I am advocating that. There are no mandates in 1-5, again that outlines how things are. Server, Servers and User Agents, or User Agents can make decisions. Fact is, the current reality is primarily due to the fact there is so much confusion with no single clear message coming through, and until that happens the future reality is only likely to get messier. It won't get any messier since 1-5 simply implies that there isn't anything to change re. HTTP response codes. Developers should make choices and live with the consequences, as they do every day :-) Best, Nathan -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
Hi Ian, Although I applaud your efforts at finding a simpler solution, upon reflection I think I would vote against the 200 + Content-location proposal, http://iand.posterous.com/a-guide-to-publishing-linked-data-without-red for these reasons: 1. I think adding a third option to the use either hash URIs or 303 redirects guidance will cause more harm then good to the LOD community. There is already enough confusion over Should I use a hash URI or a 303 and why? question. A third option is likely to create even more confusion. 2. I don't see the extra network access of 303 as being such a big deal -- though YMMV -- since even though the 303 response itself is not supposed to be cached (per RDF 2616), the toucan description document returned in the following 200 response can (and should) be cached. In fact, if you have n slash URIs U1, U2, ... Un etc. that share the same description document, then with the 200+CL approach the entire description document would have to be returned n times, whereas with the 303 approach the description document would only be retrieved once: the rest of the n network access would be short 303 responses. 3. The proposed use of the Content-location header is not aligned with the RFC 2616 or HTTPbis definitions of its purpose: http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#page-24 That header does not indicate that the returned representation is *not* a representation corresponding to the effective request URI. Rather, it says that it is *also* a representation corresponding to the Content-location URI. I.e., the returned representation is *both* a representation of a generic *and* a more specific resource. Best wishes, -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Is disambiguation really necessary? (was Is 303 really necessary?)
/agree with Tore. I know it's an old debate, but it's payback time for flooding my inbox for the last week. Can someone please give me a good use case for pedantically disambiguating an IR and NIR? This week I've seen the following samples: /toucan.rdf is wrong. Why are you declaring a document wrong? Which part of the document at what point in time? Why don't you just say what you think is right? ian owns /toucan.rdf. Why are you saying this? Are you being lazy and really mean ian makes statement X about a toucan? /toucan.rdf was last updated Who cares, this rdf only exists because he isn't allowed to 200 an rdf on /toucan. And why would you say /toucan was updated? Does this make life easier for your simpleton web crawler/indexer? Don't you mean On monday ian made statement X, but on tuesday he made statement Y? /toucan.rdf has a page rank of... Who cares that google ranks anything served over http, this statement is meaningless for a toucan or it's representation. Did we really add a whole layer of suck just to make life easier for a tiny set of questionably useful document-oriented applications? Maybe those apps should focus on .html URIs instead of toucans. We have enough trouble solving true identity problems as David's paper points out, why add more inane ones? It definitely killed my motivation to try and fix real ambiguity at openguid. Not that anyone cares, but I use conneg to respond with 200 STFU in rdf/html/etc. And you can't complain about my content because it doesn't have unique identifier. HA! Jason
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On Tue, 9 Nov 2010 17:04:44 -0500 (EST) joel sachs jsa...@csee.umbc.edu wrote: I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. But: Kingsley film:isStarOf #SexyBeast . Kingsley film:isStarOf #Ghandi . is no more ambiguous than: #SexyBeast film:star Kingsley . #Ghandi film:star Kingsley . And what exactly is ambiguous about the following example? 2010-11-10^^xsd:date d:precedes 2010-11-11^^xsd:date . Whether an identifier is ambiguous and whether it's a literal are two mostly orthogonal issues. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Is 303 really necessary?
Torsdag 04 november 2010 16:21, skrev Giovanni Tummarello: ..but its so deployed now I have to admit, that would be my response. I wrote the code and it was really easy. My impression is that people have very few issues with the 303, what they may feel unfamiliar is the need to use different URIs for the thing and the data. If this is correct, would really the discussion presented here be so important or can we do without this distinction? Cheers, Kjetil
RE: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Ian said: I used Denny Vrandečić's browser tool to test several Linked Data browsers including Tabulator. http://browse.semanticweb.org/?uri=http%3A%2F%2Fiandavis.com%2F2010 %2F303%2Ftoucandays=7 Non of these showed any confusion between the toucan and its description, nor did that throw warnings or errors about the lack of 303 or in fact make any reference to it (tabulator includes the response as RDF but does not infer that the 200 response implies a type of information resource, which I had assumed it would) Looking at the Tabulator view here http://dig.csail.mit.edu/2005/ajar/release/tabulator/0.8/tab?uri=http%3A%2F%2Fiandavis.com%2F2010%2F303%2Ftoucan I did notice that the Tabulator generates the two triples: http://iandavis.com/2010/303/toucan http://dig.csail.mit.edu/2005/ajar/ajaw/ont#mentionsClass http://xmlns.com/foaf/0.1/Document . http://iandavis.com/2010/303/toucan http://dig.csail.mit.edu/2005/ajar/ajaw/ont#mentionsClass http://dbpedia.org/resource/Ramphastidae . Which leads me to wonder whether either you have a very erudite toucan there, or Tabulator may be exhibiting some element of confusion? Though, yes, the mentionsClass property has domain rdfs:Resource (rather than some:Document), so there is no inference that the toucan is-a document, though I do note the human-readable rdfs:comment for that property says This document mentions the following class Pete --- Pete Johnston Technical Researcher Eduserv E: pete.johns...@eduserv.org.uk T: +44 (0)1225 474323 F: +44 (0)1225 474301 http://www.eduserv.org.uk/ http://efoundations.typepad.com/ Eduserv is a company limited by guarantee (registered in England Wales, company number: 3763109) and a charity (charity number 1079456), whose registered office is at Royal Mead, Railway Place, Bath, BA1 1SR.
Re: Is 303 really necessary?
Hi Ian, Even if I come from a slightly different camp (Topic Maps), I wonder if your proposal hasn't become reality already. Try to resolve rdf:type or rdfs:label: I think we agree that these resources describe abstract concepts and should not return 200 but 303. Both return 200. So, what we're talking about? The building bricks of RDF return 200 and everybody seems to happy with that fact. Why shouldn't other (non-addressable) information resources return 200 as well? Do I miss something? Best regards, Lars -- Semagia http://www.semagia.com
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On Tue, Nov 9, 2010 at 11:23 AM, Nathan nat...@webr3.org wrote: Pete Johnston wrote: This document mentions the following class It's all very simple really, when you remove all the conflated terms. I am not conflating terms and nor is my example, but I think you are (see below) What is this: ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:foaf=http://xmlns.com/foaf/0.1/; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:wdrs=http://www.w3.org/2007/05/powder-s#; xmlns:dbp=http://dbpedia.org/resource/; dbp:Toucan rdf:about=http://iandavis.com/2010/303/toucan; rdfs:labelA Toucan/rdfs:label foaf:depiction rdf:resource=http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Pteroglossus-torquatus-001.jpg/250px-Pteroglossus-torquatus-001.jpg; / rdfs:commentThis resource is an individual toucan that happens to live in southern mexico./rdfs:comment wdrs:describedby rdf:resource=http://iandavis.com/2010/303/toucan.rdf/ /dbp:Toucan foaf:Document rdf:about=http://iandavis.com/2010/303/toucan.rdf; rdfs:labelA Description of a Toucan/rdfs:label rdfs:commentThis document is a description of the toucan resource./rdfs:comment /foaf:Document /rdf:RDF http://iandavis.com/2010/303/toucan is simply another name for whatever the above is. Nope. It's not at all. That text you include is the entity sent when you issue a GET to the URI. Entity bodies aren't usually named on the web. It's also a representation of http://iandavis.com/2010/303/toucan.rdf You are conflating the resource with the content of an HTTP message sent to your computer. You could interpret the tabulator property as meaning the entity returned when you perform a GET on the URI contains the following class Hints: - it's not a resource It has a URI http://iandavis.com/2010/303/toucan.rdf, anything identified by a URI is a resource. - it's not a document I think it is - it's not an rdf document I think it is - it's not a toucan Agree. That text is not a toucan. Best, Nathan Ian
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Pete Johnston wrote: This document mentions the following class It's all very simple really, when you remove all the conflated terms. What is this: ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:foaf=http://xmlns.com/foaf/0.1/; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:wdrs=http://www.w3.org/2007/05/powder-s#; xmlns:dbp=http://dbpedia.org/resource/; dbp:Toucan rdf:about=http://iandavis.com/2010/303/toucan; rdfs:labelA Toucan/rdfs:label foaf:depiction rdf:resource=http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Pteroglossus-torquatus-001.jpg/250px-Pteroglossus-torquatus-001.jpg; / rdfs:commentThis resource is an individual toucan that happens to live in southern mexico./rdfs:comment wdrs:describedby rdf:resource=http://iandavis.com/2010/303/toucan.rdf/ /dbp:Toucan foaf:Document rdf:about=http://iandavis.com/2010/303/toucan.rdf; rdfs:labelA Description of a Toucan/rdfs:label rdfs:commentThis document is a description of the toucan resource./rdfs:comment /foaf:Document /rdf:RDF http://iandavis.com/2010/303/toucan is simply another name for whatever the above is. Hints: - it's not a resource - it's not a document - it's not an rdf document - it's not a toucan Best, Nathan
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 6:57 AM, Ian Davis wrote: On Tue, Nov 9, 2010 at 11:23 AM, Nathannat...@webr3.org wrote: Pete Johnston wrote: This document mentions the following class It's all very simple really, when you remove all the conflated terms. I am not conflating terms and nor is my example, but I think you are (see below) What is this: ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:foaf=http://xmlns.com/foaf/0.1/; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:wdrs=http://www.w3.org/2007/05/powder-s#; xmlns:dbp=http://dbpedia.org/resource/; dbp:Toucan rdf:about=http://iandavis.com/2010/303/toucan; rdfs:labelA Toucan/rdfs:label foaf:depiction rdf:resource=http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Pteroglossus-torquatus-001.jpg/250px-Pteroglossus-torquatus-001.jpg; / rdfs:commentThis resource is an individual toucan that happens to live in southern mexico./rdfs:comment wdrs:describedby rdf:resource=http://iandavis.com/2010/303/toucan.rdf/ /dbp:Toucan foaf:Document rdf:about=http://iandavis.com/2010/303/toucan.rdf; rdfs:labelA Description of a Toucan/rdfs:label rdfs:commentThis document is a description of the toucan resource./rdfs:comment /foaf:Document /rdf:RDF http://iandavis.com/2010/303/toucan is simply another name for whatever the above is. Nope. It's not at all. That text you include is the entity sent when you issue a GET to the URI. Entity bodies aren't usually named on the web. It's also a representation of http://iandavis.com/2010/303/toucan.rdf You are conflating the resource with the content of an HTTP message sent to your computer. You could interpret the tabulator property as meaning the entity returned when you perform a GET on the URI contains the following class Hints: - it's not a resource It has a URI http://iandavis.com/2010/303/toucan.rdf, anything identified by a URI is a resource. Yes, in Resource Conflation lingo. No, in reality. A URI is an Identifier. Remember it stands for: Uniform Resource Identifier. It should actually be: Universal Object Identifier or Universal Entity Identifier or Uniform Object Identifier or Uniform Entity Identifier. URIs Identify Entities or Things. They can identify anything we can imagine. A Resource is a kind of Thing that has physical manifestation in a specific realm. Yes, we are Resources, Documents, Widgets, but not in the Web Realm. You are conflating because Web != Real World. Thus, saying everything is a Resource, when the rest of the world knows that everything is an Entity or Thing or Object is conflation that leads to utter incomprehension. How do you think Object based systems work? How do you think Object Oriented Database work? How do you think Object Relational Databases work? How do you think Relational Databases work? How do computers work? Is an Address the only way we use a Pointer? Do you seriously think that the ubiquity of an HTTP network, where physical resources represent Documents (e.g. HTML, RDF, XML etc..), warrants such overreach and disregard for the past re. computer technology continuum? Resource conflation days are numbered. Its usage and acceptence is inherently inversely related to Linked Data concept comprehension. Remember my statement above. Same applies to RDF = Linked Data, conflation. - it's not a document I think it is It cannot be! It resolves to a Document. Without Documents how can one perceive anything across any medium? - it's not an rdf document I think it is It resolves to a Document Type where the Content is expressed in on of the RDF markup syntaxes. - it's not a toucan Agree. That text is not a toucan. Yes, but for a different reason. The Toucan is the Referent of the URI. This is how its always been, if it wasn't you wouldn't be reading this mail via a computer system that uses pointers to create references that enables us walk data structures, programmatically. Kingsley Best, Nathan Ian -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
On Mon, 2010-11-08 at 22:17 +0100, Lars Heuer wrote: Hi Ian, Even if I come from a slightly different camp (Topic Maps), I wonder if your proposal hasn't become reality already. Try to resolve rdf:type or rdfs:label: I think we agree that these resources describe abstract concepts and should not return 200 but 303. Both return 200. Those are hash URIs, for example, the rdf:type expands to the URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#type As it says [1] in the RDF specs: the RDF treatment of a fragment identifier allows it to indicate a thing that is entirely external to the document, or even to the shared information space known as the Web. That is, it can be a more general idea, like some particular car or a mythical Unicorn So those are perfectly fine. Ian's proposal and the discussion here has been entirely about URIs without fragment identifiers, so called slash URIs. Dave [1] http://www.w3.org/TR/rdf-concepts/#section-fragID - though that is an Informative rather than Normative section of the concepts document.
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Kingsley Idehen wrote: On 11/9/10 6:57 AM, Ian Davis wrote: On Tue, Nov 9, 2010 at 11:23 AM, Nathannat...@webr3.org wrote: Pete Johnston wrote: This document mentions the following class It's all very simple really, when you remove all the conflated terms. it's a description. I am not conflating terms and nor is my example, but I think you are (see below) What is this: ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:foaf=http://xmlns.com/foaf/0.1/; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:wdrs=http://www.w3.org/2007/05/powder-s#; xmlns:dbp=http://dbpedia.org/resource/; dbp:Toucan rdf:about=http://iandavis.com/2010/303/toucan; rdfs:labelA Toucan/rdfs:label foaf:depiction rdf:resource=http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Pteroglossus-torquatus-001.jpg/250px-Pteroglossus-torquatus-001.jpg; / rdfs:commentThis resource is an individual toucan that happens to live in southern mexico./rdfs:comment wdrs:describedby rdf:resource=http://iandavis.com/2010/303/toucan.rdf/ /dbp:Toucan foaf:Document rdf:about=http://iandavis.com/2010/303/toucan.rdf; rdfs:labelA Description of a Toucan/rdfs:label rdfs:commentThis document is a description of the toucan resource./rdfs:comment /foaf:Document /rdf:RDF http://iandavis.com/2010/303/toucan is simply another name for whatever the above is. Nope. It's not at all. That text you include is the entity sent when you issue a GET to the URI. Entity bodies aren't usually named on the web. It's also a representation of http://iandavis.com/2010/303/toucan.rdf You are conflating the resource with the content of an HTTP message sent to your computer. You could interpret the tabulator property as meaning the entity returned when you perform a GET on the URI contains the following class Hints: - it's not a resource It has a URI http://iandavis.com/2010/303/toucan.rdf, anything identified by a URI is a resource. Yes, in Resource Conflation lingo. No, in reality. A URI is an Identifier. Remember it stands for: Uniform Resource Identifier. It should actually be: Universal Object Identifier or Universal Entity Identifier or Uniform Object Identifier or Uniform Entity Identifier. URIs Identify Entities or Things. They can identify anything we can imagine. A Resource is a kind of Thing that has physical manifestation in a specific realm. Yes, we are Resources, Documents, Widgets, but not in the Web Realm. You are conflating because Web != Real World. Thus, saying everything is a Resource, when the rest of the world knows that everything is an Entity or Thing or Object is conflation that leads to utter incomprehension. How do you think Object based systems work? How do you think Object Oriented Database work? How do you think Object Relational Databases work? How do you think Relational Databases work? How do computers work? Is an Address the only way we use a Pointer? Do you seriously think that the ubiquity of an HTTP network, where physical resources represent Documents (e.g. HTML, RDF, XML etc..), warrants such overreach and disregard for the past re. computer technology continuum? Resource conflation days are numbered. Its usage and acceptence is inherently inversely related to Linked Data concept comprehension. Remember my statement above. Same applies to RDF = Linked Data, conflation. - it's not a document I think it is It cannot be! It resolves to a Document. Without Documents how can one perceive anything across any medium? - it's not an rdf document I think it is It resolves to a Document Type where the Content is expressed in on of the RDF markup syntaxes. - it's not a toucan Agree. That text is not a toucan. Yes, but for a different reason. The Toucan is the Referent of the URI. This is how its always been, if it wasn't you wouldn't be reading this mail via a computer system that uses pointers to create references that enables us walk data structures, programmatically. Kingsley Best, Nathan Ian
Re: Is 303 really necessary?
Hi Dave, [rdf:type returns 200] Those are hash URIs, for example, the rdf:type expands to the URI: [...] So those are perfectly fine. Ian's proposal and the discussion here has been entirely about URIs without fragment identifiers, so called slash URIs. I see. Thanks :) Best regards, Lars -- Semagia http://www.semagia.com
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 11:22 AM, Nathan wrote: Kingsley Idehen wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can Describe what isn't unambiguously Identified (Named); hence the use of Names since the beginning of shared cognition era re. human evolution. A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); hence the use of Names since the beginning of shared cognition era re. human evolution. ex:about#toucan doesn't name a toucan though, it names, or refers to, toucan, as described by ex:about Yes, it refers to Toucan by .. ? Put differently, Toucan (a Thing observed by the Describer) is the Referent of the Identifier (URI). Thus, the URI is used to distinguish the Subject (Tucan) from the surface (Document) from which we perceive its Description. Referent, Identifier, Resource trinity :-) The 3 elements (in combination) deliver comprehensible Representation, to a given beholder. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 10:54 AM, Nathan wrote: Kingsley Idehen wrote: On 11/9/10 6:57 AM, Ian Davis wrote: On Tue, Nov 9, 2010 at 11:23 AM, Nathannat...@webr3.org wrote: Pete Johnston wrote: This document mentions the following class It's all very simple really, when you remove all the conflated terms. it's a description. Yes! We are describing observations. Can't do this in thin air, must have a projection surface, hence the need for Documents. You see, the whole Web of Data vs. Web of Documents is yet another false dichotomy. The Web is simply evolving its projection media from HTML documents (sorta like blank paper on to which you can scribble) to more Structured Documents (sorta like graph paper, what the spreadsheet kinda models). This new Document type is like graph paper, also like a spreadsheet (supports Name and Address reference values in cells), but with a 3-column restriction and unlimited rows. HTTP lets us stream this powerful 3 column based graph paper document. The underlying conceptual schema (EAV) allows multiple representations (HTML+RDFa, RDF/XML, OData+Atom, OData+JSON, RDF-JSON, GData etc) of the conceptual schema's model semantics. We are using a graph paper like surface to hold the descriptions of our observations. We can use a myriad of syntaxes to achieve this goal as long as said syntaxes are based on a common conceptual schema. Mapping an RDBMS to an RDF syntax isn't some new age magic, it's possible because there is a common conceptual schema at the base re. a DBMS based Relational Property Graphs vs its relative based on Relational Tables. HTTP 200 OK means: Document Found. Content-Type means: Document Content is in a given format. Content-Location means: Document Location. A URI is just an Identifier. We can Describe what isn't unambiguously Identified (Named); hence the use of Names since the beginning of shared cognition era re. human evolution. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can Describe what isn't unambiguously Identified (Named); hence the use of Names since the beginning of shared cognition era re. human evolution. A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); hence the use of Names since the beginning of shared cognition era re. human evolution. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Those opposed: But you might be misunderstood. Those in favour: We'll take our chances. ? Joel. hence the use of Names since the beginning of shared cognition era re. human evolution. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 5:04 PM, joel sachs wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Joel, Let me be a little clearer re. my statement: We can't produce high-fidelity descriptions of Things (Entities) if the description Subjects aren't unambiguously Identified. I believe, via Linked Data, we are seeking to produce high-fidelity Linked Data meshes that scale. English is but one of several syntaxes. Global scale is an integral goal of the mission, Methinks. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
joel sachs wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Those opposed: But you might be misunderstood. Those in favour: We'll take our chances. ? Perhaps you are both correct, I believe what Kingsley is getting at, is that in order to refer to the description of something (thus something described), you need to have an unambiguous name (identifier for the purpose of referencing) to use as the subject in statements made about that thing, within the description ( read as, a way of referring to a description of bar within a description named foo = bar, as described by foo = foo#bar ) - Not that foo#bar must be an unambiguous name for a thing in the IFP sense - rather an unambiguous way to say, on the web, the thing I am describing is the same thing bar, as described by foo. And perhaps what you are saying, is the same thing Kingsley, as described by Ghandi and Sexy Beast, was great = ghandi-sexy-beast#kingsley And, perhaps: Those opposed: We'll take our chances. Those in favour: But you might be misunderstood. Best, Nathan
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Kingsley, I'm not sure that you're joking, so I'll answer: It's unambiguous to those who know that Ben Kingsley was in Gandhi and Sexy Beast. It's probably close to unambiguous to those who know that Ben Kingsley is an actor, and Gandhi and Sexy Beast are movies. To everyone else, it's probably ambiguous, which is my point. Joel. On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 5:04 PM, joel sachs wrote: On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. To whom is this unambiguous? Kingsley Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Those opposed: But you might be misunderstood. Those in favour: We'll take our chances. ? Joel. hence the use of Names since the beginning of shared cognition era re. human evolution. -- Regards, Kingsley IdehenPresident CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
I guess what surprises me is your use of can't in We can't produce ... instead of shouldn't, as in We shouldn't produce high fidelity descriptions of things that aren't unambiguosly identified, because if we do, there will be no reliable way to merge descriptions from different sources. I think it's obvious that we can since we do it all the time. That we shouldn't may be true, although it is, I think you'll agree, a contested claim. Joel. On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 5:04 PM, joel sachs wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Joel, Let me be a little clearer re. my statement: We can't produce high-fidelity descriptions of Things (Entities) if the description Subjects aren't unambiguously Identified. I believe, via Linked Data, we are seeking to produce high-fidelity Linked Data meshes that scale. English is but one of several syntaxes. Global scale is an integral goal of the mission, Methinks. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On Tue, 9 Nov 2010, Nathan wrote: joel sachs wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Those opposed: But you might be misunderstood. Those in favour: We'll take our chances. ? Perhaps you are both correct, I believe what Kingsley is getting at, is that in order to refer to the description of something (thus something described), you need to have an unambiguous name (identifier for the purpose of referencing) to use as the subject in statements made about that thing, within the description ( read as, a way of referring to a description of bar within a description named foo = bar, as described by foo = foo#bar ) - Not that foo#bar must be an unambiguous name for a thing in the IFP sense - rather an unambiguous way to say, on the web, the thing I am describing is the same thing bar, as described by foo. And perhaps what you are saying, is the same thing Kingsley, as described by Ghandi and Sexy Beast, was great = ghandi-sexy-beast#kingsley And, perhaps: Those opposed: We'll take our chances. Those in favour: But you might be misunderstood. Best, Nathan Nathan, Nathan, I definitely agree with your switcharoo - Those opposed: We'll take our chances. Those in favour: But you might be misunderstood. Specifically, as it stands now, there is great scope for misunderstanding when dealing with Linked Data. Perhaps the most egregious example is the widely discredited owl:sameAs. The hope, I think, of Linked Data, is that, as time goes by, the scope for misunderstanding will be greatly diminished. Regards - Joel.
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 5:59 PM, joel sachs wrote: Kingsley, I'm not sure that you're joking, so I'll answer: It's unambiguous to those who know that Ben Kingsley was in Gandhi and Sexy Beast. It's probably close to unambiguous to those who know that Ben Kingsley is an actor, and Gandhi and Sexy Beast are movies. To everyone else, it's probably ambiguous, which is my point. Yes, in the real-world. On the Web it's totally ambiguous :-) Kingsley Joel. On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 5:04 PM, joel sachs wrote: On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 11:10 AM, Kingsley Idehen wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. To whom is this unambiguous? Kingsley Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Those opposed: But you might be misunderstood. Those in favour: We'll take our chances. ? Joel. hence the use of Names since the beginning of shared cognition era re. human evolution. -- Regards, Kingsley IdehenPresident CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen -- Regards, Kingsley IdehenPresident CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On 11/9/10 6:01 PM, joel sachs wrote: I guess what surprises me is your use of can't in We can't produce ... instead of shouldn't, as in We shouldn't produce high fidelity descriptions of things that aren't unambiguosly identified, because if we do, there will be no reliable way to merge descriptions from different sources. I think it's obvious that we can since we do it all the time. That we shouldn't may be true, although it is, I think you'll agree, a contested claim. Naturally, of course. Just my opinion. Everything I say is inherently subjective :-) Kingsley Joel. On Tue, 9 Nov 2010, Kingsley Idehen wrote: On 11/9/10 5:04 PM, joel sachs wrote: A URI is just an Identifier. We can't Describe what isn't unambiguously Identified (Named); Kingsley, I think we can, though we might not be properly understood, e.g. Kingsley was great in Gandhi and Sexy Beast. Wasn't this part of the summer's argument regarding literals as rdf:subjects , i.e. Joel, Let me be a little clearer re. my statement: We can't produce high-fidelity descriptions of Things (Entities) if the description Subjects aren't unambiguously Identified. I believe, via Linked Data, we are seeking to produce high-fidelity Linked Data meshes that scale. English is but one of several syntaxes. Global scale is an integral goal of the mission, Methinks. -- Regards, Kingsley IdehenPresident CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
On Thu, 4 Nov 2010 13:22:09 + Ian Davis m...@iandavis.com wrote: http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They require an additional HTTP request to get to the data the client actually wants. I think that without using RDF-specific publishing platforms (think WordPress for Linked Data) #1 is always going to be a difficulty. Even if we accept 200 OK as a response code for non-IR resources, this only solves part of the server configuration problem. There are still other issues to be solved - Apache doesn't come preconfigured with media type information for N3/Turtle/N-Triples. And getting neat-looking URIs (no .rdf suffix at the end) requires something like mod_rewrite, Apache multiviews or ForceType to be configured. You could try publishing an N-Triples file with no suffix, and cross your fingers that Apache's default media type of text/plain will bubble up. #2 on the other hand can be addressed quite easily. 303 responses are allowed -- indeed encouraged -- to include an entity body. Servers could be configured to duplicate the description of the non-IR resource in this entity body. Or perhaps provide a more summarised description there. Clients just need to look at it before deciding whether to follow the redirect. e.g. GET /toucan HTTP/1.1 Host: example.com HTTP/1.1 303 See Other Location: http://example.com/doc Content-Type: text/turtle @prefix foaf: http://xmlns.com/foaf/0.1/ . toucan foaf:name Harry the Toucan ; foaf:isPrimaryTopicOf doc . Here the client decides whether that's enough information. If it needs more, it continues by dereferencing doc. GET /doc HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Location: http://example.com/doc.ttl Content-Type: text/turtle @prefix foaf: http://xmlns.com/foaf/0.1/ . toucan foaf:name Harry the Toucan ; foaf:isPrimaryTopicOf doc ; foaf:birthday 10-24 . doc foaf:maker alice . -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
On Fri, Nov 5, 2010 at 9:53 AM, Leigh Dodds leigh.do...@talis.com wrote: So here's a couple of questions for those of you on the list who have implemented Linked Data tools, applications, services, etc: * Do you rely on or require HTTP 303 redirects in your application? Or does your app just follow the redirect? * Would your application tool/service/etc break or generic inaccurate data if Ian's pattern was used to publish Linked Data. I used Denny Vrandečić's browser tool to test several Linked Data browsers including Tabulator. http://browse.semanticweb.org/?uri=http%3A%2F%2Fiandavis.com%2F2010%2F303%2Ftoucandays=7 Non of these showed any confusion between the toucan and its description, nor did that throw warnings or errors about the lack of 303 or in fact make any reference to it (tabulator includes the response as RDF but does not infer that the 200 response implies a type of information resource, which I had assumed it would) Cheers, Ian
Re: Is 303 really necessary?
Hi Norman, On Sat, 2010-11-06 at 22:45 +, Norman Gray wrote: [ . . . ] I take it that Ian is suggesting resolving the ambiguity he has created, and thus the need for any heuristics, by extending the notion of IR in such a way that a URI with a 200 response *is* an IR, *unless* dereferencing it returns RDF which (authoritatively) declares that the URI is a NIR. I don't think that is feasible. After all, what's so special about RDF? And how would the client even know whether RDF were returned? Almost any serialization can be turned into RDF. Suppose XML is returned. Is that RDF? A GRDDL transformation can cause it to be viewed as RDF? And what about a plain HTML page? Surely in that case the URI would identify the web page. But what if there were some RDFa tags embedded? Suddenly it *doesn't* identify the web page? Even if the client ignores those tags? No, I think it makes more sense to acknowledge that the ambiguity *has* been created by the server both returning the 200 response and sending a document saying that the URI identifies a toucan, but applications that are troubled by this ambiguity should use the provenance of the information to decide bits of information to use or ignore -- in this case ignoring the information given in the HTTP response code in favor of the information given in the RDF document. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
On Thu, 2010-11-04 at 22:29 -0400, mike amundsen wrote: snip However, the key point is that it is *layered* on the good old http scheme. Thus, if you click on this URI: http://t-d-b.org/?http://dbooth.org/2005/dbooth/ it works, with no changes needed to your browser /snip So the thinking here is to use the concept of a scheme without actually minting one because the most common client today would throw an error if an actual scheme was used, right? Exactly. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
David, hello. On 2010 Nov 8, at 09:40, David Booth wrote: On Sat, 2010-11-06 at 22:45 +, Norman Gray wrote: [ . . . ] I take it that Ian is suggesting resolving the ambiguity he has created, and thus the need for any heuristics, by extending the notion of IR in such a way that a URI with a 200 response *is* an IR, *unless* dereferencing it returns RDF which (authoritatively) declares that the URI is a NIR. I don't think that is feasible. After all, what's so special about RDF? And how would the client even know whether RDF were returned? Almost any serialization can be turned into RDF. Suppose XML is returned. Is that RDF? A GRDDL transformation can cause it to be viewed as RDF? And what about a plain HTML page? Surely in that case the URI would identify the web page. But what if there were some RDFa tags embedded? Suddenly it *doesn't* identify the web page? Even if the client ignores those tags? There's nothing fundamentally special about RDF, and if one ignores RDF, then the adjusted Decision is identical to the original one. However, if W3C is going to pronounce on the semantics of the web, then it seems reasonable to allow W3C RDF some sort of privileged status -- it's special because httpRange-14-bis says it's special!. I appreciate that 'a URI...returns RDF' has the problem you identify. However, is it really as uncertain as you describe? In some circumstances, a server could prefer to return RDF over HTML, if that's at all compatible with the Accept header; and if an HTML resource includes RDFa or GRDDL, then it's clear that the resource owner intendes the derived RDF to be in some sense authoritative. If a data consumer decides to turn XML into RDF, then the data owner can hardly be held responsible for the resulting RDF. No, I think it makes more sense to acknowledge that the ambiguity *has* been created by the server both returning the 200 response and sending a document saying that the URI identifies a toucan, but applications that are troubled by this ambiguity should use the provenance of the information to decide bits of information to use or ignore -- in this case ignoring the information given in the HTTP response code in favor of the information given in the RDF document. I wouldn't claim there's zero ambiguity here. However simply saying httpRange-14 is defeasible buys you some convenience. If there are a few semi-standard practices about how that '/X is a NIR' statement is discovered, then the remaining ambiguity is I would guess at least acceptable, and certainly lower than what is routinely tolerated in Linked Data applications generally. Best wishes, Norman -- Norman Gray : http://nxg.me.uk
Re: Is 303 really necessary?
On Fri, 5 Nov 2010 10:24:43 +
Ian Davis m...@iandavis.com wrote:
On Fri, Nov 5, 2010 at 10:05 AM, Nathan nat...@webr3.org wrote:
Not at all, I'm saying that if big-corp makes a /web crawler/ that
describes what documents are about and publishes RDF triples
/toucan :primaryTopic dbpedia:Toucan ; a :Document .
i don't think so. If the bigcorp is producing triples from their crawl
then why wouldn't they use the triples they are sent (and/or
content-location, link headers etc).
Perhaps they try to use them, but don't understand the serialisation
you're providing.
Or perhaps they can parse your triples, but don't realise that
{/toucan a ex:Toucan.} implies Not({/toucan a foaf:Document.}).
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
Re: Is 303 really necessary?
On Mon, 2010-11-08 at 10:11 +, Toby Inkster wrote: On Thu, 4 Nov 2010 13:22:09 + Ian Davis m...@iandavis.com wrote: http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They require an additional HTTP request to get to the data the client actually wants. I think that without using RDF-specific publishing platforms (think WordPress for Linked Data) #1 is always going to be a difficulty. Why not use a 303-redirect service such as http://thing-described-by.org/ or http://t-d-b.org/ ? That makes it trivially easy to do 303 redirects. No configuration needed! And if you want to run your own 303 redirect service, you can view all of the code and configuration files here: http://thing-described-by.org/?showfile=. Even if we accept 200 OK as a response code for non-IR resources, this only solves part of the server configuration problem. There are still other issues to be solved - Apache doesn't come preconfigured with media type information for N3/Turtle/N-Triples. And getting neat-looking URIs (no .rdf suffix at the end) requires something like mod_rewrite, Apache multiviews or ForceType to be configured. You could try publishing an N-Triples file with no suffix, and cross your fingers that Apache's default media type of text/plain will bubble up. #2 on the other hand can be addressed quite easily. 303 responses are allowed -- indeed encouraged -- to include an entity body. Servers could be configured to duplicate the description of the non-IR resource in this entity body. Yes, the 303 response could include the entire toucan description. RFC 2616 says: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). The entire toucan description might be more than a short hypertext note, but this is a SHOULD requirement -- not a MUST requirement: http://www.ietf.org/rfc/rfc2119.txt [[ 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ]] Furthermore, to avoid server configuration difficulties, this ability could be combined with a 303-redirect service such as http://t-d-b.org/ such that a GET on a URI like the following http://t-d-b.org/cache?http://iandavis.com/2010/303/toucan.rdf could directly return the whole toucan description from http://iandavis.com/2010/303/toucan.rdf : HTTP/1.1 303 See Other Location: http://iandavis.com/2010/303/toucan.rdf Content-Location: http://iandavis.com/2010/303/toucan.rdf Content-Type: application/rdf+xml ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; . . . [ . . . ] /rdf:RDF Of course, such a service may wish to restrict itself to serving local files only, in part for security. For non-local files it could return a normal 303 response: HTTP/1.1 303 See Other Location: http://iandavis.com/2010/303/toucan.rdf Content-Type: text/plain Redirecting to: http://iandavis.com/2010/303/toucan.rdf -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary? (dealing with ambiguity)
On Mon, 2010-11-08 at 16:18 +0900, Tore Eriksson wrote: Hi David, David Booth wrote: [ . . . ] And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that http://iandavis.com/2010/303/toucan returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. As long as they they are aware that they are talking about a specific representation of this resource I can't see any problem with this. If they think they are stating something about the resource itself, well they would be wrong even if the current URI was an information resource. They apparently need to learn more about web technology - representations, caching, con-neg, c. How about: Ian Davis owns web page http://iandavis.com/2010/303/toucan. The content at http://iandavis.com/2010/303/toucan was last updated 7-Nov-2010. http://iandavis.com/2010/303/toucan has a page rank of 123,456,789. Those statements are not talking about any specific representations, nor are they talking about the toucan. All are completely reasonable statements for someone knowing nothing about RDF to make. [ . . . ] So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code. By not drawing ill-founded conclusions about the nature of the resource through the response code, ambiguity could have been avoided in the first place. Apparently you and I disagree about what it means to be a web page. I personally know of no better qualification criterion for something being a web page than if that thing returns a 200 status code in response to a GET request. Perhaps one would characterize this as duck typing: http://en.wikipedia.org/wiki/Duck_typing What other criteria would you use? -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary?
On Mon, 2010-11-08 at 15:34 -0500, David Booth wrote: On Mon, 2010-11-08 at 10:11 +, Toby Inkster wrote: On Thu, 4 Nov 2010 13:22:09 + Ian Davis m...@iandavis.com wrote: http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They require an additional HTTP request to get to the data the client actually wants. I think that without using RDF-specific publishing platforms (think WordPress for Linked Data) #1 is always going to be a difficulty. Why not use a 303-redirect service such as http://thing-described-by.org/ or http://t-d-b.org/ ? That makes it trivially easy to do 303 redirects. Because the domain of the URI conveys some provenance and trust connotations, particularly when dealing with public sector bodies. That gets lost when redirected through a third party service. For many of the groups I deal with that would not be acceptable. In cases where third party redirection is acceptable then there are also PURLs which arguably provide stronger expectations of longevity. Dave
Re: Is 303 really necessary?
On Mon, 2010-11-08 at 21:50 +, Dave Reynolds wrote: On Mon, 2010-11-08 at 15:34 -0500, David Booth wrote: On Mon, 2010-11-08 at 10:11 +, Toby Inkster wrote: On Thu, 4 Nov 2010 13:22:09 + Ian Davis m...@iandavis.com wrote: http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They require an additional HTTP request to get to the data the client actually wants. I think that without using RDF-specific publishing platforms (think WordPress for Linked Data) #1 is always going to be a difficulty. Why not use a 303-redirect service such as http://thing-described-by.org/ or http://t-d-b.org/ ? That makes it trivially easy to do 303 redirects. Because the domain of the URI conveys some provenance and trust connotations, particularly when dealing with public sector bodies. That gets lost when redirected through a third party service. For many of the groups I deal with that would not be acceptable. But you don't have to use a third-party redirect service. You can run your own if you want. The files for implementing thing-described-by.org are available here: http://thing-described-by.org/?showfile=. In cases where third party redirection is acceptable then there are also PURLs which arguably provide stronger expectations of longevity. +1 for PURLs. And BTW, I have used PURLs in conjunction with thing-described-by.org. Although purl.org can do 303 redirects for individual URIs, it cannot currently do 303's *and* partial redirects. To get around this limitation, I used purl.org to do a partial redirect to a thing-described-by.org URI, which then does the 303 redirect to its query string URI: http://purl.org/example/foo/* -- 302 -- http://thing-described-by.org/?http://example/foo/* -- 303 -- http://example/foo/* -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Sat, Nov 6, 2010 at 11:31 PM, Toby Inkster t...@g5n.co.uk wrote:
Not necessarily. If you take your ex:isDescribedBy predicate and add
that to a triple store where the non-Information-Resource resources are
identified using hash URIs, then the SPARQL query is just:
DESCRIBE uri ?res
WHERE { ?res ex:isDescribedBy uri . }
which needn't be very slow.
I've done this myself but using foaf:primaryTopic and foaf:topic to
link a document URI to all the resources that are needed to render it.
The other downside of fragments is you can't say it exists but I have
no description of it.
#foo a rdfs:Resource .
In which case you do have a description of it :) But point taken, this
tautology would be enough.
Cheers,
Ian
Re: Is 303 really necessary? (Multiple things described in a single document)
Hi Ian, On Fri, 2010-11-05 at 10:59 +, Ian Davis wrote: I have a question about http://thing-described-by.org/ - how does it work when my description document describes multiple things? Really, any RDF document that references more than one resource as a subject or object can be considered to be providing a description of all those resources. It sounds like you are getting into the distinction between what I've been calling core assertions and ancillary assertions: http://dbooth.org/2007/uri-decl/#uri-decl http://dbooth.org/2007/uri-decl/#ancillary In a nutshell, the core assertions of a URI are those that the URI owner has authoritatively provided in its URI declaration, that all statement authors using that URI *should* accept (or else they should not use the URI): http://dbooth.org/2009/lifecycle/#event2 [[ Statement author responsibility 3: Use of a URI implies agreement with the core assertions of its URI declaration. ]] For example, the assertions about http://iandavis.com/2010/303/toucan that you provided in http://iandavis.com/2010/303/toucan.rdf are *core* assertions with respect to http://iandavis.com/2010/303/toucan , because you own that URI. Thus, anyone using that URI to make RDF statements about your toucan *should* accept your assertions. (Otherwise they may be talking about a different toucan!) However, if *I* make statements using your toucan URI http://iandavis.com/2010/303/toucan , my assertions are *ancillary* assertions with respect to (WRT) that URI: other RDF statement authors using your toucan URI are free to use or ignore my statements, because they are not authoritative WRT that URI. So, even though your URI declaration at http://iandavis.com/2010/303/toucan.rdf may make assertions about many subjects, those assertions only act as *core* assertions for http://iandavis.com/2010/303/toucan . They act as *ancillary* assertions for other URIs. Note that the exact same assertion can be a core assertion WRT one URI, but an ancillary assertion WRT another URI. This is normal, because assertions that are authoritative WRT one URI declaration may be non-authoritative WRT another URI. The reason for this distinction between core and ancillary assertions is to ensure that when different people talk about http://iandavis.com/2010/303/toucan we can know that they are all talking about the *same* toucan (at least within the limits of the ambiguity in that toucan's definition). If different statement authors http://dbooth.org/2009/lifecycle/#statementAuthor used different URI declarations for your toucan URI then they would run the risk of talking about *different* toucans. (Actually, they still run the risk of talking about different toucans, as illustrated by graphs A and C here: http://dbooth.org/2010/ambiguity/paper.html#inconsistent-merge but the risk is reduced.) I'll address your other questions separately, so that this email message doesn't get even longer. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary? (dealing with ambiguity)
On Fri, 2010-11-05 at 10:59 +, Ian Davis wrote: On Thu, Nov 4, 2010 at 10:10 PM, David Booth da...@dbooth.org wrote: 2. only one description can be linked from the toucan's URI True, but that's far better than zero, if you only have the toucan URI and it returns 404! It could return 204. I don't understand where you're going with that. How would a 204 permit more than one description to be linked from the toucan's URI? 3. the user enters one URI into their browser and ends up at a different one, causing confusion when they want to reuse the URI of the toucan. Often they use the document URI by mistake. Yes, that's a problem. The trade-off is ambiguity. I don't think so. The ambiguity is not present because the data explicitly distinguishes the two URIs (and content-location header does too). I would say that the ambiguity *has* been created, but your heuristic (of looking at the provenance of whether the information came from the HTTP response code permits that ambiguity to be resolved. There are millions of people that use URIs to identify billions of web pages, and the vast majority have never heard of RDF. If your toucan URI returns a 200 response just like billions of other URIs then it *does* identify a web page, even if you are also using that URI in some RDF document to identify a toucan -- a document that would just be gobbledygook to most of the world. And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that http://iandavis.com/2010/303/toucan returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. (Indeed, they may know nothing about RDF.) But they still use http://iandavis.com/2010/303/toucan to identify the web page, and no amount of RDF can change that fact. Furthermore, their statements may eventually be translated to RDF -- perhaps by someone else -- and merged with other assertions that use http://iandavis.com/2010/303/toucan to refer to the toucan. So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code. 7. it mixes layers of responsibility - there is information a user cannot know without making a network request and inspecting the metadata about the response to that request. When the web server ceases to exist then that information is lost. I don't buy this argument. While I agree that explicit statements such as Utoucan :isDescribedBy Upage . is helpful and should be provided, that does *not* mean that links are not *also* useful. Just because links do not *always* work does not mean that they are useless. But you agree that under the current scheme, some things are knowable only by making a network request. It's not enough to have just the RDF description document? Sorry, I may have been unclear. I *do* think that if the client app already has enough RDF data about Utoucan then the client app should not waste a network access dereferencing Utoucan. However, I think the URI owner of Utoucan *should* still make Utoucan dereferenceable (either directly or indirectly) to RDF data, because this may be useful to the client app for cases when it either doesn't have sufficient RDF data about Utoucan or if it wishes to verify that it has the correct or current RDF data about Utoucan. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary? (dealing with ambiguity)
Hi David, David Booth wrote: There are millions of people that use URIs to identify billions of web pages, and the vast majority have never heard of RDF. Most of these millions haven't heard of, nor care about, the HTML contained in the web page either. Thus, saying that millions of people use the URI to denote the underlying HTML document seems like a stretch of imagination. If your toucan URI returns a 200 response just like billions of other URIs then it *does* identify a web page, even if you are also using that URI in some RDF document to identify a toucan -- a document that would just be gobbledygook to most of the world. Reading W3 mailing lists have made me wary of words like identify. You can get a home page by doing a HTTP GET on the URI, but the relationship to the original URI is not well defined. Why can't we just leave it like that. Use RDF for describing resources in detail. And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that http://iandavis.com/2010/303/toucan returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. As long as they they are aware that they are talking about a specific representation of this resource I can't see any problem with this. If they think they are stating something about the resource itself, well they would be wrong even if the current URI was an information resource. They apparently need to learn more about web technology - representations, caching, con-neg, c. (Indeed, they may know nothing about RDF.) But they still use http://iandavis.com/2010/303/toucan to identify the web page, and no amount of RDF can change that fact. Furthermore, their statements may eventually be translated to RDF -- perhaps by someone else -- and merged with other assertions that use http://iandavis.com/2010/303/toucan to refer to the toucan. OK, they might. Do you have any examples of problems with Ian's approach that are likely to happen at the moment? So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code. By not drawing ill-founded conclusions about the nature of the resource through the response code, ambiguity could have been avoided in the first place. Tore rEiksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]
Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Fri, Nov 5, 2010 at 5:28 PM, Nathan nat...@webr3.org wrote: URI resolution is essentially: dereference( uri.toAbsolute() ); Which gives us the simplicity and semantic indirection which we need. Use frags, forget HTTP, know that uri#frag is never going to be a document (unless you explicitly say it is). On a practical level using frags can be inefficient when your linked data output is backed by a triple store. If you use a slash URI then generating the data for html/xml/turtle output is just a simple describe uri. For hash URIs you need to describe all the resources with a common prefix because the fragment is not sent by the browser with the request. That might mean a filter with a regex or string functions which will be more inefficient. If you pick a standard fragment such as #this, #it etc then you can revert to the simple describe so the inefficiency only arises when there are multiple arbitrary fragments per document URI. The other downside of fragments is you can't say it exists but I have no description of it. With standard slash URIs you can 303 to a 404 to say that. You can 404 on the slash itself to say the resource does not exist. With my proposal to use 2xx responses you can return 204 No Content to indicate the resource exists but no description is available. With slashes you can use 410 on an individual resource to indicate that it has gone forever. You can also do this with the one frag per doc approach although you are really saying the description document has gone and the user is left to imply the secondary resource has also gone. With multiple frags per doc (i.e. a lot of schemas) you can't say just one of those resources has gone forever. In summary: Slash with 303: hard static publishing, efficient dynamic, can ack existence without description Hash, one resource per doc: easy static publishing, efficient dynamic, can't ack existence without description Hash, many resources per doc (the typical schema case): easy static publishing, less efficient dynamic, can't ack existence without description Slash with 2xx: easy static publishing, efficient dynamic, can ack existence without description Ian
Re: Is 303 really necessary?
David, hello. On 2010 Nov 6, at 20:42, David Booth wrote: httpRange-14 requires that a URI with a 200 response MUST be an IR; ^^^ Not quite. The httpRange-14 decision says that the resource *is* an IR: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 Yes, when I phrased this, I did indeed mean it as an analytic-must rather than an rfc2119-synthetic-must (this is the distinction you're making, yes?) a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. To be clear, Ian's toucan URI *does* identify an information resource, whether or not it *also* identifies a toucan: Indeed, because the decision defines what an IR is, so that Ian's toucan is necessarily an IR in the sense in which that term is currently defined. Thus, Ian has created an ambiguity by returning a 200 response. (Ian can of course speak for himself, but...) I take it that Ian is suggesting resolving the ambiguity he has created, and thus the need for any heuristics, by extending the notion of IR in such a way that a URI with a 200 response *is* an IR, *unless* dereferencing it returns RDF which (authoritatively) declares that the URI is a NIR. However, for those applications that need to distinguish between the toucan and its web page, Ian is effectively suggesting the *heuristic* that if the content served in the 200 response says that the URI identifies a toucan, then the app should ignore the fact that the URI also identifies a web page, and treat the URI as though it *only* identifies the toucan. The suggestion does mean that the toucan URI, since it now identifies a toucan, cannot also identify the toucan's webpage, which is therefore unnamed. I don't know if that's a problem or not (maybe it is, if you want to be able to say I got this information about the toucan called /toucan from X). If it's a problem, then perhaps the /toucan URI could point towards a /toucan.rdf URI which contains the same RDF as /toucan, but which is still an IR. Then /toucan.rdf is the toucan's webpage. Best wishes, Norman -- Norman Gray : http://nxg.me.uk
Re: Is 303 really necessary?
On 11/6/10 4:42 PM, David Booth wrote: httpRange-14 requires that a URI with a 200 response MUST be an IR; ^^^ Not quite. The httpRange-14 decision says that the resource *is* an IR: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. To be clear, Ian's toucan URI *does* identify an information resource, whether or not it *also* identifies a toucan: $ curl -I 'http://iandavis.com/2010/303/toucan' HTTP/1.1 200 OK Date: Sat, 06 Nov 2010 20:05:57 GMT Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_wsgi/1.3 Python/2.5.2 Content-Location: toucan.rdf Vary: negotiate TCN: choice Last-Modified: Fri, 05 Nov 2010 09:24:27 GMT ETag: 264186-403-4944ad745a8c0;4944ad754eb00 Accept-Ranges: bytes Content-Length: 1027 Content-Type: application/rdf+xml; qs=0.9 Thus, Ian has created an ambiguity by returning a 200 response. There is nothing fundamentally wrong with this, as ambiguity of resource identity is inescapable anyway, and we just have to learn to deal with it. However, for those applications that need to distinguish between the toucan and its web page, Ian is effectively suggesting the *heuristic* that if the content served in the 200 response says that the URI identifies a toucan, then the app should ignore the fact that the URI also identifies a web page, and treat the URI as though it *only* identifies the toucan. David, What about this: 1. a 200 OK response infers that a URI is a URL (an Address) since its an indication of that a Resource has been located 2. existence of a self-describing resource discovered via Content-Location header value (e.g. touscan.rdf) can result in an override if the data states that the URI is a Name. I really think we have to emphasize the Address and Name aspects of a generic URI, at every opportunity. Personally, I think it helps understand what the actual ambiguity is about. This option showcases good RDF dog-fooding, especially as the Semantic Web Project has always been about self-describing data :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Sat, 6 Nov 2010 12:33:34 +
Ian Davis li...@iandavis.com wrote:
On a practical level using frags can be inefficient when your linked
data output is backed by a triple store. If you use a slash URI then
generating the data for html/xml/turtle output is just a simple
describe uri. For hash URIs you need to describe all the resources
with a common prefix because the fragment is not sent by the browser
with the request. That might mean a filter with a regex or string
functions which will be more inefficient.
Not necessarily. If you take your ex:isDescribedBy predicate and add
that to a triple store where the non-Information-Resource resources are
identified using hash URIs, then the SPARQL query is just:
DESCRIBE uri ?res
WHERE { ?res ex:isDescribedBy uri . }
which needn't be very slow.
The other downside of fragments is you can't say it exists but I have
no description of it.
#foo a rdfs:Resource .
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
Re: Is 303 really necessary?
Hi, On 4 November 2010 18:42, Kingsley Idehen kide...@openlinksw.com wrote: Nobody ever mandated 303 redirection. I've never encountered anyone in the community that has recently advocated (i.e. since the httpRange-14 discussion) or any documentation that promotes anything other than using # URIs or the 303 redirect approach. So in the circumstance where someone doesn't want to use a # URI, what options are available? Can point to a document that illustrates an alternate approach? It's not really choice if there's only one option. You also frequently cite dbpedia as the de facto standard model for publishing Linked Data. This uses the 303 pattern, giving further prominence to that approach. It has always been an option, and so it should remain. But if there are other options that have a better mix of advantages and dis-advantages to the two that the community has promoted thus far, then we should include those too. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: Is 303 really necessary?
Ian, (trying to keep up with this thread, maybe missed one point or the other) I'd like to understand on what we can agree here. It seems that having a URI for a thing and another URI for the document describing it is something most people would acknowledge to be useful. Two questions that come immediately into mind: Who cares? What are the costs and what are the benefits? First, I'd reckon that a certain number of tools and library developers (incl. Tabulator, RAP, RDB2RDF mapping tools, etc.) will have to care about this in the first place. Given the relative small size of the community compared to the Web at large this seems doable. Second, as already pointed out, the 303 issue mainly effects setups where the RDF representation is detached from the HTML (such as RDF/XML, Turtle, etc.), which means that the emerging and increasing part of the RDFa-based Linked Data world is not effected per se. Third, given that we're still a small community and find certain things to be sub-optimal, the cost changing it now is likely less than changing it in, say, 5 years time. I think I can hence sympathise with your proposal to (carefully) revisit the issue and think about alternatives. Now, having said this, although I think one should contemplate about the 303 issue, I don't agree with your proposed plan ahead; certain items on your list are rather simple to achieve (define the :isDescribedBy, update the LD guide, etc.) others not. It occurs to me that one of the main features of the Linked Data community is that we *do* things rather than having endless conversations what would be the best for the world out there. Heck, this is how the whole thing started. A couple of people defining a set of good practices and providing data following these practices and tools for it. Concluding. If you are serious about this, please go ahead. You have a very popular and powerful platform at your hand. Implement it there (and in your libraries, such as Moriarty), document it, and others may/will follow. Cheers, Michael -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html From: Ian Davis m...@iandavis.com Date: Thu, 4 Nov 2010 13:22:09 + To: Linked Data community public-lod@w3.org Subject: Is 303 really necessary? Resent-From: Linked Data community public-lod@w3.org Resent-Date: Thu, 04 Nov 2010 13:22:46 + Hi all, The subject of this email is the title of a blog post I wrote last night questioning whether we actually need to continue with the 303 redirect approach for Linked Data. My suggestion is that replacing it with a 200 is in practice harmless and that nothing actually breaks on the web. Please take a moment to read it if you are interested. http://iand.posterous.com/is-303-really-necessary Cheers, Ian
Re: Is 303 really necessary?
Hi Nathan, On 4 November 2010 18:08, Nathan nat...@webr3.org wrote: You see it's not about what we say, it's about what other say, and if 10 huge corps analyse the web and spit out billions of triples saying that anything 200 OK'd is a document, then at the end when we consider the RDF graph of triples, all we're going to see is one statement saying something is a nonInformationResource and a hundred others saying it's a document and describing what it's about together with it's format and so on. Are you suggesting that Linked Data crawlers could/should look at the status code and use that to infer new statements about the resources returned? If so, I think that's the first time I've seen that mentioned, and am curious as to why someone would do it. Surely all of the useful information is in the data itself. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: Is 303 really necessary?
Hi David, On 4 November 2010 19:57, David Wood da...@3roundstones.com wrote: Some small number of people and organizations need to provide back-links on the Web since the Web doesn't have them. 303s provide a generic mechanism for that to occur. URL curation is a useful and proper activity on the Web, again in my opinion. I agree that URL curation is a useful and proper activity on the Web. I'm not clear on your core concern though. It looks like you're asserting that HTTP 303 status codes, in general, are useful and should not be deprecated. Totally agree there. But Ian's proposal is about using 303 as a necessary part of publishing Linked Data. That seems distinct from how services like PURLs and DOIs operate, and from the value they provide. But perhaps I'm misunderstanding? Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: Is 303 really necessary?
Hi, On 4 November 2010 17:51, Nathan nat...@webr3.org wrote: But, for whatever reasons, we've made our choices, each has pro's and cons, and we have to live with them - different things have different name, and the giant global graph is usable. Please, keep it that way. I think it's useful to continually assess the state of the art to see whether we're on track. My experience, which seems to be confirmed by comments from other people on this thread, is that we're seeing push back from the wider web community -- who have already published way more data that we have -- on the technical approach we've been advocating, so looking for a middle ground seems useful. Different things do have different names, but conflating IR/NIR is not part of Ian's proposal which addresses the publishing mechanism only. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Is 303 really necessary - demo
Hi all, To aid discussion I create a small demo of the idea put forth in my blog post http://iand.posterous.com/is-303-really-necessary Here is the URI of a toucan: http://iandavis.com/2010/303/toucan Here is the URI of a description of that toucan: http://iandavis.com/2010/303/toucan.rdf As you can see both these resources have distinct URIs. I created a new property http://vocab.org/desc/schema/description to link the toucan to its description. The schema for that property is here: http://vocab.org/desc/schema (BTW I looked at the powder describedBy property and it's clearly designed to point to one particular type of description, not a general RDF one. I also looked at http://ontologydesignpatterns.org/ont/web/irw.owl and didn't see anything suitable) Here is the URI Burner view of the toucan resource and of its description document: http://linkeddata.uriburner.com/about/html/http://iandavis.com/2010/303/toucan http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan.rdf I'd like to use this demo to focus on the main thrust of my question: does this break the web and if so, how? Cheers, Ian P.S. I am not fully caught up on the other thread, so maybe someone has already produced this demo
What would break, a question for implementors? (was Re: Is 303 really necessary?)
Hi Michael, On 5 November 2010 09:29, Michael Hausenblas michael.hausenb...@deri.org wrote: It occurs to me that one of the main features of the Linked Data community is that we *do* things rather than having endless conversations what would be the best for the world out there. Heck, this is how the whole thing started. A couple of people defining a set of good practices and providing data following these practices and tools for it. Concluding. If you are serious about this, please go ahead. You have a very popular and powerful platform at your hand. Implement it there (and in your libraries, such as Moriarty), document it, and others may/will follow. Yes, actually doing things does help more than talking. I sometimes wonder whether as a community we're doing all the right things, but that's another discussion ;) Your suggestion about forging ahead is a good one, but it also reminds me of Ian's original question: what would break if we used this pattern? So here's a couple of questions for those of you on the list who have implemented Linked Data tools, applications, services, etc: * Do you rely on or require HTTP 303 redirects in your application? Or does your app just follow the redirect? * Would your application tool/service/etc break or generic inaccurate data if Ian's pattern was used to publish Linked Data. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: Is 303 really necessary?
On Fri, Nov 05, 2010 at 09:34:43AM +, Leigh Dodds wrote: Are you suggesting that Linked Data crawlers could/should look at the status code and use that to infer new statements about the resources returned? If so, I think that's the first time I've seen that mentioned, and am curious as to why someone would do it. Surely all of the useful information is in the data itself. Provenance and debugging. It would be quite possible to record the fact that this set of triples, G, were obtained by dereferencing this uri N, at a certain time, from a certain place, with a request that looked like this and a response that had these headers and response code. The class of information that is kept for [0]. If N appeared in G, that could lead directly to inferences involving the provenance information. If later reasoning is concerned at all with the trustworthiness or up-to-dateness of the data it could look at this as well. Keeping this quantity of information around might quickly turn out to be too data-intensive to be practical, but that's more of an engineering question. I think it does make some sense to do this in principle at least. Cheers, -w [0] http://river.styx.org/ww/2010/10/corscheck
Re: Is 303 really necessary?
On Fri, Nov 5, 2010 at 9:54 AM, William Waites w...@styx.org wrote: Provenance and debugging. It would be quite possible to record the fact that this set of triples, G, were obtained by dereferencing this uri N, at a certain time, from a certain place, with a request that looked like this and a response that had these headers and response code. The class of information that is kept for [0]. If N appeared in G, that could lead directly to inferences involving the provenance information. If later reasoning is concerned at all with the trustworthiness or up-to-dateness of the data it could look at this as well. Keeping this quantity of information around might quickly turn out to be too data-intensive to be practical, but that's more of an engineering question. I think it does make some sense to do this in principle at least. All the above would remain in my proposal. If you were in fact inferring triples from the 303 then those would already be in the data you are dereferencing. Ian
Inferring data from network interactions (was Re: Is 303 really necessary?)
Hi, On 5 November 2010 09:54, William Waites w...@styx.org wrote: On Fri, Nov 05, 2010 at 09:34:43AM +, Leigh Dodds wrote: Are you suggesting that Linked Data crawlers could/should look at the status code and use that to infer new statements about the resources returned? If so, I think that's the first time I've seen that mentioned, and am curious as to why someone would do it. Surely all of the useful information is in the data itself. Provenance and debugging. It would be quite possible to record the fact that this set of triples, G, were obtained by dereferencing this uri N, at a certain time, from a certain place, with a request that looked like this and a response that had these headers and response code. The class of information that is kept for [0]. If N appeared in G, that could lead directly to inferences involving the provenance information. If later reasoning is concerned at all with the trustworthiness or up-to-dateness of the data it could look at this as well. Yes, I've done something similar to that in the past when I added support for the ScutterVocab [1] to my crawler It was the suggestion that inferring information directly from 200/303 that I was most curious about. I've argued for inferring data from 301 in the past [2], but wasn't sure of merit of introducing data based on the other interactions Keeping this quantity of information around might quickly turn out to be too data-intensive to be practical, but that's more of an engineering question. I think it does make some sense to do this in principle at least. That's what I found when crawling the BBC pages. Huge amounts of data and overhead in storing it. Capturing just enough to gather statistics on the crawl was sufficient. Cheers, L. [1]. http://wiki.foaf-project.org/w/ScutterVocab [2]. http://www.ldodds.com/blog/2007/03/the-semantics-of-301-moved-permanently/ -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: Is 303 really necessary?
Leigh Dodds wrote: Hi Nathan, On 4 November 2010 18:08, Nathan nat...@webr3.org wrote: You see it's not about what we say, it's about what other say, and if 10 huge corps analyse the web and spit out billions of triples saying that anything 200 OK'd is a document, then at the end when we consider the RDF graph of triples, all we're going to see is one statement saying something is a nonInformationResource and a hundred others saying it's a document and describing what it's about together with it's format and so on. Are you suggesting that Linked Data crawlers could/should look at the status code and use that to infer new statements about the resources returned? If so, I think that's the first time I've seen that mentioned, and am curious as to why someone would do it. Surely all of the useful information is in the data itself. Not at all, I'm saying that if big-corp makes a /web crawler/ that describes what documents are about and publishes RDF triples, then if you use 200 OK, throughout the web you'll get (statements similar to) the following asserted: /toucan :primaryTopic dbpedia:Toucan ; a :Document . Now, move down the line a couple of years and reason over the a triple dump of the web-of-data and you'll find the problem, way to solve the problem is to first strip everything that's a :Document, so all the slash URIs will be stripped, including the /toucan. I'm also saying that 303 doesn't solve this half the time either, because most HTTP clients blackbox the process, so their process is: uri = /toucan; doc = get( uri ); makeStatements( uri , doc ); Again, same problem. Best, Nathan
Re: Is 303 really necessary?
Leigh Dodds wrote: Hi, On 4 November 2010 17:51, Nathan nat...@webr3.org wrote: But, for whatever reasons, we've made our choices, each has pro's and cons, and we have to live with them - different things have different name, and the giant global graph is usable. Please, keep it that way. I think it's useful to continually assess the state of the art to see whether we're on track. My experience, which seems to be confirmed by comments from other people on this thread, is that we're seeing push back from the wider web community -- who have already published way more data that we have -- on the technical approach we've been advocating, so looking for a middle ground seems useful. fully agree :) Different things do have different names, but conflating IR/NIR is not part of Ian's proposal which addresses the publishing mechanism only. This is really simple - forget about your data, the proposal and all of that, if you can GET a URI (all slash URIs) then something somewhere will say uri a :Document (not much of a problem), then describe what it's about (bigger problem). With 303 the odds are 50/50 that they'll pick the correct uri to treat as a document, with 200 the odds are 0/100 that they'll pick the correct uri to treat as a document. What's the point in you saying: /toucan a :Toucan; :describedBy /doc . If the rest of the world is saying: /toucan a :Document; :primaryTopic ex:Toucan . Follow?
Re: Is 303 really necessary?
On Fri, Nov 5, 2010 at 10:12 AM, Nathan nat...@webr3.org wrote: What's the point in you saying: /toucan a :Toucan; :describedBy /doc . If the rest of the world is saying: /toucan a :Document; :primaryTopic ex:Toucan . Follow? Because the data obtained by dereferencing /toucan is authoratative? Ian
Re: Is 303 really necessary?
On Fri, Nov 5, 2010 at 10:05 AM, Nathan nat...@webr3.org wrote: Not at all, I'm saying that if big-corp makes a /web crawler/ that describes what documents are about and publishes RDF triples, then if you use 200 OK, throughout the web you'll get (statements similar to) the following asserted: /toucan :primaryTopic dbpedia:Toucan ; a :Document . i don't think so. If the bigcorp is producing triples from their crawl then why wouldn't they use the triples they are sent (and/or content-location, link headers etc). The above looks like what you'd get from a third party translation of the crawl results without the context of actually having fetched the data from the URI. If the bigcorp is not linked data aware then today they will follow the 303 redirect as a standard HTTP redirect. rfc2616 says that the target URI is not a substitute for the original URI but just an alternate location to get a response from. The bigcorp will simply infer the statements you list above **even though there is a 303 redirect**. As rfc2616 itself points out, many user agents treat 302 and 303 interchangeably. Only linked data aware agents will ascribe special meaning to 303 and they're the ones that are more likely to use the data they are sent. Ian
Re: Is 303 really necessary?
Ian Davis wrote: On Fri, Nov 5, 2010 at 10:12 AM, Nathan nat...@webr3.org wrote: What's the point in you saying: /toucan a :Toucan; :describedBy /doc . If the rest of the world is saying: /toucan a :Document; :primaryTopic ex:Toucan . Follow? Because the data obtained by dereferencing /toucan is authoratative? wow, so if I give you give you a big dump of triples including: http://iandavis.com/2010/303/toucan a ex:Toucan . http://iandavis.com/2010/303/toucan :primaryTopic ex:Toucan . http://iandavis.com/2010/303/toucan a e:Document . http://iandavis.com/2010/303/toucan :isPrimaryTopicOf http://iandavis.com/2010/303/doc . You can tell me which one's authorative? and if I publish: http://webr3.org/nathan#me :isKingOf :TheWorld . it's authorative and considered true? great news all round :)
Re: Is 303 really necessary?
On Fri, Nov 5, 2010 at 10:34 AM, Nathan nat...@webr3.org wrote: and if I publish: http://webr3.org/nathan#me :isKingOf :TheWorld . it's authorative and considered true? great news all round :) No :) I mean't that when you dereference http://iandavis.com/2010/303/toucan, the triples you get about http://iandavis.com/2010/303/toucan can be considered authoritative. For me, that's one of the principle advantages of linked data over other data formats - built in provenance if you will. Also authoritative does not mean true. I means it asserts authority over the data. That could very well be wrong, but it's the consumer's choice whether they trust that authority or not (or can prove it perhaps). Ian
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
So here's a couple of questions for those of you on the list who have implemented Linked Data tools, applications, services, etc: * Do you rely on or require HTTP 303 redirects in your application? Or does your app just follow the redirect? For sindice - no we do not rely on or require them, merely follow. * Would your application tool/service/etc break or generic inaccurate data if Ian's pattern was used to publish Linked Data. It wouldn't break sindice. However... with regard to publishing ontologies, we could expect additional overhead if same content is delivered on retrieving different Resources for example http://example.com/schema/latitude and http://example.com/schema/longitude . In such a case ETag could be used to suggest the contents are identical, but not sure that is a practical solution. I expect that without 303 it will be more difficult in particular to publish and process ontologies. Rob. -- Robert Fuller Research Associate Sindice Team DERI, Galway http://sindice.com/
Re: Is 303 really necessary?
Ian Davis wrote: On Fri, Nov 5, 2010 at 10:05 AM, Nathan nat...@webr3.org wrote: Not at all, I'm saying that if big-corp makes a /web crawler/ that describes what documents are about and publishes RDF triples, then if you use 200 OK, throughout the web you'll get (statements similar to) the following asserted: /toucan :primaryTopic dbpedia:Toucan ; a :Document . i don't think so. If the bigcorp is producing triples from their crawl then why wouldn't they use the triples they are sent (and/or content-location, link headers etc). The above looks like what you'd get from a third party translation of the crawl results without the context of actually having fetched the data from the URI. Wouldn't be too sure about that, even the major browser vendors get it completely wrong, for instance do an XHR for a URI in chrome and even if there's 10 redirects in a chain, the base and the document uri is that which you requested. This is true all over the place, from using file_get_content's in PHP to most HTTP clients in any language, the pattern is simply: requested-uri = http://...;; doc = get(requested-uri); info at the end is almost always ( requested-uri, doc ) - in fact often there's not even any way to get the redirected to URI back out from the HTTP client. As for using the triples they are sent, all you need to do is consider an HTML crawler running over RDFa documents If the bigcorp is not linked data aware then today they will follow the 303 redirect as a standard HTTP redirect. rfc2616 says that the target URI is not a substitute for the original URI but just an alternate location to get a response from. The bigcorp will simply infer the statements you list above **even though there is a 303 redirect**. exactly, kind of semi-damning all /slash URIs.. or atleast requiring a load of provenance data. As rfc2616 itself points out, many user agents treat 302 and 303 interchangeably. Only linked data aware agents will ascribe special meaning to 303 and they're the ones that are more likely to use the data they are sent. God knows why linked data clients are ascribing any meaning to 303, the pattern's there to ensure that a thing and the doc describing it have different URIs, and to ensure that people don't say that thing is a document. Although it's not exactly worked out that way. The use of the particular status code 303 is only relevant if your ascribing meaning to the response code of GETs, if your not then 3** will do the same job. Out of interest, just who is trawling the web and going 301 that's an IR, 303 that's maybe not an IR, 302 that's an IR. My personal opinion on the entire thing is as simple as give different things different names, if there's a good chance something will think that thing is a different kind of thing by using a particular uri scheme or style (like saying mailto:f...@bar.org is a mailbox) then avoid it if it conflicts with the kind of thing you're describing. IMO slash URIs are often taken to mean documents, so I avoid them. You don't, so regardless of what status code you use, or how you deploy data, that conflation will be there. Thus my take away on the whole thing for you (and even though it goes against tag) is just 200 your uri's if you want to, but don't go around telling the rest of the world to do it and promote it as a good pattern, as it's not. tdb scheme or frag uris address the issues, whilst introducing others, but at least the data's somewhat cleaner. I'll roll with the who cares line of thinking, I certainly don't care how you or dbpedia or foaf or dc publish your data, so long as I can deref it, but for god sake don't go telling everybody using slash URIs and 200 is The Right Thing TM Best, Nathan
Re: Is 303 really necessary?
Hi David, Rather than respond to each of your points let me say that I agree with most of them :) I have snipped away the things I agree with in principle, and left the things I want to discuss further. I have a question about http://thing-described-by.org/ - how does it work when my description document describes multiple things? Really, any RDF document that references more than one resource as a subject or object can be considered to be providing a description of all those resources. On Thu, Nov 4, 2010 at 10:10 PM, David Booth da...@dbooth.org wrote: 2. only one description can be linked from the toucan's URI True, but that's far better than zero, if you only have the toucan URI and it returns 404! It could return 204. 3. the user enters one URI into their browser and ends up at a different one, causing confusion when they want to reuse the URI of the toucan. Often they use the document URI by mistake. Yes, that's a problem. The trade-off is ambiguity. I don't think so. The ambiguity is not present because the data explicitly distinguishes the two URIs (and content-location header does too). 7. it mixes layers of responsibility - there is information a user cannot know without making a network request and inspecting the metadata about the response to that request. When the web server ceases to exist then that information is lost. I don't buy this argument. While I agree that explicit statements such as Utoucan :isDescribedBy Upage . is helpful and should be provided, that does *not* mean that links are not *also* useful. Just because links do not *always* work does not mean that they are useless. But you agree that under the current scheme, some things are knowable only by making a network request. It's not enough to have just the RDF description document? Cheers, Ian
Re: Is 303 really necessary?
On Fri, Nov 5, 2010 at 10:57 AM, Nathan nat...@webr3.org wrote: I'll roll with the who cares line of thinking, I certainly don't care how you or dbpedia or foaf or dc publish your data, so long as I can deref it, but for god sake don't go telling everybody using slash URIs and 200 is The Right Thing TM Sure. We don't want to restrict choice or options. I am focussed here only on simplifying a common pattern. Ian
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Robert Fuller wrote: However... with regard to publishing ontologies, we could expect additional overhead if same content is delivered on retrieving different Resources for example http://example.com/schema/latitude and http://example.com/schema/longitude . In such a case ETag could be used to suggest the contents are identical, but not sure that is a practical solution. I expect that without 303 it will be more difficult in particular to publish and process ontologies. Good point which needs discussed more, for instance FOAF returning 200 OK's would be a real PITA and even worse than the 303 pattern, 3**s are definitely advisable in this case. ps: introducing some form of ETag equality wouldn't be the best idea, it may be possible to use Content-Location and ETag together to cache and save doing the second request after a 303 though. Best, Nathan
RE: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Hi Nathan I'm not saying you're wrong - but could you explain why it would be a pain for FOAF terms to return 200? Which kinds of application are dereferencing those terms and relying on a 303 response? eg http://xmlns.com/foaf/0.1/Person currently 303s to http://xmlns.com/foaf/spec/ What would break if http://xmlns.com/foaf/0.1/Person returned that same content with a status code of 200? Just trying to understand the issue Bill -Original Message- From: public-lod-requ...@w3.org on behalf of Nathan Sent: Fri 11/5/2010 12:45 PM To: Robert Fuller Cc: Leigh Dodds; Michael Hausenblas; Ian Davis; Linked Data community Subject: Re: What would break, a question for implementors? (was Re: Is 303 really necessary?) Robert Fuller wrote: However... with regard to publishing ontologies, we could expect additional overhead if same content is delivered on retrieving different Resources for example http://example.com/schema/latitude and http://example.com/schema/longitude . In such a case ETag could be used to suggest the contents are identical, but not sure that is a practical solution. I expect that without 303 it will be more difficult in particular to publish and process ontologies. Good point which needs discussed more, for instance FOAF returning 200 OK's would be a real PITA and even worse than the 303 pattern, 3**s are definitely advisable in this case. ps: introducing some form of ETag equality wouldn't be the best idea, it may be possible to use Content-Location and ETag together to cache and save doing the second request after a 303 though. Best, Nathan
Re: Is 303 really necessary?
Greetings, On 2010 Nov 4, at 13:22, Ian Davis wrote: http://iand.posterous.com/is-303-really-necessary I haven't been aware of the following formulation of Ian's problem+solution in the thread so far. Apologies if I've missed it, or if (as I guess) it's deducible from someone's longer post. httpRange-14 requires that a URI with a 200 response MUST be an IR; a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. Is that about right? That fits in with Harry's remarks about IRW, and the general suspicion of deriving important semantics from the details of the HTTP transaction. Here, the only semantics derivable from the transaction is defeasible. In the absence of RDF, this is equivalent to the httpRange-14 finding, so might require only adjustment, rather than replacement, of httpRange-14. All the best, Norman -- Norman Gray : http://nxg.me.uk
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
bill.robe...@planet.nl wrote: Hi Nathan I'm not saying you're wrong - but could you explain why it would be a pain for FOAF terms to return 200? Which kinds of application are dereferencing those terms and relying on a 303 response? eg http://xmlns.com/foaf/0.1/Person currently 303s to http://xmlns.com/foaf/spec/ What would break if http://xmlns.com/foaf/0.1/Person returned that same content with a status code of 200? Just trying to understand the issue Hi Bill, Good question :) If you consider a basic linked data client, with a basic ontology/schema awareness, for instance one which shows peoples FOAF profiles and uses the nice rdfs:label's for properties rather than foaf:Person. It's going to have to GET the ontology, now when it cycles through the properties it'll find http://xmlns.com/foaf/0.1/Person and GET it, then hopefully cache it against the URL specified in the [content?] location of the final request (be that 1 or many requests). When you 200 OK the response then the ontology will be stored against http://xmlns.com/foaf/0.1/Person so when you hit http://xmlns.com/foaf/0.1/knows you need to do another GET, and be returned a full ontology again, thus you end up with 40+ requests with full responses and 40+ cached versions of the single ontology. Unless you code around it in some way, make a provision for FOAF. However, if you use 303's the then first GET redirects there, then you store the ontology against the redirected-to URI, you still have to do 40+ GETs but each one is fast with no response-body (ontology sent down the wire) then the next request for the 303'd to URI comes right out of the cache. It's still 40+ requests unless you code around it in some way, but it's better than 40+ requests and 40+ copies of the single ontology. The above, together with the deployment for FOAF is a v good reason *not* to use slash URIs for ontologies - ask Dan Bri about the FOAF rewrite rules for a second opinion on that :p Hope that explains, Best, Nathan
Re: Is 303 really necessary - demo
Ian Davis wrote: Hi all, To aid discussion I create a small demo of the idea put forth in my blog post http://iand.posterous.com/is-303-really-necessary Here is the URI of a toucan: http://iandavis.com/2010/303/toucan Ian, where's the demo of /toucan#frag so everybody can see that you can use 200 OK *and* keep the graph clean? will you give it fair air time in the (non-)debate? will you show us a comparison of the two and benefits of each? does this break the web and if so, how? Of course it doesn't break the web, anybody who says that being HTTP friendly breaks the web is clearly wrong. Wrong question, correct question is if I 200 OK will people think this is a document, to which the answer is yes. You're toucan is a :Document.
Re: Is 303 really necessary?
On Fri, 2010-11-05 at 12:11 +, Norman Gray wrote: Greetings, On 2010 Nov 4, at 13:22, Ian Davis wrote: http://iand.posterous.com/is-303-really-necessary I haven't been aware of the following formulation of Ian's problem+solution in the thread so far. Apologies if I've missed it, or if (as I guess) it's deducible from someone's longer post. httpRange-14 requires that a URI with a 200 response MUST be an IR; a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. Is that about right? That fits in with Harry's remarks about IRW, and the general suspicion of deriving important semantics from the details of the HTTP transaction. Here, the only semantics derivable from the transaction is defeasible. In the absence of RDF, this is equivalent to the httpRange-14 finding, so might require only adjustment, rather than replacement, of httpRange-14. Very nice. That seems like an accurate and very helpful way of looking at Ian's proposal. Dave
Re: Is 303 really necessary?
Dave Reynolds wrote: On Fri, 2010-11-05 at 12:11 +, Norman Gray wrote: Greetings, On 2010 Nov 4, at 13:22, Ian Davis wrote: http://iand.posterous.com/is-303-really-necessary I haven't been aware of the following formulation of Ian's problem+solution in the thread so far. Apologies if I've missed it, or if (as I guess) it's deducible from someone's longer post. httpRange-14 requires that a URI with a 200 response MUST be an IR; a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. Is that about right? That fits in with Harry's remarks about IRW, and the general suspicion of deriving important semantics from the details of the HTTP transaction. Here, the only semantics derivable from the transaction is defeasible. In the absence of RDF, this is equivalent to the httpRange-14 finding, so might require only adjustment, rather than replacement, of httpRange-14. Very nice. That seems like an accurate and very helpful way of looking at Ian's proposal. The other way of looking at it, is that the once clear message of: Don't use /slash URIs for things, use fragments, and if you flat out refuse to do this then at least use the 303 to keep distinct names has been totally lost. The advice is not that /slash URIs are okay and use them if you like, it's that they're not ok and you should be using #fragments. Don't dress the TAG finding up in other words to make it seem more favourable than it actually is. I think this needs to be made clear for all those who don't realise. Best, Nathan
Re: Is 303 really necessary?
Hi Ian, Do you suggest that the two resources (/toucan and /doc in your example) should return the exact same data? If yes, don't you think this would lead to people not getting the distinction between the two URIs at all, and thus, mixing them up even more? Personally, I think that the hard part is the distinction between the URIs. Once that is understood and accepted, the 303 becomes kind of obvious (even more so than the hash approach). I don't have a lot of experience teaching LD to developers to back up this statement, though. -- Vasiliy Faronov
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Hi Robert, Thanks for the response, good to hear from an implementor. On 5 November 2010 10:41, Robert Fuller robert.ful...@deri.org wrote: ... However... with regard to publishing ontologies, we could expect additional overhead if same content is delivered on retrieving different Resources for example http://example.com/schema/latitude and http://example.com/schema/longitude . In such a case ETag could be used to suggest the contents are identical, but not sure that is a practical solution. I expect that without 303 it will be more difficult in particular to publish and process ontologies. This is useful to know thanks. I don't think the ETag approach works as it's intended to version a specific resource, not be carried across resources. One way to avoid the overhead is to strongly recommend # URIs for vocabularies. This seems to be increasingly the norm. It also makes them easier to work with (you often want the whole document) L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
RE: What would break, a question for implementors? (was Re: Is 303 really necessary?)
Hi Nathan - thanks for clear answer. I see the point and also the argument for using hash URIs with ontologies. In practice how I get round this prob is to preload my triple store with the handful of common ontologies I know I'm going to use, so don't need to deref them as I go along. Cheers Bill -Original Message- From: Nathan [mailto:nat...@webr3.org] Sent: Fri 11/5/2010 1:12 PM To: bill.robe...@planet.nl Cc: public-lod@w3.org; Dan Brickley Subject: Re: What would break, a question for implementors? (was Re: Is 303 really necessary?) bill.robe...@planet.nl wrote: Hi Nathan I'm not saying you're wrong - but could you explain why it would be a pain for FOAF terms to return 200? Which kinds of application are dereferencing those terms and relying on a 303 response? eg http://xmlns.com/foaf/0.1/Person currently 303s to http://xmlns.com/foaf/spec/ What would break if http://xmlns.com/foaf/0.1/Person returned that same content with a status code of 200? Just trying to understand the issue Hi Bill, Good question :) If you consider a basic linked data client, with a basic ontology/schema awareness, for instance one which shows peoples FOAF profiles and uses the nice rdfs:label's for properties rather than foaf:Person. It's going to have to GET the ontology, now when it cycles through the properties it'll find http://xmlns.com/foaf/0.1/Person and GET it, then hopefully cache it against the URL specified in the [content?] location of the final request (be that 1 or many requests). When you 200 OK the response then the ontology will be stored against http://xmlns.com/foaf/0.1/Person so when you hit http://xmlns.com/foaf/0.1/knows you need to do another GET, and be returned a full ontology again, thus you end up with 40+ requests with full responses and 40+ cached versions of the single ontology. Unless you code around it in some way, make a provision for FOAF. However, if you use 303's the then first GET redirects there, then you store the ontology against the redirected-to URI, you still have to do 40+ GETs but each one is fast with no response-body (ontology sent down the wire) then the next request for the 303'd to URI comes right out of the cache. It's still 40+ requests unless you code around it in some way, but it's better than 40+ requests and 40+ copies of the single ontology. The above, together with the deployment for FOAF is a v good reason *not* to use slash URIs for ontologies - ask Dan Bri about the FOAF rewrite rules for a second opinion on that :p Hope that explains, Best, Nathan
Re: What would break, a question for implementors? (was Re: Is 303 really necessary?)
bill.robe...@planet.nl wrote: Hi Nathan - thanks for clear answer. I see the point and also the argument for using hash URIs with ontologies. Most welcome, and glad it helped :) In practice how I get round this prob is to preload my triple store with the handful of common ontologies I know I'm going to use, so don't need to deref them as I go along. Snap, however the big caveat is that as soon as I followed the paradigm a bit further and hit client side applications which use the web as a data tier (read write web of linked data) where typically you just leverage HTTP caching, and where a triple store isn't particularly ideal (or even needed) the importance of these things became somewhat more noticeable. I have to say, that if I hadn't taken this move, then I probably wouldn't be quite as passionate as I am about these things. Linked Data should (must?) be HTTP friendly, and slash URIs for both ontologies and data are most definitely not, even to deal with foaf with the current 303's you need to hard code rules around it, or embed the ontology in your application (in js code!). Give it some time and I'm sure it won't just be a handful of us shouting OMG that was a mistake and a half. Best, Nathan
Re: Is 303 really necessary - demo
On Fri, Nov 5, 2010 at 12:37 PM, Nathan nat...@webr3.org wrote: Ian Davis wrote: Hi all, To aid discussion I create a small demo of the idea put forth in my blog post http://iand.posterous.com/is-303-really-necessary Here is the URI of a toucan: http://iandavis.com/2010/303/toucan Ian, where's the demo of /toucan#frag so everybody can see that you can use 200 OK *and* keep the graph clean? will you give it fair air time in the (non-)debate? will you show us a comparison of the two and benefits of each? does this break the web and if so, how? Of course it doesn't break the web, anybody who says that being HTTP friendly breaks the web is clearly wrong. Wrong question, correct question is if I 200 OK will people think this is a document, to which the answer is yes. You're toucan is a :Document. That assertion would be wrong if the response contained a Content-Location header pointing to the specific document resource. Cheers, Mike
Re: Is 303 really necessary?
Hi Nathan, The other way of looking at it, is that the once clear message of: Don't use /slash URIs for things, use fragments, and if you flat out refuse to do this then at least use the 303 to keep distinct names has been totally lost. I've never encountered this clear message before. Can you please point me to a couple of places where it is clearly stated? -- Vasiliy Faronov
Re: Is 303 really necessary - demo
Mike Kelly wrote: On Fri, Nov 5, 2010 at 12:37 PM, Nathan nat...@webr3.org wrote: Ian Davis wrote: Hi all, To aid discussion I create a small demo of the idea put forth in my blog post http://iand.posterous.com/is-303-really-necessary Here is the URI of a toucan: http://iandavis.com/2010/303/toucan Ian, where's the demo of /toucan#frag so everybody can see that you can use 200 OK *and* keep the graph clean? will you give it fair air time in the (non-)debate? will you show us a comparison of the two and benefits of each? does this break the web and if so, how? Of course it doesn't break the web, anybody who says that being HTTP friendly breaks the web is clearly wrong. Wrong question, correct question is if I 200 OK will people think this is a document, to which the answer is yes. You're toucan is a :Document. That assertion would be wrong if the response contained a Content-Location header pointing to the specific document resource. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
Re: Is 303 really necessary - demo
I might be wrong but I dont like it much . Sindice would index it as 2 documents. http://iandavis.com/2010/303/toucan http://iandavis.com/2010/303/toucan.rdf i *really* would NOT want to different URLs resolving to the same thing thanks Giovanni On Fri, Nov 5, 2010 at 10:43 AM, Ian Davis m...@iandavis.com wrote: Hi all, To aid discussion I create a small demo of the idea put forth in my blog post http://iand.posterous.com/is-303-really-necessary Here is the URI of a toucan: http://iandavis.com/2010/303/toucan Here is the URI of a description of that toucan: http://iandavis.com/2010/303/toucan.rdf As you can see both these resources have distinct URIs. I created a new property http://vocab.org/desc/schema/description to link the toucan to its description. The schema for that property is here: http://vocab.org/desc/schema (BTW I looked at the powder describedBy property and it's clearly designed to point to one particular type of description, not a general RDF one. I also looked at http://ontologydesignpatterns.org/ont/web/irw.owl and didn't see anything suitable) Here is the URI Burner view of the toucan resource and of its description document: http://linkeddata.uriburner.com/about/html/http://iandavis.com/2010/303/toucan http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan.rdf I'd like to use this demo to focus on the main thrust of my question: does this break the web and if so, how? Cheers, Ian P.S. I am not fully caught up on the other thread, so maybe someone has already produced this demo
