wdrs Error (was Re: isDefinedBy and isDescribedBy, Tale of two missing predicates)

Adding Public POWDER list. Main thread is on 
http://lists.w3.org/Archives/Public/public-lod/2010Nov/

It's clear to me that there is an error in wdrs:describedby. And since I 
am one of the originators of it, I'd like to do something about it.

What I wrote, and meant, in the text at [1] was:
"... [wdrs:describedby] is a generic relationship type that does not of 
itself imply that the link points to a POWDER document — that is done by 
the specific Media type. The formal definition of describedby is given 
in Appendix D."

Appendix D is where it says:

"The relationship A 'describedby' B asserts that resource B provides a 
description of resource A. There are no constraints on the format or 
representation of either A or B, neither are there any further 
constraints on either resource."

However, later in the same document, at [2] it says

We define the RDF property wdrs:describedby with a domain of 
rdf:Resource and a range of wdrs:Document. This is the class of POWDER 
documents and is a sub class of owl:Ontology. The meaning of 
wdrs:describedby is identical to the describedby relationship type 
defined above so that:

http://www.w3.org/2007/05/powder-s#describedby

and

http://www.iana.org/assignments/relation/describedby

So we have a mis-match Either wdrs:describedby has a range of 
wdrs:Document (bad) or it has the same semantics as the @rel type 
describedby which implies no range at all (good).

I'd like to correct this error!! wdrs:describedby is intended to be used 
exactly as is being discussed here - a generic link between A and B such 
that B describes A with no constraints at all on either.

Since I can (readily) point to an error in the description of what I 
hope is a basically sound design, I'm going to see if I can:

a) add an erratum to the POWDER Rec
b) edit the wdrs namespace documentation

That should I hope, make wdrs:describedby fully usable??

(Looks up W3C process document on getting this done...)

Phil

[1] http://www.w3.org/TR/powder-dr/#assoc-linking
[2] http://www.w3.org/TR/powder-dr/#semlink

On 05/11/2010 12:35, 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" :)
>
> 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.
>
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>

-- 


Phil Archer
Talis Platform
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org


Talis Systems Ltd,
Knights Court
Solihull Parkway
Birmingham Business Park
B37 7YB
United Kingdom

Tel: +44 (0)870 400 5000

Received on Friday, 5 November 2010 13:05:03 UTC