On 11/5/10 8:35 AM, Dave Reynolds wrote:
On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:
On 11/5/10 4:51 AM, Dave Reynolds wrote:
On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:
When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .
Ian mentioned this predicate in his post.
Looking at [1] the range of wdrs:describeBy is given as "class of POWDER
documents and is a sub class of owl:Ontology" which seems to make it
unsuitable as a general predicate for the purpose being discussed here.
Dave
[1] http://www.w3.org/TR/powder-dr/#semlink
Dave,
I am not saying or implying that Ian didn't say this in his post.
These issues have been raised many times in the past by others
(including myself), repeatedly.
Indeed.
I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.
Here's the key difference though, yesterday was the first time that
these suggestions were presented as somehow being mutually exclusive
relative to use of 303 redirection.
I don't want to start another session with Ian, but here is my
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303
redirection (mechanism for resolve. At the end of the day there are
going to be resolvable object/entity identifiers either side of these
predicates, if we are seeking to keep the resulting Linked Data mesh
intact etc..
"dropping 303" simply didn't need to be the focal point of the
conversation. It has nothing to do with why people have been
publishing "old school" RDF resources that fail to link the container
(rdf doc) with its structured content (triples).
I hope I've made my point clear :-)
Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a "third way" :)
Dave,
I have no issue with options.
My only gripe is with mutual exclusion. "..dropping 303..." didn't come
across as adding an option to the mix. Ditto positioning 303 as a
mandate, which it's never really been.
I have some sympathy with this. The situation I've faced several times
of late is roughly this:
Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:
(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].
(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].
(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.
(d) Ergo we must use 303.
(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier technology [4].
Yes, which is why we've opted to move the conversation to the conceptual
realm so that platforms take responsibility for complex Linked Data
deployment while RDFa handles the "magic document" scenario i.e. use
HTML+RDFa to create data descriptions, inject into the Web via a myriad
routes i.e., no Apache and .htaccess tax etc..
What Facebook, Microsoft, and Google take the position that
high-semantic-fidelity EAV graphs are best handled by organizations that
are capable of transforming their low-semantic-fidelity EAV graphs. Of
course, they hold this position today because the opportunity costs to
their respective organizations aren't palpable just yet. That's going to
change, and change quick if Linked Data platforms just deliver Linked
Data without the distraction element of RDF.
Google's adoption of RDFa is a nice example of what I've outlined above.
Google is no stranger to RDF, they just haven't been able to get past
its legacy problems. Then along comes RDFa + GoodRelations, totally
about "opportunity cost palpability" and 12 months later, they
officially come out, because in reality they had no choice. It now makes
sense re. palpable impact on short and long term business model. Sames
has also happened at Yahoo!, and in a sense Facebook.
Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.
Sorta. Ultimately, we are going to be stuck with a variety of
approaches. Platforms should solve these problems, users should just
exploit the virtues of Linked Data.
I take this discussion to be exploring the question:
Would a third alternative be possible? People can continue to
use # URIs and to use slash URIs with 303s but would it be that
bad if we allowed people to use slash URIs for Things, without
the redirect?
The talk of "dropping" and "deprecating" I've heard has been concerned
with the TAG finding on http-range-14 (which does ban use of slash URIs
for Things and thus is a genuine, standards-body-backed, objection to
such a third way) rather than to the use of 303s by those happy to do
so.
I don't think this community has operated on the basis of such mandates.
As Michael H., said in an earlier post, we just do stuff over here. We
don't wait for anyone since shippers are the ones that win, ultimately :-)
Linked Data is what it is because this community just does it!
Ian:
Rather than start a meme about dropping 303, we could have just taken
the "do it" route, as per usual. I can assure you, I wouldn't be
opposing a new option. I do believe in high-fidelity self-describing
data, always have, always will.
Hope this helps rather than muddies things further.
Thanks!
Very clear.
Kingsley
Cheers,
Dave
[0] I'm going to trying use the terminology of Thing and Document here
rather than NIR and IR - inspired by Tim's historical note (thanks to
Andy Seaborne for point this out):
http://lists.w3.org/Archives/Public/www-tag/2009Aug/0000.html
[1] Note that some people conclude something more like "this is a
philosophical distinction that I don't care about, I'll go hang with a
different crowd". This not the branch we're concerned with here.
[2] See for example the reasons cited in Tim's historical summary note.
[3] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
[4] Note that I'm in no way suggesting that 303 redirects is the only or
the biggest barrier to adoption. It just has a way of triggering
conversations with users and early adopters that tend to be
counterproductive.
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
