Re: nathans definition of an IR

While I find aspects of the 'vitalist' view (Nathan) and the 'cynical'
view (David) appealing I think the presentations both suffer from the
flaw of using objective language (ontology and epistemology) for what
is essentially an engineering question (what we should write or
deduce). Saying "an information resource is..." without either logical
precedent ("according to ...") or logical consequent ("if something is
..., then ... follows") just invites confusion and futility. Meaning
comes from unlocking useful inference, not from ontological assertion.

That said I do recognize the value of 'vitalist' or ontological
approaches - done right they tend to be both consequential and
relatively decisive i.e. they don't leave as much open to
interpretation (and therefore promote understanding and
interoperability). This is the metatheory behind the OBO Foundry. So I
don't mind attempts to discover theories that might predict why 2116
and REST are written the way they are.

And I recognize the value in denying it as well - starting with a
deployed system and then attempting to say what existing URIs "refer
to", without an objective definition of "refer to", is presumptuous,
if not doomed to failure. I don't really understand the consequence of
David's view but it acts as a useful counteranchor.

My attempt to bridge the two views - Nathan's 'vitalist' one and
David's 'cynical' one - is the 'requirements' note (and its
predecessors "predictive metadata" and "exchange invariants") - call
it maybe the 'pragmatic' view. I confess I am feeling smug about this
approach as it finally explains for me how TimBL's view, mushy as it
is, has significant and practical engineering consequences. It seemed
to me all along that something like this ought to hold, given the
constancy with which TimBL has held to it, but it hasn't been until
now that I've figured out how to turn it into a system with teeth.
http://www.w3.org/2001/tag/awwsw/ir-axioms/

(On the other hand the axioms may be so strong that they might require
an "opt in" to avoid confusions where someone is held to them without
their consent. I'm not sure - I need to try to synthesize such a
scenario.)

Right now I don't mind any 'vitalist' or 'cynical' explanation of IRs,
so long as the axioms are satisfied. The way to get us engaged with
one another's explanations might be to go a step deeper in comparing
them.

Random comments:

- I think some confusion arises from a failure to distinguish "well
behaved IRs" - those that we write metadata about - from "badly
behaved one" - those that are only supposed to be IRs because the
httpRange-14 resolution tells us they are.  I see little harm in
dropping the 200-implies-IR rule for badly behaved IRs, the ones for
which no metadata property holds i.e. we can't figure out anything
that all the 'representations' have in common (cf. the last line of
the Tractatus).

- Similarly it may be useful to talk about REST-modelable resources as
a subclass of IR. As I said previously I'm uncomfortable with calling
a random number generator (at a 200-yielding URI) a REST resource
because if you do so then it is impossible (IMO) to say that anything
is *not* a REST resource.

-  I take my definition of IR from TimBL, David from working backwards
from the httpRange-14 resolution. Each of us thinks the other is
idiotically insisting that rocks have legs, and neither wants to stop
using "rock" or "leg" in the way we like. Maybe we all need to be a
bit less proud. How about turning "information resource" into a DMZ? I
know we've agreed to do this in the past, and I don't know why the
decision hasn't stuck. Maybe we can pledge it on the call tomorrow and
talk about possible enforcement mechanisms.

Jonathan

On Sun, Feb 27, 2011 at 10:53 PM, David Booth <david@dbooth.org> wrote:
> [Sorry, I accidentally hit 'send' prematurely.]
>
> On Sun, 2011-02-27 at 22:07 -0500, David Booth wrote:
>> On Mon, 2011-02-28 at 01:16 +0000, Nathan wrote:
>> > even shorter:
>> >
>> >    IR = something you could potentially GET a copy of
>>
>> That sounds like it is trying to go down the same path as the existing
>> AWWW definition of IR
>> http://www.w3.org/TR/webarch/#def-information-resource
>
> I think that path is fatally misguided.  From an engineering
> perspective, it doesn't matter what is behind the interface.  All that
> matters is that the resource obeys the interface contract by following
> the protocol.
>
> The relevance that IRs have to semantic web architecture is that they
> play a *role* in the architecture of the web, as the things that have
> awww:representations.
>
> This is very much analogous to the roles played by senders and
> recipients in a protocol specification that talks about message
> transmission.  It is pointless to try to define what things in the
> universe are innately "senders" and what things are "non-senders".  If
> something adheres to the protocol and sends a message, then that thing
> *is* a sender.  Period.
>
> Similarly, it is pointless to try to define what things in the universe
> are innately IRs and what things are non-IRs.  If something adheres to
> the HTTP protocol and provides a awww:representation in response to a
> GET, then it *is* an IR.
>
>
> --
> 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 Monday, 28 February 2011 14:14:49 UTC