W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2011

Re: please review issue-57 document draft before Tuesday telcon

From: David Booth <david@dbooth.org>
Date: Tue, 15 Mar 2011 16:20:41 -0400
To: Jonathan Rees <jar@creativecommons.org>
Cc: AWWSW TF <public-awwsw@w3.org>
Message-ID: <1300220441.1954.39429.camel@dbooth-laptop>
On Tue, 2011-03-15 at 15:13 -0400, Jonathan Rees wrote:
> On Tue, Mar 15, 2011 at 2:06 PM, David Booth <david@dbooth.org> wrote:
> [ . . . ]
> > Suppose the community adopted the
> > convention that for any statement of the form
> >
> >  <u1> rdfs:definedBy <u2> .
> >
> > the document obtained by an HTTP GET of u2 should be taken as an account
> > of <u1>'s meaning.  In this case, the meaning of <u1> does not depend on
> > the meaning of <u2>, so where is the infinite regress?
> The community could do that, but it could not ignore what <u2> means
> without stepping on RDF and OWL semantics, as this practice would not
> be referentially transparent. Interpretations have to say what u2 maps
> to.  It would be much more robust to have similar relations where the
> right-hand side was written as a literal, not a <...>.

Well, an interpretation *could* map u2 to u2.

But I certainly agree that a solution retaining referential transparency
would be much better.  I agree that the URI should be written as a

However, I have sometimes pondered proposing a standard set of
assertions that an RDF parser could optionally make available.  And one
of these could be, for example:

  <u> log:uri "u" .

for any URI that is used as a <u> term in the document.  Other standard
assertions could include things like the URI u from which the document
was fetched:

  <> :fetchedFrom "u" .

These are the kinds of things that toolkits often keep internally.  This
would be another way that the problem could be approached.

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 15 March 2011 20:21:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:09 UTC