Re: Change Proposal for HttpRange-14

On 3/27/12 4:01 PM, Giovanni Tummarello wrote:
> Tom if you were to do a serious assessment then measuring milliseconds
> and redirect hits means looking at a misleading 10% of the problem.
>
> Cognitive loads,economics and perception of benefits are the over the
> 90% of the question here.
>
> An assessment that could begin describing the issue
>
> * get a normal webmaster calculate how much it takes to explain him
> the thing,follow him on and
> * see how quickly he forgets,
> * assess how much it takes to VALIDATE the whole thing works (E.g. a
> newly implemented spects)
> * assess what are the tools that would check if something break
> * assess the same thing for implementers e.g. of applications or
> consuming APIs to get all teh above
> * then once you calculate the huge cost above then compare it with the
> perceived benefits.
>
> THEN REDO ALL AT MANAGEMENT LEVEL once you're finished with technical
> level because for sites that matters ITS MANAGERS THAT DECIDE geek run
> websites dont count, sorry.

That's a really skewed and somewhat biased sequence. How about this one:

1. Demonstrate the virtues of Linked Data modulo a single line of code
2. Determine if the customer can work with the Linked Data tool as is
3. Quote on professional services if they opt to engage you to get it 
going rather that doing it themselves.

Look, your example is akin to prescribing the following to an ODBC 
driver customer:

1. Explain what an ODBC Data Source Name is
2. Explain the constituency of a connect string
3. Explain who to use the ODBC API in C/C++ or VB where Environment 
Handles and Connection Handles management creep in
4. Compare to the perceived benefits.

Q: What are the perceived, anticipated, or actual benefits of Linked Data?
A: Enterprise and/or Individual agility improvements via increased 
access to data across disparate data sources.

Q: What are the perceived, anticipated, or actual benefits of the World 
Wide Web?
A: Enterprise and/or individual agility improvements via increased 
access to data across disparate data sources.

If you bring minutia into the conversation you invite the skewed 
sequence you outlined in your sequence.

Here's what we are all ultimately seeking to enable. The sequence goes 
something like this:

1. Something piques your interest;
2. You make a statement about it in a document;
3. You publish the document to the Web (or private network);
4. Done!

This pattern works absolutely fine using hash URIs, you can even go 
kinda primitive re. your narrative. Say something like this:

1. Create a file;
2. Describe the item of interest via structured content in 3-tuple 
(triple) form using an Identifier of the form: <file-name>#this ;
3. Save the file ;
4. Publish the file to the Web;
5. Done!

This whole thing is like a global jigsaw puzzle, instead of trying to 
put all the pieces together in one go, simply contribute or connect the 
pieces that are of interest to you. The Web (or your private HTTP based 
network) will do the REST, no joke :-)

>
> Same thing when looking at 'real world applications' by counting just
> geeky hacked together demostrators or semweb aficionados libs has the
> same skew.. these people and apps were paid by EU money or research
> money or  so they should'n  count toward real world economics driven
> apps, so if one was thinking of counting   50 "apps that would break"
> that'd be just as partial and misleading.

You are simply confirming the issue re. obvious dearth of productivity 
oriented tools in the Linked Data realm.

>
> .. and we could go on. Now do you really need to do the above? (let
> alone how difficult it is to do inproper terms) me and a whole crowd
> know already the  results for the same exercise have been done over
> and over and we've been witnessing it.
>   i sincerely hope this is the time we get this fixed so we can indeed
> go back and talk about the new linked data (linked data 2.0) to actual
> web developers, it managers etc.

Managers will always fund projects that are beneficial. Thus, time to 
manifest value proposition is crucial. If the journey requires scripting 
or heavy duty coding as a basic prerequisite, it's deservedly dead on 
arrival.

>
> removing the 303 thing doesnt solve the whole problem, it is just the
> beginning. Looking forward to discuss next steps

It has nothing to do with 303. You keep on pulling 303 into to the 
conversation then end up complaining about the mess it potentially creates.

Show the value first, not the mechanics of the value engine.

As per usual, I encourage you and others to study the 20+ year old ODBC 
ecosystem which is comprised of:

1. ODBC compliant productivity tools
2. ODBC drivers
3. Relational Databases.

The only difference between ODBC Data Source Names and Linked Data is 
the use of X.500 style naming re. ODBC connection strings and the fact 
that the graphs a confined to the realm of 'C' data structures. If you 
study the API you would be quite amazed as to how much it actually covers.

Linked Data is more productive than the very ODBC pattern I celebrate in 
these permarants of mine. I've been dealing with this stuff for 20+ 
years with next to zero downtime.

Linked Data is a killer solution like no other in this utterly vital 
realm of data access, integration, and management. We just have to step 
back and understand that it improves on existing patterns rather than 
seeing it as inventing a whole new world or universe.

Please leave 303 alone, it isn't the cause of any problems. Neither is 
HttpRange-14 for that matter. If this was also so bad the Web wouldn't 
even work at all. It would have imploded a long time ago.


Kingsley
>
> Gio
>
>
>
>
> On Mon, Mar 26, 2012 at 6:13 PM, Tom Heath<tom.heath@talis.com>  wrote:
>> Hi Jeni,
>>
>> On 26 March 2012 16:47, Jeni Tennison<jeni@jenitennison.com>  wrote:
>>> Tom,
>>>
>>> On 26 Mar 2012, at 16:05, Tom Heath wrote:
>>>> On 23 March 2012 15:35, Steve Harris<steve.harris@garlik.com>  wrote:
>>>>> I'm sure many people are just deeply bored of this discussion.
>>>> No offense intended to Jeni and others who are working hard on this,
>>>> but *amen*, with bells on!
>>>>
>>>> One of the things that bothers me most about the many years worth of
>>>> httpRange-14 discussions (and the implications that HR14 is
>>>> partly/heavily/solely to blame for slowing adoption of Linked Data) is
>>>> the almost complete lack of hard data being used to inform the
>>>> discussions. For a community populated heavily with scientists I find
>>>> that pretty tragic.
>>>
>>> What hard data do you think would resolve (or if not resolve, at least move forward) the argument? Some people>  are contributing their own experience from building systems, but perhaps that's too anecdotal? Would a
>>> structured survey be helpful? Or do you think we might be able to pick up trends from the webdatacommons.org>  (or similar) data?
>> A few things come to mind:
>>
>> 1) a rigorous assessment of how difficult people *really* find it to
>> understand distinctions such as "things vs documents about things".
>> I've heard many people claim that they've failed to explain this (or
>> similar) successfully to developers/adopters; my personal experience
>> is that everyone gets it, it's no big deal (and IRs/NIRs would
>> probably never enter into the discussion).
>>
>> 2) hard data about the 303 redirect penalty, from a consumer and
>> publisher side. Lots of claims get made about this but I've never seen
>> hard evidence of the cost of this; it may be trivial, we don't know in
>> any reliable way. I've been considering writing a paper on this for
>> the ISWC2012 Experiments and Evaluation track, but am short on spare
>> time. If anyone wants to join me please shout.
>>
>> 3) hard data about occurrences of different patterns/anti-patterns; we
>> need something more concrete/comprehensive than the list in the change
>> proposal document.
>>
>> 4) examples of cases where the use of anti-patterns has actually
>> caused real problems for people, and I don't mean problems in
>> principle; have planes fallen out of the sky, has anyone died? Does it
>> really matter from a consumption perspective? The answer to this is
>> probably not, which may indicate a larger problem of non-adoption.
>>
>>> The larger question is how do we get to a state where we *don't* have this permathread running, year in year
>>> out. Jonathan and the TAG's aim with the call for change proposals is to get us to that state. The idea is that by
>>> getting people who think that the specs should say something different to "put their money where their mouth is">  and express what that should be, we have something more solid to work from than reams and reams of
>>> opinionated emails.
>> This is a really worthy goal, and thank you to you, Jonathan and the
>> TAG for taking it on. I long for the situation you describe where the
>> permathread is 'permadead' :)
>>
>>> But we do all need to work at it if we're going to come to a consensus. I know everyone's tired of this discussion,>  but I don't think the TAG is going to do this exercise again, so this really is the time to contribute, and preferably
>>> in a constructive manner, recognising the larger aim.
>> I hear you. And you'll be pleased to know I commented on some aspects
>> of the document (constructively I hope). If my previous email was
>> anything but constructive, apologies - put it down to httpRange-14
>> fatigue :)
>>
>> Cheers,
>>
>> Tom.
>>
>> --
>> Dr. Tom Heath
>> Senior Research Scientist
>> Talis Education Ltd.
>> W: http://www.talisaspire.com/
>> W: http://tomheath.com/
>>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Tuesday, 27 March 2012 20:35:02 UTC