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/0000.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
