Re: Content negotiation: Why always redirect from non-information resource to information resource?
2010/1/27 Ross Singer : > On Tue, Jan 26, 2010 at 7:35 PM, Christoph LANGE > wrote: > >> So far, I don't understand why it is recommended to have separate URIs for >> the >> non-information resource and the (RDF/XML) information resource. > > This is because the URI for the RDF/XML is an identifier for the > _document describing_ the non-information resource, but not the actual > resource. They need to be disambiguated, because otherwise you > wouldn't ever be able to assert anything about the RDF describing the > resource (e.g. provenance or quality) - the RDF is its own resource, > as well. > > To use an example Ian Davis uses to describe this: > > If you say http://iandavis.com/id/me sucks, you're saying Ian, the > human being, sucks. > > If you say http://iandavis.com/id/me.rdf sucks, you are objecting to > the way he made his FOAF document. > > (hey, it's his example, not mine) > > "You are not your FOAF." Taken from a different angle, this issue might be caused by the lack of a domain specific way to say that a "document sucks" as opposed to saying that a "person sucks". Disambiguating everything is a pipe dream IMO. We would be much better to focus on domain specific vocabularies, as the RDF user can actually choose what to utilise for the property even if they can't always disambiguate the object URI they are focusing on. Cheers, Peter
Re: Content negotiation: Why always redirect from non-information resource to information resource?
On Tue, Jan 26, 2010 at 7:35 PM, Christoph LANGE wrote: > So far, I don't understand why it is recommended to have separate URIs for the > non-information resource and the (RDF/XML) information resource. This is because the URI for the RDF/XML is an identifier for the _document describing_ the non-information resource, but not the actual resource. They need to be disambiguated, because otherwise you wouldn't ever be able to assert anything about the RDF describing the resource (e.g. provenance or quality) - the RDF is its own resource, as well. To use an example Ian Davis uses to describe this: If you say http://iandavis.com/id/me sucks, you're saying Ian, the human being, sucks. If you say http://iandavis.com/id/me.rdf sucks, you are objecting to the way he made his FOAF document. (hey, it's his example, not mine) "You are not your FOAF." BTW the # uri style doesn't require all of your resources to be in some long document; it just provides the same disambiguation as above, without any need for .htaccess or redirects. So while an HTTP client requests: http://id.loc.gov/authorities/sh2002000569 (which renders an HTML or RDF document), the non-information resource's URI is http://id.loc.gov/authorities/sh2002000569#concept -- distinct from the former (they are different URIs), but available from the same HTTP request. -Ross.
Re: Content negotiation: Why always redirect from non-information resource to information resource?
Hi Georgi, 2010-01-27 01:00 Georgi Kobilarov : > If a client asks the server: "please give me Berlin", the server must > respond with "sorry, can't give you that", because Berlin is a city that > can't be send through the wire (non-information resource), "but look over > there, maybe that's of help". That's a 303 redirect. > > The server is only allowed to respond with an HTTP 200 if it can actually > send what the client wants. thanks, but what if I suppose that my client is software (HTML-aware browser or RDF-aware agent) that does not have any understanding of a city, but just of HTTP? I.e. if I assume that my client just finds the URI http://not-dbpedia.org/Berlin in some RDF on the web (not caring about whether this is an information resource or not) and dereferences it, * case 1: requesting RDF – if the server directly serves RDF from http://not-dbpedia.org/Berlin, this is what the client wants * case 2: requesting HTML – then the server would understand that the content (i.e. the information resource) at http://not-dbpedia.org/Berlin is not what the client wants, it would 303-redirect the client to, say, http://html.not-dbpedia.org/Berlin, which is what the client wants. > A nice workaround are #-URIs (which I prefer...) In our setting we are not planning to rely on "normal" #-URIs, i.e. long documents containing lots of fragments, for various reasons. "Cool URIs" recommends "fake" #-URIs for non-information resources, e.g. http://not-dbpedia.org/Berlin#this (see http://www.w3.org/TR/cooluris/#choosing), but here I don't understand what they are good for. So far, I don't understand why it is recommended to have separate URIs for the non-information resource and the (RDF/XML) information resource. I can understand that it might be desirable for clear communication among humans to have two separate URIs/URLs (that's why it might be hard for me to communicate my point), and I can also understand that from a software engineering point of view the designer of a web server application might not want to privilege a certain data format (e.g. RDF/XML) over the others by making the arbitrary decision to serve that format from the URL that is also used to denote the abstract philosophical concept. I.e. the reasoning in http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14#iddiv1138805816 (essentially the same as what you said above) is clear to me from a philosophical point of view, but not from a technical one. I'm taking a more pragmatic view here, as the information that we would like to serve is not necessarily "the one, true and only concept of Berlin", but rather something more pragmatic, such as "our view of Berlin, as we happen to define it (in RDF)" – and IMHO the latter can as well be unified with an information resource. Or am I entirely missing the point? Cheers, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
Re: Content negotiation: Why always redirect from non-information resource to information resource?
Christoph LANGE wrote: Dear all, in the well-known guides on cool URIs and publishing linked data, there is one thing I don't understand. When doing 303 redirects, there are always three URIs/URLs involved: * U, the URI of the non-information resource (redirects depending on requested MIME type) * U_R, the URL of the RDF information resource * U_H, the URL of the HTML information resource I do understand that it makes sense to have separate URLs for U_R and U_H. Delivering everything, be it RDF or HTML, directly from U (which would technically be possible) would impair cacheability. But why can't we do without U_R and do it like this? * If RDF is requested from U, it is directly served from U * If HTML is requested from U, a 303 redirect to U_H is made. I'd be interested in justifications for the above-mentioned best practice (with 3 URIs/URLs) that are based on semantic considerations and on HTTP architecture. Restrictions imposed by Apache's standard plugins are not relevant to me. Cheers, and thanks in advance, Christoph 303 is a RESTful mechanism for disambigutating a Resource Identifier from the Address of and Information Resource (AWWW parlance). In distributed object technology parlance, this is about distinguishing an Object Identifier from the address of the network addressable Resource (a physical artifact e.g. document) holding its description (metadata). When you use Generic HTTP URIs for Object IDs you have to cater for the duality of this URI form i.e., it embodies an Object Identifier (Name) and an Address (Location) (i.e., Identity/Access duality). Back to 303, this condition arises when your HTTP Identifier is slash rather than # (hash) terminated. Goal: bind an Object ID to its metadata via sophistication of URI abstraction. As for the HTML part, this is about providing an HTML representation of the Object (Resource) metadata rather than being confined to a single representation. Note, these days RDF based resource descriptions are served up in quite a few representations: HTML, HTML + RDFa, N3/Turtle, JSON, RDF/XML, TriX, TriG etc.. Hope this helps. -- Regards, Kingsley Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter: kidehen
RE: Content negotiation: Why always redirect from non-information resource to information resource?
Speaking in non-technical terms: If a client asks the server: "please give me Berlin", the server must respond with "sorry, can't give you that", because Berlin is a city that can't be send through the wire (non-information resource), "but look over there, maybe that's of help". That's a 303 redirect. The server is only allowed to respond with an HTTP 200 if it can actually send what the client wants. A nice workaround are #-URIs (which I prefer...) Cheers, Georgi -- Georgi Kobilarov www.georgikobilarov.com > -Original Message- > From: public-lod-requ...@w3.org [mailto:public-lod-requ...@w3.org] On > Behalf Of Christoph LANGE > Sent: Wednesday, January 27, 2010 12:46 AM > To: Linked Data community > Cc: Vyacheslav Zholudev; Florian Rabe > Subject: Content negotiation: Why always redirect from non-information > resource to information resource? > > Dear all, > > in the well-known guides on cool URIs and publishing linked data, > there is > one thing I don't understand. When doing 303 redirects, there are > always > three URIs/URLs involved: > > * U, the URI of the non-information resource (redirects depending on > requested > MIME type) > * U_R, the URL of the RDF information resource > * U_H, the URL of the HTML information resource > > I do understand that it makes sense to have separate URLs for U_R and > U_H. > Delivering everything, be it RDF or HTML, directly from U (which would > technically be possible) would impair cacheability. > > But why can't we do without U_R and do it like this? > > * If RDF is requested from U, it is directly served from U > * If HTML is requested from U, a 303 redirect to U_H is made. > > I'd be interested in justifications for the above-mentioned best > practice > (with 3 URIs/URLs) that are based on semantic considerations and on > HTTP > architecture. Restrictions imposed by Apache's standard plugins are > not > relevant to me. > > Cheers, and thanks in advance, > > Christoph > > -- > Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype > duke4701
Content negotiation: Why always redirect from non-information resource to information resource?
Dear all, in the well-known guides on cool URIs and publishing linked data, there is one thing I don't understand. When doing 303 redirects, there are always three URIs/URLs involved: * U, the URI of the non-information resource (redirects depending on requested MIME type) * U_R, the URL of the RDF information resource * U_H, the URL of the HTML information resource I do understand that it makes sense to have separate URLs for U_R and U_H. Delivering everything, be it RDF or HTML, directly from U (which would technically be possible) would impair cacheability. But why can't we do without U_R and do it like this? * If RDF is requested from U, it is directly served from U * If HTML is requested from U, a 303 redirect to U_H is made. I'd be interested in justifications for the above-mentioned best practice (with 3 URIs/URLs) that are based on semantic considerations and on HTTP architecture. Restrictions imposed by Apache's standard plugins are not relevant to me. Cheers, and thanks in advance, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
Re: PHP RDF fetching code
Hi Hugh,
The code you posted seems sane to me. It is very similar to the php we use to
make sparql-queries. My only comment being that you probably want to have a
line which closes curl connection after you have used it.
something like :
You could also set a User Agent, to identify your self to the website's you are
fetching RDF from, you would do it like so :
I hope this helps,
Mischa
On 25 Jan 2010, at 18:10, Hugh Glaser wrote:
> OK, here’s some fun for you...
> (Excuse me if it has been discussed before, and just point me at it :-) )
>
>
> Having struggled through the php manual for cURL, I have come up with the
> following draft for getting an RDF document, given a URI.
>
>$ch = curl_init();
>curl_setopt($ch, CURLOPT_URL, $_REQUEST['uri']);
>curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
>curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
>curl_setopt($ch, CURLOPT_HTTPHEADER, array("Accept:
> application/rdf+xml, text/n3, text/rdf+n3, text/turtle, application/x-turtle,
> application/turtle, text/plain"));
>$data = curl_exec($ch);
>$info = curl_getinfo($ch);
>
>if ($data === FALSE || $info['http_code'] != 200) {
>
> What does anyone think?
> I’m sure there are a bunch of improvements/corrections.
>
> As a (hopefully) separate issue, the MIME types will probably generate some
> discussion, but it is the PHP I am primarily asking about at the moment.
>
> Best
> Hugh
>
_
Mischa Tuffield
ECS - http://www.ecs.soton.ac.uk/
Homepage - http://users.ecs.soton.ac.uk/mmt04r/
Identity - http://id.ecs.soton.ac.uk/person/6914
WebID - http://mmt.me.uk/foaf.rdf#mischa
Re: PHP RDF fetching code
You may find something useful in my Moriarty project: http://code.google.com/p/moriarty/ It's geared towards the Talis Platform but there is a lot of code in there that has no dependencies on the platform, e.g.: http://code.google.com/p/moriarty/source/browse/trunk/httprequest.class.php some documentation for that class here: http://code.google.com/p/moriarty/wiki/HttpRequest Ian
