Re: Change Proposal for HttpRange-14

On 3/25/12 1:18 PM, Hugh Glaser wrote:
> Hi Kingsley,
> On 25 Mar 2012, at 17:17, Kingsley Idehen wrote:
>
>> On 3/25/12 7:18 AM, Hugh Glaser wrote:
>>> Fair questions, Michael.
>>> I have a lot of sympathy for your "I don't see the point of this whole discussion".
>>> We can write what we want in documents, but the world can ignore them - and will if they don't work.
>>> And the world will be what it is, not what we want it to be.
>>>
>>> However.
>>> Unfortunately, perhaps, standards are important for people who work in the field providing systems to others.
>>> Personally, I never did agree with the solution, but have always aimed to carry out the implications of it in the systems I construct.
>>>
>>> This is for two reasons:
>>> a) as a member of a small community, it is destructive to do otherwise;
>>> b) as a professional engineer, my ethical obligations require me to do so.
>>>
>>> It is this second, the ethical obligations that are the most significant.
>>> I should not digress from the standards, or even Best Practice, in my work.
>>> (Apart from anything else, the legal implications of doing otherwise are very unpleasant.)
>>>
>>> This means that systems involving Linked Data do not get built because the options I am allowed to offer are too expensive (in money, complexity, time or business disruption), or technologically infeasible due to local constraints.
>> But as an engineer the complexity of the spec shouldn't determine the very essence of the spec. The whole AWWW is about the "deceptively simple" principle in action. It isn't a "simply simple" solution.
> I keep meaning to ask: what is AWWW? It's not a term I see used anywhere but your emails.

Architecture of the World Wide Web.


>> We have URI abstraction and styles of URIs (hash or slash). The system (Linked Data in this case) is concerned about separation of powers right down to the fine-grained level of structured data representation. As result, there are implications that arise from the style of URI used in this context.
>>
>> Since 1998 we've ended up with the following syntaxes and serializations formats for the RDF model (EAV enhanced with URIs, language tags, and typed literals):
>>
>> 1. RDF/XML
>> 2. N3
>> 3. Turtle
>> 4. TriX
>> 5. N-Triples
>> 7. TriG
>> 8. NQuad
>> 9. (X)HTML+RDFa
>> 10. HTML+Microdata
>> 11. JSON/RDF
>> 12. JSON-LD.
>>
>> Don't you see a pattern here? Also what's an innocent newbie supposed to do when they encounter the above.
> Probably run screaming from the room.
> Or at least tell us to go away and come back when the community has sorted itself out.
> (Were I to present things this way.)
>> Now we want repeat the pattern, this time scoped to URIs and they usage re. Linked Data fidelity:
>>
>> 1. hash -- Linked Data indirection is implicit
>> 2. slash -- 303 redirection delivering Linked Data indirection explicitly
>> 3. slash -- 200 OK and no redirection leaving user agents to process relations (and HTTP response headers) en route to manifestation of Linked Data's mandatory indirection.
>>
>> Again, don't you see the same pattern is taking shape i.e., a potpourri of suggestions that ultimately only add more confusion to newbies. Even worse, this particular suggest is ultimately a reworking of the entire AWWW.
> I'm not sure I agree with your assertion of the same pattern.
> In any case, I didn't say this proposal was perfect - I would do it differently.
> But if it is a broken world - not fixing it should not be an option.

I don't think the AWWW is broken. That's my fundamental argument.

> You and I will have to differ as to whether the Project is currently a success - you clearly think so - I think that we are far back from what where we should be by now.

I don't think so. There is more structured data on the Web, and it is 
growing exponentially. This simplifies the entire pursuit of Web scale 
Linked Data.

>>> So the answer to your first question is yes: semantic web (parts of) projects are stopped because of this.
>> I don't buy that for one second. There's a little more to it than that.  How about the tools being used for these projects? You statement implies the very best tools available where used and they failed. You know that cannot be true.
> Actually, it is.
> Your fallacy is to think that these are purely technological issues, and can always be solved with "tools".

I know these issues can be solved by tools. I've designed such tools and 
they are in broad use :-)

> These are socio-technical issues at best.
>>>   Ethics and community membership requires it.
>>> When they do go ahead, of course they actually cause me some pain - implementing a situation I think is significantly sub-optimal - but I do not have the choice.
>> We have to separate issues here. We have:
>>
>> 1. a spec or set of best practices;
>> 2. tools that implement the spec or best practices;
>> 3. projects seeking to exploit the spec or best practices.
>>
>> You are basically ruling out tool choices as reasons for project failure.
>>
>>> Of course, people who are outside this community will do what they feel like, as always.
>> And in due course opportunity costs force them to reevaluate their choices. Decision makers in commercial enterprises don't care about technology, they are fundamentally preoccupied with opportunity costs. Make opportunity costs palpable and you have the ear of any decision maker in charge of a commercial venture.
>>
>>> But the current situation constrains the people in the community, who are the very people who should be helping others to build systems that are a little less broken.
>> It doesn't. I just don't buy that. You can have Structured Data that isn't Linked Data. We can't have it both ways. Why not move folks over in stages i.e., get them to Structured Data first, then upgrade them to Linked Data since the virtues of the upgrade will have much clearer context since Structured Data modulo Linked Data fidelity has clear limitations. Basically, turn what seems to be today's headache into a narrative showcasing specific virtues.
> Well you should be buying - if people didn't feel constrained they would not have proposed the change.

This doesn't reflect the *majority* of this communities membership.
> By the way, if I try and sell them "Structured Data" I don't get the benefit of them feeling they are joining a Big Movement.
> (Wikipedia redirects to http://en.wikipedia.org/wiki/Data_model and http://structureddata.org/ is really not very exciting.)
> You seem to be advocating yet more terminology and even practices.

I am advocating ways to be more accommodating. Right now we have 
structured data growing exponentially. That's an awesome thing. It will 
deliver the missing context for mass appreciation and comprehension of 
the Linked Data meme and the best practices it espouses.

> This just confuses the situation more, as you describe above.

It doesn't. People need to understand and appreciate Structured Data en 
route to Linked Data [1].
>> Also note, we don't have a bookmarking problem with any style of URI for Linked Data. People can start by bookmarking the URLs of Information Resources.
> I just don't understand that - how do your deal with the myexperiment.org situation without getting the chemists to understand they can't bookmark in the browser and expect to paste into a field that wants to know about a workflow?

You can bookmark a entity URI or the URL of its descriptor document. 
When dealing with Linked Data its just about *indirection*. A hash URI 
hides the slight of hand, while a slash URI doesn't.

Links:

1. http://www.mkbergman.com/962/structured-web-gets-massive-boost/ -- a 
nice post about structured data and its relevance to the the Semantic 
Web in general.

Kingsley
>
> Cheers
>>
>> Kingsley
>>> Best
>>> Hugh
>>>
>>> On 25 Mar 2012, at 11:03, Michael Brunnbauer wrote:
>>>
>>>> Hello Jeni,
>>>>
>>>> On Sun, Mar 25, 2012 at 10:13:09AM +0100, Jeni Tennison wrote:
>>>>> I agree we shouldn't blame publishers who conflate IRs and NIRs. That is not what happens at the moment. Therefore we need to change something.
>>>> Do you think semantic web projects have been stopped because some purist
>>>> involved did not see a way to bring httprange14 into agreement with the
>>>> other intricacies of the project ? Those purists will still see the new
>>>> options that the proposal offers as what they are: Suboptimal.
>>>>
>>>> Or do you think some purists have been actually blaming publishers ? What will
>>>> stop them in the future to complain like this: Hey, your website consists
>>>> solely of NIRs, I cannot talk about it! Please use 303.
>>>>
>>>> You are solving the problem by pretending that the IRs are not there then
>>>> the publisher does not make the distinction between IR and NIR.
>>>>
>>>> Maybe we can optimize the wording of standards and best practise guides to
>>>> something like "these are the optimal solutions. Many people also do it this
>>>> way but this has the following drawbacks..."
>>>>
>>>> Regards,
>>>>
>>>> Michael Brunnbauer
>>>>
>>>> -- 
>>>> ++  Michael Brunnbauer
>>>> ++  netEstate GmbH
>>>> ++  Geisenhausener Straße 11a
>>>> ++  81379 München
>>>> ++  Tel +49 89 32 19 77 80
>>>> ++  Fax +49 89 32 19 77 89
>>>> ++  E-Mail brunni@netestate.de
>>>> ++  http://www.netestate.de/
>>>> ++
>>>> ++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>>> ++  USt-IdNr. DE221033342
>>>> ++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>>> ++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>>>
>>
>> -- 
>>
>> 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
>>
>>
>>
>>
>>
>>


-- 

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