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

Re: AWWSW vs. httpRange-14

From: David Booth <david@dbooth.org>
Date: Mon, 14 Feb 2011 11:04:45 -0500
To: Jonathan Rees <jar@creativecommons.org>
Cc: AWWSW TF <public-awwsw@w3.org>
Message-ID: <1297699485.2043.15028.camel@dbooth-laptop>
On Fri, 2011-02-11 at 15:06 -0500, Jonathan Rees wrote:
> On Fri, Feb 11, 2011 at 2:07 PM, David Booth <david@dbooth.org> wrote:
> > Hi Jonathan,
> >
> > I want to see if I am properly understanding what you mean, so I'll
> > reflect back a bit for you to verify or correct.
> >
> > On Fri, 2011-02-11 at 10:38 -0500, Jonathan Rees wrote:
> >> In my current view there are two issues:
> >>
> >> 1. What notation do we use to write a reference to an 'information
> resource'?
> >
> > Do you mean an *explicit* reference, such as <http://example/#foo> in
> > the following RDF statement:
> >
> >  <http://example/#foo> a :InformationResource .
> >
> > Or do you mean an *implicit* reference, by virtue of the fact that an
> > HTTP GET on that URI yielded a 200 status?
> >
> >  <http://example/bar> :createdOn "2009-12-31"^^xsd:date .
> >
> > where a GET on http://example/bar yields a 200 response with a document.
> >
> > Or do you mean both?  Or something else?
> 
> What I mean is, that currently when someone wants to say that a
> document has a title or a license, they use the document's URI (the
> URI from which they GET the document or its "representation") as the
> subject of an RDF statement.
> 
> I have interpreted the httpRange-14 resolution as reflecting a
> suggestion that people use these URIs in this way (and not in some
> other way). This has been widely assumed, e.g. FOAF and CC REL.
> 
> This practice has been questioned, so we have to consider other
> options in order to do an honest appraisal of the alternatives.
> 
> Webarch, RFCs 3986 and 2616, and the httpRange-14 resolution seem to
> be fairly explicit, but by your definition these references are
> implicit.

Yes, indeed those specs are quite explicit.  I merely meant implicit
from an RDF perspective.  Sorry for the confusion.

> 
> >> 2. What does such a reference mean, such that it can be used to good
> >> effect in various kinds of statements (eg. Dublin Core, FOAF, CC REL)?
> >
> > Do mean: "What other RDF assertions should be used if a URI is used in
> > an RDF statement?"?
> 
> By "mean" here I mean according to current and/or future community
> consensus. Qualifying RDF statements isn't what everyone does now, and
> it may or may not be part of a future consensus; I don't know how it's
> going to turn out.

It sounds like an example you have in mind is to consider the meaning of
an RDF statement like:

  <http://example/doc> cc:license
         <http://creativecommons.org/licenses/by-nc/3.0/> .

where and HTTP GET on http://example/doc returns a 200 status with a
body that is a copy of a creative work that is intended to be licensed,
and terms of the license are published at
http://creativecommons.org/licenses/by-nc/3.0/ .

By asking "What does such a reference mean", are you asking something
like this: "Assuming a copy of a creative work is returned from an HTTP
GET of http://example/doc, and someone uses that copy in a way that
violates the terms of the license that is available at
http://creativecommons.org/licenses/by-nc/3.0/ , should that person be
liable?"

>From an RDF perspective, it seems to me that there are two implicit
leaps (though they are explicit in other specs):

 - that the term <http://example/doc> refers to the particular creative
work whose copy is returned from an HTTP GET of http://example/doc ; and

 - that the term <http://creativecommons.org/licenses/by-nc/3.0/> refers
to the particular license whose copy is returned from an HTTP GET of
http://creativecommons.org/licenses/by-nc/3.0/ .

>From an RDF perspective, those seem to be the missing (or implicit)
links that would enable the conclusion that someone violating the
license terms would be liable.  Is this what you're getting at?

> 
> > If so, this sounds right up the ally of "Statement author responsibility
> > 3" and "Consumer responsibility 5" in
> > http://dbooth.org/2009/lifecycle/
> 
> An agreement with these rules would preclude any referential use of
> these URIs, since nobody would know the meaning of the 'core
> assertions' they would be agreeing to. 

Well, for non-InformationResources the 'core assertions' are merely the
assertions that you get by follow-your-nose dereference of the URI.  But
it sounds like you referring to the InformationResource case, where the
URI (such as http://example/doc ) returns a plain HTML document with 200
status.  (The RDFa case is even more complex to figure out, as it
combines both HTML and RDF, so I'm hoping that we can figure this out
first for the plain HTML case and then address the RDFa case.)  

The community has not standardized what the 'core assertions' should be
in the plain HTML InformationResource case, though I proposed some (for
discussion purposes) in the N3 rules that I drafted a while back:
http://lists.w3.org/Archives/Public/public-awwsw/2008Mar/0016.html
http://lists.w3.org/Archives/Public/public-awwsw/2008Mar/att-0016/test6.n3.txt

Those were a meager step, but I think they are along the lines of what
is needed to bridge gap between the RDF term <http://example/doc> and
the creative work that it is intended to identify (by virtue of copies
of that creative work being returned when you do an HTTP GET on
http://example/doc ).


> Or, if there were no such
> assertions, then nobody would use these URIs since statements using
> them wouldn't convey anything at all. Adoption would say that CC would
> have to retool since none of its license assertions have any meaning.
> So it sounds like you're in the don't-be-unclear camp with Alan,
> Harry, and Larry. 

I don't think I understand clearly enough what you mean by the
"don't-be-unclear camp" to either agree or disagree.

> Am I the only one here trying to explain and
> maintain the value of the current investment in metadata?

I agree with trying to explain and maintain the value of the current
investment in metadata.

> 
> I would think one way to go would be to explain why these metadata
> assertions work socially, and under what limitations, and then try to
> build consensus around whatever it is we learn. 

That sounds like a good idea to me.  If we can just capture an
explanation of why they currently work socially, I think it will be a
big step forward.

David


> If not then we'll have
> to retract every bit of advice ever given about writing metadata in
> RDF.
> 
> Jonathan
> 
> >> Clearly these interact, but pretend for a minute that they don't.
> >>
> >> #1 is related to Harry's complaint that # and 303 are too hard; he
> >> doesn't like it that we use dereferenceable URIs as references to
> >> information resources, because he thinks those URIs can be put to
> >> better use.  (IIUC.)
> >>
> >> #2 was the complaint that created AWWSW: If I *do* use a term (URI or
> >> anything else) referring to an "information resource" in a proposition
> >> (metadata), what do I mean, even if the webarch is assumed; and might
> >> we either record or set expectations for their use.
> >>
> >> The TAG was convinced this week that an issue needs to be opened for
> >> #1, and I will be moving that forward.
> >>
> >> It was already convinced #2 was a question, and that's how AWWSW was
> >> established.
> >>
> >> I think that Harry and Alan (and Larry Masinter) are saying something
> >> similar, which is: If it matters whether your meaning is clear, then
> >> IR references do not stand on their own, as they are inherently
> >> unclear.  To obtain interoperability, you have to stop talking about
> >> 'the information resource at a URI' entirely, regardless of how you
> >> refer to them. IR is a lost cause.
> >>
> >> This cuts both ways. If you want to be clear that you mean to use an
> >> http: URI to refer to something described in the accessed document,
> >> you need to write some statements to that effect.
> >
> > Such as by owl:imports?
> >
> >> (This is clearly
> >> even harder than using # or 303.) If you want to be clear that you
> >> want it to mean the document, you also need to say something.  (So
> >> Creative Commons and FOAF would need to retool.)
> >>
> >> In this pessimistic view it's only if you don't care about being clear
> >> that http: URIs serve as references.
> >>
> >> In either case RDF graph merging (i.e. interoperability) is defeated
> >> since to merge a graph using a URI in one way with a graph using a URI
> >> in the other way either one or the other graph would need
> >> alpha-conversion, a rather nasty procedure.
> >
> > Pointer to alpha-conversion please?
> >
> > thanks,
> > David
> >
> >>
> >> (There is a somewhat different story in the OWL context but I think
> >> much of this still applies.)
> >>
> >> The way to get interoperability is to stop using http: URIs (or at
> >> least hashless ones) for reference entirely. In this case we would
> >> still need a 'web semantics' to provide a vocabulary for talking about
> >> the documents that we find on the web, and perhaps relating them to
> >> the things they describe.  So the AWWSW project is in a sense
> >> independent of the notational question of what RDF terms we use to
> >> refer to IRs or documents.
> >>
> >> I hope it's clear I haven't completely given up on this as Harry and
> >> Alan have. However I do consider despair an option.
> >>
> >> By the way I had forgotten about TAG Issue 39
> >> http://www.w3.org/2001/tag/group/track/issues/39 , which seems to be
> >> forgotten and forlorn. I'm not sure if it would be appropriate to
> >> track #1 and/or #2 under this issue; I sort of disagree with the
> >> formulation of the problem and I'm not sure AWWSW is a part of this.
> >> I'd be interested in hearing others' thoughts on the relation of our
> >> work to issue 39.
> >>
> >> Jonathan
> >>
> >>
> >>
> >
> >
> >
> 
> 

-- 
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 Monday, 14 February 2011 16:05:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 February 2011 16:05:14 GMT