Re: Profiles in Linked Data
On Thu, May 7, 2015 at 9:13 AM, Svensson, Lars l.svens...@dnb.de wrote: Mark, On Thu, May 7, 2015 at 7:05 AM, Martynas Jusevičius marty...@graphity.org wrote: On the other hand, it seems like you want different descriptions of a resource -- so it seems to me that these should in fact be different resources? That could be split into http://example.org/some/resource/dcat and http://example.org/some/resource/premis, for example. ^ This. Can you please elaborate a bit on this? I'm not quite sure I get your point. Only that IME, having separate URIs is almost always the best option because it allows problems to be solved within the linked data model itself. To your mobile-optimized page example, I'd add that from a REST POV, that is a separate resource because representations are consistently different (aka they have different membership functions).
Re: URIs within URIs
On Aug 22, 2014 12:23 PM, Ruben Verborgh ruben.verbo...@ugent.be wrote: This gets us to a deeper difference between (current) Linked Data and the rest of the Web: Linked Data uses only links as hypermedia controls, whereas the remainder of the Web uses links *and forms*. Forms are a much more powerful mechanism to discover information. Indeed. Interestingly, this use case was the first one I published as an example of RDF Forms; http://www.markbaker.ca/2003/10/UriProxy/
Re: Updated LOD Cloud Diagram - Missed data sources.
On Fri, Jul 25, 2014 at 6:04 AM, Christian Bizer ch...@bizer.de wrote: Hi, But I wonder where so many other sites (including mine) went ? The problem with crawling the Web of Linked Data is really that it is hard to get the datasets on the edges that set RDF links to other sources but are not the target of links from well-connected sources. I'm curious, why you don't just crawl the whole Web looking for linked data? Mark.
Re: Exchanging Links with LINK and UNLINK
Link exchange over HTTP, awesome. I hope you support the 402 status code ;)
Re: representing hypermedia controls in RDF
On Thu, Nov 21, 2013 at 1:01 PM, Markus Lanthaler markus.lantha...@gmx.net wrote: +public-hydra On Thursday, November 21, 2013 5:11 PM, Mark Baker wrote: Cool. Very similar to RDF Forms in important ways, though I think RDF Forms internalizes some useful features that Hydra could benefit from; stripping out information that isn't required (or isn't an optimization) for a state transition, e.g. DeleteResourceOperation. Right, we already discussed removing all those prefided *ResourceOperations. The only reason I included them in the first place was to bootstrap the system so that developers could build simple CRUD-based systems without having to define these things themselves. This is ISSUE-5 [1] btw. :-) Yep, I started down that path too. Then I had to use it :) PUT should also be usable without any required parameterization, Not so convinced about that.. It's a relatively minor point, but the idea there is that the common case will involve retrieving a representation, modifying it, then PUTting it back. Obviously the media type of initially retrieved representation is all you need in that case. Not to suggest it's the only case, though, so I'm all for non-authoritative optimizations. though declaring an accepted media type (something that seems to be missing from hydra) Right.. Hydra currently assumes the client uses the media type it used to retrieve the API documentation or the entry point for its requests. This leaves binaries out, I know. It isn't currently specified but I think that could be handled by specific classes together with hydra:expects as well. I haven't quite figured out hydra:expects. The examples show that it's something other than a media type, and moreover, something (e.g. comment) which I'd normally use a predicate/rel for. can be considered an optimization. And POST can be used for much more than creation, so I think CreateResourceOperation is a misnomer (or else overly specific). Of course.. that's the whole reason that Operations thing exists in the first place. But it isn't Hydra's job to define them. Concrete APIs will create their own by subclassing Operation (or one of the three others unless we remove it). Ok. Also, the next version of RDF Forms has been sitting in my head for a few years after collecting a little bit of experience with the current version. One of the big changes I would make is to go fully predicate based rather than class based simply because I expect it would be more flexible and also fit better into, e.g. HTML or the Link header. So if I had a POST-accepting resource, instead of this: http://example.org/res1 a hydra:CreateResourceOperation . I'd go with; hydra:sink http://example.org/res1 . (yah, that example represents at least 3 improvements I'd suggest for the language - sorry if it's too dense) Indeed. I don't understand that example at all. Could you explain it a bit more in detail? Well, the most important difference is the use of the predicate. The intent there is that if you consider the two resources in play - the one containing the form/affordances, and the one receiving the data that results from the form being used - then they share a generic relationship which can be called a sink, aka The second resource acts as a sink for data that emerges as a result of the affordances in the first being followed. So sink is 1-to-1 with HTTP POST, and would of course require additional parameterization, but that's the gist. For documents containing multiple forms, I guess you'd want a subject that wasn't the document itself, but some identifier for the form; and you'd also need that same id to hook the parameters to, obv. [1] https://github.com/HydraCG/Specifications/issues/5 We may or may not need one depending how we connect parameterization to operations after the required decisions surrounding them have been mode. Obviously we need to support parameterized GET requests though. And FWIW, I don't like the Link construct. If the publisher doesn't want me to crawl some particular subset of their URI space, they should describe that space in robots.txt.
Re: representing hypermedia controls in RDF
On Thu, Nov 21, 2013 at 6:14 AM, Markus Lanthaler markus.lantha...@gmx.net wrote: Hi Ruben, You probably already expected me asking this :-) Why not Hydra [1]? Cool. Very similar to RDF Forms in important ways, though I think RDF Forms internalizes some useful features that Hydra could benefit from; stripping out information that isn't required (or isn't an optimization) for a state transition, e.g. DeleteResourceOperation. PUT should also be usable without any required parameterization, though declaring an accepted media type (something that seems to be missing from hydra) can be considered an optimization. And POST can be used for much more than creation, so I think CreateResourceOperation is a misnomer (or else overly specific). Also, the next version of RDF Forms has been sitting in my head for a few years after collecting a little bit of experience with the current version. One of the big changes I would make is to go fully predicate based rather than class based simply because I expect it would be more flexible and also fit better into, e.g. HTML or the Link header. So if I had a POST-accepting resource, instead of this: http://example.org/res1 a hydra:CreateResourceOperation . I'd go with; hydra:sink http://example.org/res1 . (yah, that example represents at least 3 improvements I'd suggest for the language - sorry if it's too dense) I have some other thought similar to Ruben's too. But I've gone ahead and joined the group, and once I'm caught up on the discussion to date, we can discuss this further over there.
Re: Again on endpoint server limits [WAS Re: Public SPARQL endpoints:managing (mis)-use and communicating limits to users.]
On Thu, May 30, 2013 at 10:33 AM, Kingsley Idehen kide...@openlinksw.com wrote: On 5/30/13 9:13 AM, Andrea Splendiani wrote: Hi, let me get back to this thread for two reasons. 1) I was wondering whether the report on DBPedia queries cited below was already published. 2) I have recently tried to use DBPedia for some simple computation and I have a problem. Basically a query for all cities whose population is larger than that of the countries they are in returns a random number of results. I suspect this is due to hitting some internal computation load limits, and there is not much I can do with limits, I think, as results are no more than 20 o so. Now, I discovered this by chance. If this due to some limits, I would much better prefer an error message (query too expensive) than partial results. Is there a way to detect that these results are partial ? Of course, via the response headers of the SPARQL query: 1. X-SQL-State: 2. X-SQL-Message: We are also looking at using HTTP a bit more here i.e., not returning 200 OK if the resultset is partial. Kingsley - The problem isn't with HTTP, it's with SPARQL's mapping to HTTP, so the solution isn't to patch HTTP, it's to fix the mapping. The correct-by-HTTP way of doing this is for the server to publish a GET form/template (even if just as documentation, if you don't want to go the extra mile) which constructs a URI that returns the desired data. By virtue of publishing this form/template/docs, the server is acknowledging its support of this potentially expensive query, which suggests that they'd need to do one or both of a) creating an index specific to this query, b) enabling caching so that the query only needs to be performed when there's a reasonable chance that the data has changed, and also falls below some internal cost-of-servicing value set by the publisher. BTW, it's great to see the problems I discussed with SPARQL/HTTP many years ago described so well by a SPARQL user; http://www.markbaker.ca/blog/2006/08/sparql-useful-but-not-a-game-changer/ Mark.
Re: Content negotiation negotiation
On Tue, Apr 23, 2013 at 1:42 PM, Hugh Glaser h...@ecs.soton.ac.uk wrote: On 22 Apr 2013, at 12:18, Phillip Lord phillip.l...@newcastle.ac.uk wrote: snip We need to check for content negotiation; I'm not clear, though, how we are supposed to know what forms of content are available. Is there anyway we can tell from your website that content negotiation is possible? Ah, and interesting question. I don't know of any, but maybe someone else does? Client-side conneg, look for Link rel=alternate headers in response Server-side conneg, look for Vary: Content-Type in response Mark.
Re: SPARQL, philosophy n'stuff..
On Fri, Apr 19, 2013 at 9:57 AM, Kingsley Idehen kide...@openlinksw.com wrote: The original query language you describe is what makes the Web, the Web. We can't just swap it out and expect the resulting architecture to still be the Web and exhibit its same desirable architectural properties. But I don't see how the following break the model: 1. sparql-protocol 2. sparql-update protocol 3. sparql-graph-store protocol. They are all HTTP based. Yes, but so was SOAP :P That isn't to say that there are strong architectural similarities between the above (in general) and SOAP, only that both misuse HTTP to the point where they're not REST, and their relationship to the Web is tenuous at best. sparql-update doesn't seem to have anything to do with HTTP AFAICT (other than being tunnelled over POST), but the other two get caught up in specifying what amounts to a profile of HTTP rather than in using hypermedia to fit a SPARQL implementation behind an HTTP interface. For example, GSP standardizes on the graph query parameter, rather than use a GET form and a relation. Ditto for SPARQL 1.1's use of query. The problem here, and why SPARQL/HTTP solutions end up non-RESTful, is that both are application protocols. How do you map FTP onto HTTP? HTTP onto IMAP? POP onto FTP? You don't, because it makes no sense, just as it makes no sense (to me) to map SPARQL onto HTTP. What you *can* do, is build a pipeline (a proxy), where a client talks HTTP (and only HTTP) to an HTTP server that is configured to talk FTP to an FTP server. The key point there is that the client has absolutely no idea that FTP is in use... which is as it should be with SPARQL. I'd be repeating myself to respond to each of your subsequent points separately, so won't ;) Mark.
Re: SPARQL, philosophy n'stuff..
Kingsley, On Thu, Apr 18, 2013 at 11:21 AM, Kingsley Idehen kide...@openlinksw.com wrote: The global Web is a functional Data Space equipped with a declarative query language based on the Web's architectural essence (URIs and HTTP). It can work, and will work. The challenge is getting folks to hone in to what possible circa. 2013 :-) I can accept that definition of query language, and agree... but don't believe we need a separate query language to do these new things. The original query language you describe is what makes the Web, the Web. We can't just swap it out and expect the resulting architecture to still be the Web and exhibit its same desirable architectural properties. There are solutions to these problems within the constraints of REST. Let's explore those first before jumping to the conclusion that we need to expose SPARQL. Mark.
Re: Public SPARQL endpoints:managing (mis)-use and communicating limits to users.
On Fri, Apr 19, 2013 at 9:25 AM, Rob Warren war...@muninn-project.org wrote: Hi Rob, There is a fundamental problem with HTTP status codes. Lets say a user submits a complex but small sparql request. My server sees the syntax is good and starts to reply in good faith. This means the server starts the http response and sends an 200 OK Some results are being send However, during the evaluation the server gets an exception. What to do? I can't change the status code anymore... Is this really so? Failures in large transfers are common and there are a few ways to detect it from the client's end (wrong format, wrong Content-Length and dropped connection). Yes, this is a well known (to HTTP geeks) problem with HTTP framing. Trailers were introduced to solve similar problems, but because the response status code isn't a header, there's no standard way to communicate this is the new status code. And even if they're were, it can't easily be communicated through existing HTTP client libraries without an interface change which makes it prohibitively expensive to deploy. IIRC, HTTP 2.0 framing will address this. Mark.
Re: SPARQL, philosophy n'stuff..
On Thu, Apr 18, 2013 at 10:41 AM, Barry Norton barry.nor...@ontotext.com wrote: On 18/04/2013 15:35, Jürgen Jakobitsch SWC wrote: I think the problem is that many people (especially web developers) have not yet realized that SPARQL *IS* already a REST API May I rephrase? SPARQL is already at least as close to a subset of REST principles as 90% of what the Web calls 'REST APIs' I'd agree too, but you're setting that bar way, way low. REST is still a best practice for most Web apps, even if a lot of people screw it up. Mark.
Re: Proper usage of HTTP for LD servers, clients, crawlers etc.
On Fri, Apr 1, 2011 at 1:44 AM, Markus Luczak-Rösch markus.luczak-roe...@fu-berlin.de wrote: Hi all! Since on the LDOW11 and USEWOD workshops at WWW there was the recent discussion about using HTTP referrers properly when browsing, crawling etc. linked data (short using it) I would like to add another thing that I was wondering about. If endpoints deliver no content to the client e.g. if the client performs a SPARQL query that yields no results, servers answer HTTP status code 200 and deliver some content that holds the information that there were no results. As far as I see, there is the HTTP status code 204 for exactly this, isn't it? (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) No, 204 is for the case when there's no actual representation body in the HTTP response, as demonstrated by the requirement that The 204 response MUST NOT include a message-body. Mark.
Re: CORS question (was Re: Proposal to assess the quality of Linked Data sources)
On Fri, Feb 25, 2011 at 6:22 AM, Damian Steer d.st...@bristol.ac.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for changing the topic (and, indeed, sailing off list topic). On 24/02/11 18:28, Melvin Carvalho wrote: http://www.w3.org/wiki/CORS_Enabled [reproduced for convenience] ... To give Javascript clients basic access to your resources requires adding one HTTP Response Header, namely: Access-Control-Allow-Origin: * I tried this recently and it didn't work on either Safari or Chrome (iirc) without adding: Access-Control-Allow-Methods: GET Has anyone else had this issue? Nope, plain old Access-Control-Allow-Origin: * worked for me this week on chrome-stable (9.0.597.98). Mark.
Re: quick advice on content negotiation
On Tue, Dec 8, 2009 at 11:43 AM, Nathan nat...@webr3.org wrote: in addition adding the extension .n3 / .rdf to the uri causes content RDF to be returned instead. How is that information communicated to the world? Is it documented somewhere, or expressed in-band? If not the latter, then I'd say that's not passable because, from a REST POV it's not respecting the hypermedia constraint. I'd suggest returning a Link header using the alternate relation type, e.g. GET /user/23 HTTP/1.1 Host: example.org Accept: application/rdf+xml -- HTTP/1.1 200 Ok Content-Type: application/rdf+xml Link: http://example.org/user/23.n3; rel=alternate; type=text/n3 Link: http://example.org/user/23.html; rel=alternate; type=text/html ... Mark.
Re: [pedantic-web] Re: quick advice on content negotiation
On Tue, Dec 8, 2009 at 12:33 PM, Nathan nat...@webr3.org wrote: actually.. how about this.. Expressing the links in HTML is fine too. GET /user/23 HTTP/1.1 Host: example.org Accept: application/rdf+xml -- HTTP/1.1 200 Ok Content-Type: application/rdf+xml Link: http://example.org/user/23; rel=alternate; type=text/rdf+n3 Link: http://example.org/user/23; rel=alternate; type=application/rdf+json and so forth.. note the URI never changes only the type.. You really need the specific URIs otherwise it defeats the point of Link header and your use of file extension convention remains hidden from the world. Mark.
Re: quick advice on content negotiation
On Tue, Dec 8, 2009 at 12:35 PM, Kingsley Idehen kide...@openlinksw.com wrote: Nathan: see URIBurner or DBpedia responses which also include LINK response headers :-) I had no idea the community was using it. Excellent! Sequence example via cURL: kidehen$ curl -I -H Accept: text/html http://dbpedia.org/resource/London HTTP/1.1 303 See Other Server: Virtuoso/06.00.3124 (Solaris) x86_64-sun-solaris2.10-64 VDB Connection: close Content-Type: text/html; charset=ISO-8859-1 Date: Tue, 08 Dec 2009 17:31:21 GMT Accept-Ranges: bytes Location: http://dbpedia.org/page/London Content-Length: 0 kidehen$ curl -I -H Accept: text/html http://dbpedia.org/page/London HTTP/1.1 200 OK Server: Virtuoso/06.00.3124 (Solaris) x86_64-sun-solaris2.10-64 VDB Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Date: Tue, 08 Dec 2009 17:31:37 GMT Accept-Ranges: bytes Expires: Tue, 15 Dec 2009 17:31:35 GMT Link: http://dbpedia.org/data/London.rdf; rel=alternate; title=Metadata in RDF/XML format, http://dbpedia.org/data/London.n3; rel=alternate; title=Metadata in N3/Turtle format, http://dbpedia.org/data/London.json; rel=alternate; title=Metadata in JSON+RDF format Content-Length: 2095119 That seems to be missing the type attribute which is required for automated variant selection. Humans could figure it out by the title of course... Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
On Wed, Nov 25, 2009 at 6:08 PM, Michael Nelson m...@cs.odu.edu wrote: I disagree. I would say that agent-driven negotiation is by far the most common form of conneg in use today. Only it's not done through standardized means such as the Alternates header, but instead via language and format specific links embedded in HTML, e.g. Click here for the PDF version, or a Language/country-selector dropdown in the page header, or even via Javascript based selection. While the exact line between them might be hard to draw, I'd argue those aren't HTTP-level events, but instead are HTML-level events. In other words, I would call those examples navigation. In addition, navigation works well for things that can be expressed in HTML wrappers (e.g., click here for the PDF version), but not really for embed/img tags where you want to choose between, say, .png .gif. I don't draw much of a distinction there, at least for the purposes of discussions like this; they are all URLs in an HTTP response message. Server driven conneg, in comparison, is effectively unused. Ditto for transparent negotiation. I think that is an unfair characterization. I won't guess as to how often it is done, but it is done. It is just not perceived by the user. I didn't mean to imply it wasn't done. As Richard (and Larry, in his referenced message) point out, User-Agent conneg is pretty common. I was just trying to point out that it's not used nearly as often as client selection. Almost every browser sends out various Accept request headers, and it is not uncommon to have Vary and TCN: Choice response headers (check responses from w3c.org, for example). When done with the 200 response + Content-Location header, the URI that the browser displays does not change. I used to use w3.org as an example too, but I've learned since that it's the exception, not the rule, for Web site design. So while I think you are describing agent-driven CN (or something very similar), I also think it would be desirable to go ahead and get the full monty and define the appropriate Accept header and allow server-driven transparent CN. Agent-driven CN is still available for clients that wish to do so. I just don't understand the desire for server driven conneg when agent driven is the clear winner and has so many advantages; we'll have to agree to disagree on that; I think they are different modalities. Fair enough. I'm just offering you my advice based on my extensive experience in this space. You're free not to believe me, of course 8-) As long as you're also supporting agent driven conneg, I'm happy. - not needing to use the inconsistently-implemented Vary header, so there's no risk of cache pollution. see http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989 - more visible to search engines - simpler for developers, as it's just links returned by the server like the rest of their app. no need for new server side modules either I would suggest these are among the reasons we champion the 302 response + Location header approach (as opposed to 200/Content-Location) -- it makes the negotation more transparent Ah, I see. Yes, I agree that's a good design choice. You might also be interested to read this, where one of the RFC 2616 editors apologizes for supporting server driven conneg; http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html Note that he refers to HTTP conneg being broken, but is actually only talking about server driven conneg. I would counter with that fact that CN features prominently in: http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ http://www.w3.org/TR/cooluris/ Given the role CN plays in these recent documents, it would seem CN has some measure of acceptance in the LOD community. Content negotiation is a valuable tool, so I'm glad there's interest, but IMO, both of those documents misrepresent it by only describing the server-driven form. Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
Michael, On Wed, Nov 25, 2009 at 1:07 AM, Michael Nelson m...@cs.odu.edu wrote: What you describe is really close to what RFC 2616 calls Agent-driven Negotiation, which is how CN exists in the absence of Accept-* request headers. That's correct. But the TCN: Choice approach is introduced as an optimization. The idea is that if you know you prefer .en, .pdf and .gz then tell the server when making your original request and it will do its best to honor those requests. We think adding an orthogonal dimension for CN will be similar: if you know you prefer .en, .pdf, .gz and .20091031, then tell the server when making your original request and it will do its best to honor those requests. I understand. In practice, agent-driven CN is rarely done (I can only guess as to why). In practice, you get either server-driven (as defined in RFC 2616) or transparent CN (introduced in RFC 2616 (well, RFC 2068 actually), but really defined in RFCs 2295 2296). See: http://httpd.apache.org/docs/2.3/content-negotiation.html I disagree. I would say that agent-driven negotiation is by far the most common form of conneg in use today. Only it's not done through standardized means such as the Alternates header, but instead via language and format specific links embedded in HTML, e.g. Click here for the PDF version, or a Language/country-selector dropdown in the page header, or even via Javascript based selection. Server driven conneg, in comparison, is effectively unused. Ditto for transparent negotiation. So while I think you are describing agent-driven CN (or something very similar), I also think it would be desirable to go ahead and get the full monty and define the appropriate Accept header and allow server-driven transparent CN. Agent-driven CN is still available for clients that wish to do so. I just don't understand the desire for server driven conneg when agent driven is the clear winner and has so many advantages; - not needing to use the inconsistently-implemented Vary header, so there's no risk of cache pollution. see http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989 - more visible to search engines - simpler for developers, as it's just links returned by the server like the rest of their app. no need for new server side modules either You might also be interested to read this, where one of the RFC 2616 editors apologizes for supporting server driven conneg; http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html Note that he refers to HTTP conneg being broken, but is actually only talking about server driven conneg. I think that makes for a pretty strong case against it, and I haven't even elaborated on the architectural problems I perceive with it (though some of the advantages above relate closely). Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
Herbert, On Tue, Nov 24, 2009 at 6:10 PM, Herbert Van de Sompel hvds...@gmail.com wrote: Just to let you know that our response to some issues re Memento raised here and on Pete Johnston's blog post (http://efoundations.typepad.com/efoundations/2009/11/memento-and-negotiating-on-time.html) is now available at: http://www.cs.odu.edu/~mln/memento/response-2009-11-24.html Regarding the suggestion to use the Link header, I was thinking the same thing. But the way you describe it being used is different than how I would suggest it be used. Instead of providing a link to each available representation, the server would just provide a single link to the timegate. The client could then GET the timegate URI and find either the list of URIs (along with date metadata), or some kind of form-like declaration that would permit it to specify the date/time for which it desires a representation (e.g. Open Search). Perhaps this is what you meant by timemap, I can't tell, though I don't see a need for the use of the Accept header in that case if the client can either choose or construct a URI for the desired archived representation. As for the current state issue, you're right that it isn't a general constraint of Web architecture. I was assuming we were talking only about the origin server. Of course, any Web component can be asked for a representation of any resource, and they are free to answer those requests in whatever way suits their purpose, including providing historical versions. Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
On Mon, Nov 23, 2009 at 1:01 AM, Peter Ansell ansell.pe...@gmail.com wrote: The issue with requiring people to direct requests at the URI for the Resource X at time T is that the circular linking issue I described previously comes into play because people need to pre-engineer their URI's to be compatible with a temporal dimension. I would recommend the use of a query parameter. If the user didn't know exactly what time scales were used by the server they would either need to follow a roughly drawn up convention, such as //MM/DD/meaningfulresourcename, or they would have to find an index somewhere, neither of which are as promising for the future of the web as having the ability to add another header to provide the desired behaviour IMO. I'm not sure what criteria you're basing that evaluation on, but IME it's far simpler to deploy a new relation type than a new HTTP header. Headers are largely opaque to Web developers. The documentation of the Vary header [1] seems to leave the situation open as to whether the server needs to be concerned about which or any Headers dictate which resource representation is to be returned. Caching in the context of HTTP/1.1 may have been designed to temporary, but I see no particular reason why a temporal Accept-* header, together with the possibility of its addition to Vary, couldn't be used on the absolute time dimension. It seems much cleaner than adding an extra command to HTTP, or requiring some other non-HTTP mechanism altogether. The extra header would never stop a server from returning the current version if it doesn't recognise the header, or it doesn't keep a version history, so it should be completely backwards compatible. Yes, Vary should, in theory, be used for this purpose. Unfortunately, in practice, due to a bug in IE, it has the effect of disabling caching in the browser and so you don't see it used very much, at least not for browser based applications; http://www.ilikespam.com/blog/internet-explorer-meets-the-vary-header Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
Hi Chris, On Fri, Nov 20, 2009 at 1:07 PM, Chris Bizer ch...@bizer.de wrote: Hi Michael, Georgi and all, just to complete the list of proposals, here another one from Herbert Van de Sompel from the Open Archives Initiative. Memento: Time Travel for the Web http://arxiv.org/abs/0911.1112 The idea of Memento is to use HTTP content negotiation in the datetime dimension. By using a newly introduced X-Accept-Datetime HTTP header they add a temporal dimension to URIs. The result is a framework in which archived resources can seamlessly be reached via the URI of their original. Sounds cool to me. Anybody an opinion whether this violates general Web architecture somewhere? IMO, it does. The problem is that an HTTP request with the Accept-Datetime header is logically targeting a different resource than the one identified in the Request-URI. Accept-* headers are for negotiating the selection of resource *representations*, not resources. Resource selection should always be handled via hypermedia. Mark.
Re: RDF Update Feeds + URI time travel on HTTP-level
On Sun, Nov 22, 2009 at 11:59 PM, Peter Ansell ansell.pe...@gmail.com wrote: It should be up to resource creators to determine when the nature of a resource changes across time. A web architecture that requires every single edit to have a different identifier is a large hassle and likely won't catch on if people find that they can work fine with a system that evolves constantly using semi-constant identifiers, rather than through a series of mandatory time based checkpoints. You seem to have read more into my argument than was there, and created a strawman; I agree with the above. My claim is simply that all HTTP requests, no matter the headers, are requests upon the current state of the resource identified by the Request-URI, and therefore, a request for a representation of the state of Resource X at time T needs to be directed at the URI for Resource X at time T, not Resource X. Mark.
