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

Re: information resource paradox

From: Jonathan Rees <jar@creativecommons.org>
Date: Fri, 19 Mar 2010 13:02:14 -0400
Message-ID: <760bcb2a1003191002m53075976p1772395d07d5b447@mail.gmail.com>
To: Dan Connolly <connolly@w3.org>
Cc: AWWSW TF <public-awwsw@w3.org>
I don't understand this at all, sorry. This has nothing to do with URIs,
it's about what they name.
Let me try again, retracting the part about journal article
transparency sounding nonsensical.
Are journal articles 'transparent' according to the definition I gave?
We could say 'no' and add that to our growing theory of information resources.
I.e. if a resource R has the property that it is transparent, then R
is not a journal article
(or at least is not the same journal article as the similar R' that is
transparent).

Or we can say 'unspecified' (i.e. 'yes' in some models and 'no' in others), in
which case no careful server would yield the abstract only. This has
pretty much the same outcome as 'yes':
I cannot ask the DOI foundation for a statement that its URIs name
the intended articles, I will have to (a) ask it to mint new URIs that do,
(b) mint my own URIs for things named by DOIs, or (c) advise people
who want to express metadata to name the articles
using blank nodes (the practice advocated by Bibo, and what one has
to do now), or (d) advise people to discount any RDF/HTTP connection.

I guess it's based on the undesirability of (a)-(d) that we say journal articles
are not 'transparent'. OK. So how would I ever prove
that a particular article does not talk about unicorns, if representations
are allowed to be lossy? This is something that's easy if you
have the article in front of you, but apparently hard on the web.
Maybe some out of band mechanism, but
what would that be like?

On Fri, Mar 19, 2010 at 12:09 PM, Dan Connolly <connolly@w3.org> wrote:
> On Fri, 2010-03-19 at 10:17 -0400, Jonathan Rees wrote:
>> I'm mulling over the comparison of the information carried by
>> a representation to the information carried by a resource.
>>
>> Let's suppose that content entities (representations) and information
>> resources can both carry information, perhaps many "informations"
>> each.  Suppose the a resource R "has information" content entity E (R
>> "has information" E) at time t, let I(R) be the information carried by
>> R, and I(E) be the information carried by E.  We might have
>>
>>    I(E) = I(R)                (e.g. data: URI resource, 'fixed resource')
>>    I(E) a subset of I(R)      (lossy encoding)
>>    I(E) a superset of I(R)    (advertising? marginalia?)
>>    I(E) disjoint from I(R)
>>    I(E) overlaps I(R)
>>
>> and so on.  Let's define subclasses of "information resource"
>> according to which of these holds.  For example, let's say that an IR
>> R is "transparent" if I(E) = I(R) whenever E "corresponds to" R.
>>
>> So let's take our journal article example, where you do a GET of some
>> URI U and you only get an abstract of an article (you don't get all of
>> its information).  Is this consistent with U naming the journal article
>> (consisting of more than the abstract)?  We might phrase the question
>> this way: are journal articles transparent?
>>
>> When you put it this way the question sounds nonsensical - why would
>> you consider applying a property like "transparent" to a journal
>> article? I.e. journal articles are not information resources.  Where did
>> I go wrong?
>
> When you made "transparent" a property of R rather than the
> relationship between R and E. "Is article X transparent?"
> is sort of like "is this grain of sand named by a URI?"
> I can always mint a URI for that grain of sand, making
> the answer 'yes'. And I can always force R to be opaque
> (i.e. non-transparent) by minting a new URI for it
> and serving less than the full information of R there...
> i.e. by making a new E where I(E) != I(R).
>
>
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>
Received on Friday, 19 March 2010 17:02:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 19 March 2010 17:02:48 GMT