Re: nathans definition of an IR

Jonathan Rees wrote:
> While I find aspects of the 'vitalist' view (Nathan) and the 'cynical'
> view (David) appealing I think the presentations both suffer from the

clarification: I've got both views, I just express them at different 
times; both could be made to work, one is easier and leaves less scope 
(the one in this thread) and the other is a bit harder (especially for 
sem web) but has almost infinite scope and is a bit more useful. It's a 
trade-off thing. Just had to fully understand them both in order to get 
here.

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

agree

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

nit: you keep saying 2116 instead of 2616 :p

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

agree, to me the bridge is that all (http) URIs refer to Aristotelian 
abstractions, all resource representations are Platonic abstractions, 
resource representations are considered over time to clarify what a 
dereferencable-absolute-URI refers to, but it's always information (or a 
source of), and information about some-thing(s), information which can 
be considered in order to establish some notion or understanding of what 
is being referred to. This provides a partial view, or perspective, on 
the things for which the information is about; typically it's perceived 
to be information offered on behalf of some entity, however the 
provenance and authority of the resource representation depends on 
external checking and tracking in order to establish whether it really 
did come from where it is thought to have. HTTP+TLS of course alters 
this a bit, when coupled with dns-sec or where an ip address with - 
blah, wandering OT!

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

I'll re-read that in depth tonight with a "moderate" head on, and 
hopefully get you some useful feedback - sorry it took so long to get to 
this stage, just had to understand the space and views well enough to no 
longer be confused by them - didn't take that long (probably could have 
rewritten half the specs and techs in the same time lol!)

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

snap, I can move to the same position as you, either view can be taken 
by people, and I guess it's more of a social thing, with people choosing 
their own trade-offs, the only important bits are the vital bits of 
guidance (cool URIs don't change, except where the benefits outweigh the 
cost of course, ir/httpRange14, different names for different things).

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

or the other approach, is to build in the IR/not-IR thing right in to 
sem web via some naming convention. 200 means-IR is backwards compatible 
though, and with a clear story, it makes sense and is "good practise", 
I'm happy with either one of these approaches, but can only see one 
actually happening (keep 200-means-IR).

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

no issue imo, that's hidden behind the interface, 200 OK yields a 
representation which contains a number (or a set of numbers), to say 
that's not an IR means that a static document containing the number one 
is not an IR. However, it doesn't matter what's a REST resource and what 
isn't, it's just text, written by a human, and open to interpretation, 
we already established that right? tis just Roy's (and others) informed 
view on the world of the web circa a decade ago. Remember, everything 
ever written by every human is imperfect in some way, as we all are 
imperfect :)

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

Now that's weird - I see you and david, and tim and roy, as all saying 
the same thing, technically, well same technical constraints, which is 
all that actually matters yeah? the rest is social perceptions.

IMHO, the important thing is to make sure what works today works 
tomorrow, and also provision for what needs to work tomorrow (the 
capability to express time, perspective, or change in the semantic web).

Best,

Nathan

Received on Monday, 28 February 2011 16:32:42 UTC