Re: draft: Requirements for Any Theory of 'Information Resource'

Hi Jonathan,

forking the reply, will cover this stuff first then reply to the rest 
under separate cover.

Jonathan Rees wrote:
> On Wed, Feb 16, 2011 at 9:15 PM, Nathan <nathan@webr3.org> wrote:
>> I feel like I need to remind that i did violently defend and back up the
>> httpRange-14 decision and IR theory for a very long time, and very publicly
>> - but now I have to confess that my view has changed, and that now feel that
>> names are used to refer to things, and whatever most people agree a thing
>> names, is what it names - web arch and rdf simply have to accept that and
>> make it work, not constrain it.
> 
> Ah - this is what I was trying to get you to fess up to - that you
> reject the standards process as a way to coordinate implementors.  In
> that case why on earth are you spending a single minute on W3C
> business?

That is certainly not what I said or implied, I strongly feel the 
standards process is critical to achieve interoperability, and to 
balance room for evolution with constraints to actually make the thing 
work - and to that end devote at least 80 hours a week, unpaid, to try 
and help that process along. It's 3.30am here and I'm still doing what I 
can. I got to this stage, because when I was "just a developer" some 
people told me that the semantic web was ready to use, that I could use 
the read write web of data right now, and I thought that would be great, 
after trying I found that to be false, lost a huge contract because of 
it, and then decided that I thought it (rww) was worth investing the 
time in to help it come to fruition - that's why I'm here, because one 
day, as soon as possible, I want to take all these techs W3C is 
standardizing, thinking about or that are simply mapped out somewhere, 
and actually use them all, together. You see me doing that every day 
Jonathan, so I don't feel your comments are quite fair :(

Now, I fully believe there are Information Resource (of course there 
are!), and that many IRs are named with dereferencable absolute-URIs, 
but not all, and that to get past 50% you need to start being pretty 
loose about your definition of an IR (taking in to account Expressions, 
Works, Manifestations and Items in frbr terms). At the same time I fully 
believe that many people use URIs to refer to anything under the sun, 
and things more abstract than that (they do in RDF, and they do in real 
life). And further, from a technical standpoint, I know that the 303 
pattern is bad for the network (needing another request), can lead to 
some tricky deployments, and that general humans don't "get" it, see the 
dbpedia case for example, and also that "representations" aren't 
naturally named by dereferenceable absolute URIs, neither are processes 
that run on servers, which ironically are the two things people 
(developers) often think they refer to, out there on the web.

So, for a multitude of reasons I came to the conclusion that 
interoperability would be best improved by having two distinct classes 
of, or views of, names on the web, that both shared the same lexical 
form - a set which people use in network terms to GET/PUT/POST, and a 
set used to refer to what people called "resources" or "things", used as 
names. That way nobody GETs a 404 on an elephant and deduces that the 
elephant can't be found, rather they GET a 404 and deduce that no 
information could be found, that their request failed.

Also, there's interoperability between humans, between communities to 
consider - and at the minute that's a mess.

All the above I believe to be true, I'm not from an academic background 
but I'm entitled to my opinion, and I'm entitled to think that 
httpRange-14 needs withdrawn, that AWWW needs an update, particularly 
around the use of fragments and URIs as names, and that the web 
communities (different WGs) need a story they can all get behind in 
order to encourage convergance and interoperability, so that what I'd 
call "web 3.0" can get going sooner rather than later.

>> However, I also respect you, and those that made the IR decision in the
>> first place, so happy to go along with proving or disproving it - my own
>> theory is that we can both simultaneously prove and disprove it, depending
>> on which way were looking at the situation, or what we're trying to achieve,
>> or what use-case we are considering.
> 
> That is absolute gibberish. We are talking about interoperability
> engineering.  The community decides what agreements it wants to hold
> to. If coordination is too expensive, or the people who matter can't
> be engaged, no one bothers, and you just suck up and live with
> incompatibility. If interoperability is an issue and there is the will
> to get it, it can be obtained.

Indeed, it just appears that you and I have different opinions on how 
interoperability can be achieved. AFAICT the HTTP, web of documents and 
network oriented communities have suggested "we use URIs as locators" 
and the sem web has said "web use URIs as names" and that linked data 
has said "we use URIs in our data as both names and locators", so rather 
than have the fighting, tell the sem web and linked data people that 
their URIs are names, and that this portion of it is a locator, and tell 
the HTTP/network communities to just keep using URIs as they always 
have. That's interoperability, is it not?

> What I'm saying is that if some people do this one way, and some do it
> another, then the value of these URIs plummets and some alternative
> means has to be used to defend against inconsistency. When linguistic

exactly, I'm saying the same thing, so rather than letting that happen, 
and rather than saying that only X percent of people can be catered for, 
just remove the issue such that URIs are URIs and such that sem webbery 
and all things that deal with "names" use names instead (names that 
contain URIs).

> territory gets invaded you have to either defend or abandon it. There
> is a big investment in the architecture I've described, in
> specification preparation, software, and documents. Changing things
> means pulling the rug out from those who have invested in it. This has
> to be done with respect. We can ditch it, but I want everyone to know
> the cost: all generic metadata tools break.

that's an important factor, can you give me an example of one which 
breaks (or something that does)? I can see how they do with some 
proposals, like using different URI schemes, or changing the way we 
construct statements, or changing syntax, but not all solutions have 
those caveats..

> A couple of people have asked what breaks if we ignore the
> architecture. Of course nothing breaks, just as having your own
> private incompatible version of HTML served up under text/html doesn't
> break anything - as long as you don't care about interoperability with
> the deployed one, which obviously those who want to withdraw
> httpRange-14 don't.
> 
> Having different parties prove contradictory statements is the
> definition of incompatibility.
> 
> What do I have to do to convince you of this?

nothing, I'm already convinced of it, and have been for a long time - I 
just think there are other considerations and different ways to approach 
this. What's important here, is that different parties don't 
contradictory statements, as you say :) there's more than one way to 
achieve that, and some ways have positive knock on effects to related 
techs, and network optimizations when deploying these techs.

> I'm not trying to defend the quality of the architecture; in many ways
> I think it's pretty silly. But I just don't see the point of this much
> upheaval and I hate the attitude that you can just ignore a
> principled, organized design that lots of people have worked hard to
> build and exploit. If # is too hard to write, or a new set of names
> defined by anarchy it needed, then let's deploy a new URI scheme or
> something - it will be easier than rewriting every spec that talks
> about URIs.

It appears # is to hard to write for some (!?) and that a new URI scheme 
will probably just fail or be ignored, and that 303 isn't very nice for 
people to use, if rewriting (well refining the human understanding/view 
without changing the implementations and technical details) is also too 
much, then god knows.

Hope something is worked out though!

Best and Regards,

Nathan

ps: tis 4:30 now, next reply will be after some sleep most likely

Received on Thursday, 17 February 2011 04:31:39 UTC