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 is3. 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 string3. 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<[email protected]> wrote:Hi Jeni, On 26 March 2012 16:47, Jeni Tennison<[email protected]> wrote:Tom, On 26 Mar 2012, at 16:05, Tom Heath wrote:On 23 March 2012 15:35, Steve Harris<[email protected]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
