Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

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" :)

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].

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.

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.

Hope this helps rather than muddies things further.

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.

Received on Friday, 5 November 2010 12:36:02 UTC