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
