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

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

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 15 Mar 2011 15:13:13 -0400
Message-ID: <AANLkTimXM2mrdurs1JzE2Kni8HPOHfBpvj9w59DoXGLj@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: AWWSW TF <public-awwsw@w3.org>
[cutting out chunks of the replied-to message indiscriminately for the
sake of brevity]

On Tue, Mar 15, 2011 at 2:06 PM, David Booth <david@dbooth.org> wrote:
>
> Agreed.  But since RDF *is* the motivating use case, I think it would
> helpful to write this as a Webarch issue expressed in RDF.
>
Happy to look at suggestions.

>> The "URI owner" theory is an unnecessary distraction.
>
> I disagree.  I don't see why you are referring to it as a "theory" any
> more than "Alice" is a theory.

I don't say that either is more of a theory than the other; but the
Alice theory is one I understand. According to your "lifecycle" note
your "URI owner" is the same as the one in AWWW. I don't see any
reason to refer to that. It's enough to talk about the entity that is
able to control HTTP (or other protocol) responses for the URI.
Claiming there is some kind of "ownership" is at least unnecessary -
forget about the question of whether it's true or not. I just don't
want to get into that question.

> They are both terms for the roles in the
> scenarios.  I think it is helpful to use established terms, but I don't
> think it is worth arguing this point further, so if you prefer to stick
> with Alice, Bob and Carol at this point, I'm fine with that.
>
> When we start writing generalizations or (prose) rules though, I think
> we will need to use general terms like "URI owner", "RDF statement
> author" and "RDF consumer".

Hoping to avoid defining new terms, but we'll see how it goes. If
something like this is needed we can do it.

>>
>> > 3. Sec 2.2 this sentence doesn't make sense to me, because AFAIK,
>> > Alice's account does not describe a document, it describes a mynah: "The
>> > referent is not the account that Alice publishes, it is the document
>> > that Alice's account describes."
>>
>> The sentence is correct as written. I've changed "document" to
>> "information resource".
>
> I'm still baffled by that sentence.  The sentence refers to "the
> *document* that Alice's account describes".  But the definition of
> "account" is: "A document or document part that provides information
> about the meaning of a URI or other phrase."  And the description of
> scenario 2.2 says: "Alice publishes a document that would lead a reader
> to realize that the phrase refers to Fred".  So Alice's published
> document seems to fit the definition of "account", and that account says
> that the phrase "refers to Fred", i.e., Alice's account describes
> *Fred*.  I am assuming that Fred is not a document.  Therefore, the
> sentence in the second variant that mentions "the document that Alice's
> account describes" does not make sense to me.
>
> Perhaps the confusion is that the second "Variant" does not make clear
> exactly which parts of the original scenario are being kept and which
> are being changed, nor which "referent" is meant.

I can change "Variant:" to "Variant use case: Same as above except that..." ?

That paragraph is pretty bletcherous. I'll see if I can rewrite this
to maybe improve things... something like "The account that Alice
writes then explains that the phrase is to refer to that information
resource."

although maybe there's a way to write it that says in-your-face that
there are two IRs and one is about the other.  This is important
because it's a potential CC REL lossage scenario, where metadata is
applied to the wrong IR.

> I think this could be clarified a lot by giving specific RDF and
> document examples.

Probably so. I'd like to make sure the document has the right outline
and says what it needs to say before diving into the next level of
expansion.

>> > 4. Regarding section 3.5:
>> > [[
>> > 3.5 Cite your sources
>> > Whenever using a URI to refer to something, provide a link to the
>> > document that carries an account of the URI's meaning. This is the
>> > approach taken by OWL (owl:imports). The rdfs:definedBy property could
>> > also be used for this purpose.
>> >
>> > Both of these properties beg the question in that they do not say how to
>> > figure out what the target URI refers to.
>> > ]]
>> >
>> > Do you mean that they beg question because they do not specify what to
>> > do after one has obtained the document that carries an account of the
>> > URI's meaning?   Or do you mean that they beg the question because they
>> > do not say how to determine the document's URI, for example in a case
>> > like this:
>> >
>> >  <x> rdfs:definedBy _:aBnode .
>>
>>           Both of these properties beg the question in that
>>         they do not say how to figure out what the URI that is the
>>         target of owl:imports or rdfs:definedBy refers to. If the
>>         meaning of <emph>that</emph> URI were given by citing a source,
>>         there would be infinite regress.
>
> I'm still not sure what you mean.  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 <...>.

Best
Jonathan
Received on Tuesday, 15 March 2011 19:13:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 March 2011 19:13:48 GMT