Jiří Procházka wrote:
On 11/10/2010 11:44 AM, Nathan wrote:
Hi Jiří,
Jiří Procházka wrote:
Hi,
having read all of the past week and still ongoing discussion about HTTP
status codes, URIs and most importantly their meaning from Linked Data
perspective, I want share my thoughts on this topic.
I don't mean to downplay anyone's work but I think the role of URI and
HTTP specifications (especially semantics) in Linked Data is
overemphasized, which unnecessarily complicates things.
The URI is what makes Linked Data, Linked Data, it's the only hook to
the real world, and via the domain name system + domain registration
process gives us a hook on accountability, which is critically
important.
I am by no means giving up these utilities by what I suggest.
"#bar, as described by <http://example.com/foo>" resolves in
two ways:
(1) <http://example.com/foo> as a name for the literal description/graph
(2) <http://example.com/foo> as a way of saying "the author of the
description available at <http://example.com/foo>, stated X, and was
responsible as delegated by the owners of example.com", where X is (1)
and provable by the HTTP messages and logs. A status code of 200 vs 303
to some other domain or URI vs 4xx or 5xx plays a big part in that chain
of accountability / validity / trust.
I don't think Linked Data consumers should *have to* care about what
status codes HTTP request returns - it shouldn't be part of the core
Linked Data semantics. Of course it can be beneficial for clients to
listen to them to get more information, but treating HTTP library as a
simple function should be allowed (either it returns data or not).
Whether someone 303s (nice verb) to a different domain, it obviously
means he trusts it to maintain the description of his URI.
snap, I don't think they should either, I also don't think they should
have to constantly ask "is this a document or a toucan?" - it could all
be so much easier.
ps: 303 doesn't day "you'll find it here!", it says "maybe you try here
instead?"
So lets stick with this. Lets just treat URIs as RDF does - as simple
names. When we dereference an URI we get back some useful data and
that's it.
So, that'll be like mailto: or pop: or tel: then..
I don't follow here. I don't know of any standardized ways of getting
structured data out of such URIs.
That's the point, RDF treats all URIs the same, you're saying we should
treat URIs as RDF does, as nothing more than a logical hook - doesn't do
us much good practically when we want to dereference and get back some
useful data.
If we want to express, the data fetched are in fact a
document, we use the wdrs:isDefinedBy property. The data fetched are
just a data and any info about it should be contain in it.
Expressing that the data fetched is infact a document, is indeed
optional, but any response is always a message, a description, a
/literal/ thing, you can't pretend it doesn't exist, it does - to say a
description is anything other than that is like me saying you're an
apple and insisting everybody believe me. Literals are self identifying,
self naming, things.
I don't get what you mean here either. Are you talking about RDF
semantics here or general ontological philosophy? If you are talking
about RDF, then be aware that literals can have names - URIs assigned to
literals. If talking about the latter, then I don't get you at all.
I am advocating making Linked Data as simple as possible, avoiding
abstract ontological definitions (in which I count the notion of
literal). The fact that what you say is incomprehensible to me further
strengthens me in my opinion.
Much, much simpler - "this is an email", "this is a html document",
"this is an rdf document", "this is a book" - why are people even trying
to assert that one of those statements is false?
You have for example foaf:Agent which you dereference and get back the
data amended with:
foaf:Agent wdrs:isDefinedBy [ wdsr:location
"http://xmlns.com/foaf/0.1/Agent"; ] .
If the data already contains:
foaf:Agent wdrs:isDefinedBy foaf: .
foaf: wdrs:location "http://xmlns.com/foaf/0.1/"; .
great, we get better info.
/foaf#Agent = "Agent, as described by /foaf" seems much simpler to me.
and nobody is going to say "Agent sameas Document"
..
