- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 05 Nov 2010 11:27:45 -0400
- To: Phil Archer <phil.archer@talis.com>
- CC: "public-lod@w3.org" <public-lod@w3.org>, Public POWDER <public-powderwg@w3.org>, Dave Reynolds <dave.e.reynolds@gmail.com>
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