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

Re: AWWSW Telecon Tuesday 2011-03-29

From: David Booth <david@dbooth.org>
Date: Tue, 29 Mar 2011 08:24:03 -0400
To: Jonathan Rees <jar@creativecommons.org>
Cc: AWWSW TF <public-awwsw@w3.org>
Message-ID: <1301401443.2904.3556.camel@dbooth-laptop>
On Thu, 2011-03-24 at 15:57 -0400, Jonathan Rees wrote: 
> Agenda: continue review of http://www.w3.org/2001/tag/awwsw/issue57/latest/ .

Here are some notes that I started collecting a few days ago, but did
not finish.  They pertained to the current version at that time, so they
may not all still be relevant.  The latest version looks significantly
improved.  It looks like you've been putting a lot of good work into it.

1. One of the biggest problems I see is that this document ignores
previous work that I have done in this area that is clearly relevant,
most notably the following:

Quoting from the abstract:
Various parties are typically involved in the creation and use of a URI,
including the URI owner, an RDF statement author, and a consumer of that
RDF statement. What principles should these parties follow, to ensure
that a consistent resource identity is established and (to the extent
possible) maintained throughout that URI's lifetime? This paper proposes
a set of roles and responsibilities for establishing and determining a
URI's resource identity through its lifecycle. 

Quoting from the abstract:
This presentation sheds light on these issues by: . . . proposing a
standard operational sequence for determining the intended referent of a
URI, even in the the presence of semantic extensions.

2. Section 1.3 "A dereferenceable URI refers to the information resource
at that URI" is describing a rule (i.e., that a dereferenceable URI
refers to the IR at that URI) that is currently in use by many, so it
belongs in section 3 under "General definition methods in current use".

3. Regarding:
Variant use case: Same as above, but Bob's bibliography includes a
number of RDF documents, and his metadata includes information relevant
for making use of those RDF documents.
Do you mean, for example, that IR('http://example/spoonwing') is an RDF
document?  If so, why is this important to mention as a variation of the
original use case?

4. Regarding:
Variant use case: Same as above, but instead of being a person, Bob is a
tool that is charged with updating all the documents on a Web site with
license metadata. 
Can you be more specific about the issue that you are trying to bring
out?  Is it the fact that an automated tool is doing it rather than a
human?  Or is there some special issue that license metadata raises?

5. Sec 2.1: This use case seems to be intended to raise the following
a. What phrase should Bob use to refer to the report?
b. How should Carol know to dereference http://example/spoonwing ?
c. How should Carol know that Bob's phrase is intended to refer to

I think it would be helpful to state these questions explicitly.

6. Sec 2.2: This use case seems to be intended to raise the following
a. What phrase should Alice mint, to refer to Fred (the mynah)?
b. Where/how should Alice publish the definition of her phrase?
c. How should Carol know how to find Alice's definition?
d. How should Carol know to interpret Alice's definition as a definition
of Alice's phrase (as opposed to, say, a movie review)?

7. It would be helpful to uniquely number each use case variant, so that
we can refer to them more easily.

8. Sec 2.2: The variations of this use case sound very similar to use
case 2.1, where Bob's bibliography is in a web page and Alice's report
is either accessible or not.

9. Are the characters (Alice, Bob, Carol) supposed to be the same people
across use cases?  If so, this could be clearer if the use cases were
more coordinated.  For example, Bob's bibliography in use case 2.1 could
be published at http://example/biblio, and that could the same "Bob's
document" that use case 2.2 mentions.  If not, it would be clearer to
use distinct names.

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 29 March 2011 12:24:36 UTC

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