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

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.
http://dbooth.org/

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 March 2011 20:21:12 GMT