Re: Issue-57

Jonathan Rees <jar@creativecommons.org> wrote:
>2011/6/24 Tore Eriksson <tore.eriksson@po.rd.taisho.co.jp>:
>> Jonathan Rees wrote:
>>> Suppose the following holds:
>>>
>>>     <http://example/z> xhv:license <http://example/l1>.
>>>
>>> Suppose that I do a GET of 'http://example/z' and retrieve a "representation" R.
>>>
>>> My interlocutor wants me to be able to infer that
>>>
>>>     R xhv:license <http://example/l1>.
>>>
>>> so that my remix tool knows what license terms apply when using the bits in R.
>>
>> Sure, let's say this holds. However, when downloading R to a local file,
>> creating a new resource <file:///tmp/z>, the licensing information might
>> be lost. Wouldn't it be safer to use a license embedded in R (i.e. in HTML
>> META tags)?

> (Advising against using RDF is funny to hear from someone who puts RDF
> in their email signature.)

Please don't put words in my mouth. Maybe I wan't explicit enough, but
I though that RDF would be used is the default assumption on this
mailing list. A concrete example:

<HEAD>
  <META name="dc.author" content="Tore Eriksson"/>
  <LINK rel="xhv.license" src="http://example/l1"/>
<HEAD>

Does this seem familiar? I think that the syntax could be improved upon
though...

> These are all good questions, so thanks for listening.

> You're switching problems on me. What was on the table was how to use
> the amended httpRange-14 200 rule in concretely helpful communication.
> Now you are asking about the reliability of the communication channel.
> So even if you are right - and you are - I don't think this bears on
> the question. The meaning of metadata expressed as statements
> involving a URI does not change depending on what the communication
> channel is, because URIs are *uniform* resource identifiers.

I agree that if httpRange-14 was followed rigorously by all parties on
the web, your solution is sound. I'm sorry for switching the problem
here, but I am concerned about the practical applicability of
httpRange-14. If you can't trust the premises stated in your theory, the
solution - theoretically sound as it might be - is bad engineering.
Earlier I do believe you said that your proposal was more concered about
engineering that philosophy?

The neat thing of RDF is that it is independent of the communications
channel, sure. But since you are using the channel to infer what the
meta-data applies to, claiming that the channel is irrelevant in this
case sounds like a leap of faith.

> Not all metadata can be embedded, either.

No, but if you choose a format with embedded metadata, you are safe.
Avoid text/raw if you want machine-readable metadata.

>> Jonathan also made this statement in an earlier mail:
>>> If U is a dereferenceable
>>> absolute URI, and M(<U>) for some metadata M, and a retrieval of U
>>> yields a representation Z, then M(Z). E.g. if an information resource
>>> has dc:title "Little mouse", then its associated representations do,
>>> too. Conversely, if M(Z) consistently for Z retrieved from U, then
>>> M(<U>).
>>
>> I do have a problem with the last part of this paragraph where the
>> applicability of metadata is reversed. How are you supposed to determine
>> whether M(Z) is consistent? Is this consistency at a specific point in
>> time? How do I enumerate all possible representations of <U>?

> OK, maybe not the best choice of words. Here is my reasoning.
> Operationally M(<U>) says that if  GET(U) yields 200 Z, then M(Z). The
> individual writing M(<U>) may not know exactly when the GET will be
> done or by whom (or with what request details), so if M(<U>) is going
> to be true then M(Z) may have to be true of a variety of Zs, or at
> worst all future Zs. The easiest way to express this in FOL is using
> universal quantification, and on a whim I colloquialized this to
> "consistently", for which I apologize.

No problem. Even changing the wording, I still can't imagine any
practical way of deciding whether M(Z) is true for all (future) Zs. You
have some examples below, but they are all ways to decide post factum.

>> I assume that httpRange-14 tries to avoid this consistency check through
>> enforcing these rules globally on the web. Doesn't read like sound
>> engineering and also seems like a hard task to me...
> 
> I'm not sure where enforcement comes into this. We're talking about
> establishing prior agreements so that we can communicate with each
> other. It's always good when statements are checkable, and these
> statements are, but that doesn't mean they can be or need to be
> checked all the time.

Enforcing is a word loaded with negative connotations. Sorry for using
it. However, the essence of my comment stands. Establishing prior
agreement is a social problem that is very difficult on the scale of the
WWW. How you can determine that agreement is reached or not? Perhaps a
little icon on the top page: "This site is compatible with httpRange-14"... My
concern with httpRange-14 has always been that it claims to be
applicable to the entire web - regardless of the parts involved have
agreed or not. That is why I chose the word "enforcing".

<Removed some examples of how to measure trust on the web>

> Again, I am not saying that the httpRange-14 amended 200 rule is the
> right tool for all jobs. I just want to clarify what it is, because
> the first attack on it is always that it's nonsense or useless. That
> doesn't make sense given how widely it's relied on. It may be "of
> limited utility" (Larry's phrase) but I want to get past the
> foolishness claim and confusion over how it works so that we can turn
> the discussion to what needs to be done.

I don't think it is useless or nonsene. I am concerned about how it will
work in practice though. Looking back at my comments, I noticed that
my proposal is perhaps not relevant for Issue-57, but would be more
fitting in the context of Issue-63. Beeing a www-tag lurker, I have an
insufficient grasp of the organization, sorry about that. I'll try to
make a comment in some thread about Issue-63 instead.

Tore

_______________________________________________________________
Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]

Received on Monday, 27 June 2011 05:36:01 UTC