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

On 11/5/10 8:58 AM, Phil Archer wrote:
> 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).
>

Phil,

We've always implemented in  "good faith" :-)

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

The specs do need to be fixed, as there is a tsunami heading POWDER's way.
>
> 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??

Great!


Kingsley
>
> (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.
>>
>


-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 5 November 2010 15:28:19 UTC