Re: AWWSW Telecon Tuesday 2011-03-29

On Tue, Mar 29, 2011 at 8:24 AM, David Booth <david@dbooth.org> wrote:
> 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:
>
> http://dbooth.org/2009/lifecycle/
> 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.
> ]]

"Resource identity" doesn't make any sense to me, and there are many
other aspects of that article that I find troubling, so if we refer to
it, it has to be clear that's it's not an endorsement.

Do you think the issue57 report needs a bibliography? A lot has been
written on this subject (some of it by me) and I'd rather not have to
do a literature survey.

> http://dbooth.org/2010/ambiguity/paper.html
> 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.
> ]]

The goal of the issue57 report is to talk about what people actually
do, not to propose something new.

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

It used to be there, but it's not a general definition method, so I
moved it.All of these URIs are defined in bulk to be the IRs at their
URIs. The "minter" (dereference controller) has no choice about that.
Even if you considered the versions/representations to somehow be
"defining" the ability to deploy them would not be a *general*
definition method since they could only serve to define the URI to be
the IR at that URI. Dereferenceable URIs are much closer to data: or
mailto:, and you wouldn't call those general definition methods.

> 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?

I have removed this. It was a reminder to myself that Ian had wanted
to distinguish the IR(u) vs. FV(u) cases on the basis of whether there
was an RDF response, and so this variant use case would be affected. I
think I cover this ground elsewhere now.

> 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?

It's that the method for adding metadata has to be automated (i.e. not
involve judgment or intelligence), and that includes for RDF
documents. Again, this is affected by Ian's method.

> 5. Sec 2.1: This use case seems to be intended to raise the following
> questions:
> 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
> IR('http://example/spoonwing')?
>
> I think it would be helpful to state these questions explicitly.

ok, will look at it

> 6. Sec 2.2: This use case seems to be intended to raise the following
> questions:
> 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)?

will investigate

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

the variants are all gone now

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

You mean, distinct names for the people.  will consider.  As I said on
today's call I'm not sure we still need all three use cases any more.

Thanks for the comments.
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 Tuesday, 29 March 2011 15:14:17 UTC