On 3/23/12 1:05 PM, Hugh Glaser wrote:
Thanks Kingsley, I share your concern about change - it is never a good thing when things are gestating, as they still are.I would only differ with you in the sense that I think LD actually has stalled (if it ever got out of second gear :-) ) We are many years down the track - LD is not such a challenge that it should be taking this long to take over the world.
But it is working, and its growth in on an exponential curve. It is the Web as originally conceived. We should never measure Linked Data's progress on the back of HttpRange-14 comprehension, support, adoption, or agreement. Look to the rise of structured data (even when it doesn't include the fidelity of Linked Data re. de-referencable URIs) as this is ultimately all that matters.
Of course there are good things about it - and that does not have to include RDF, as you yourself always enjoy reminding us - and these things will persist and succeed whatever we do. But the world of RDFa, microformats and things we have not yet conceived of may well be the beneficiaries of all this.
Yes! We now have increased appreciation and growth of structured data as part of the Web. This is a reflection of the effects of the Linked Data meme. Ultimately, structured data will simply create additional context for Linked Data fidelity appreciation and comprehension.
As I once said, it's easier to appreciate DBpedia if the narrative walked users and developers through the following sequence:
1. http://dbpedia.org/page/Linked_Data -- an HTML based descriptor resource (a document) that describes an unambiguously named subject; 2. http://dbpedia.org/resource/Linked_Data -- the de-referencable HTTP URI that names the subject described by the HTML based descriptor resource above.
Instead of:1. http://dbpedia.org/resource/Linked_Data -- the de-referencable Name of a Subject 2. http://dbpedia.org/page/Linked_Data -- an HTML based descriptor resource that magically appears in the address bar of browsers and introduces confusion (e.g. what do I bookmark?) from the get-go en route to HttpRange-14 imbroglio.
We need to accept that everything is not rosy, and address painful issues (for us) that lead to pain (for users) in adoption.
Ideally, we should address the pain in the solutions that we deliver to end-users and developers. Asking them to lead is broken. They are expecting to be lead by those who understand the intricacies of the journey.
Otherwise the LD world will have been bypassed and be sitting complaining they started it all and are not getting the kudos for the parts of it that succeed, when in practice they actually still sit there complaining that everyone is Doing It Wrong.
What's sometimes lost is the fact that HttpRange-14 recommendations keep the Web intact. By that I am referring to the AWWW and its ability to accommodate multiple Web interaction and exploitation dimensions. For instance, you can have structured data bearing resources that don't adhere to HttpRange-14 recommendations that work absolutely fine in the Information Space dimension i.e., where Name and Address ambiguity doesn't matter. Thus, at the inevitable point in time when ambiguity bites e.g., when trying to exploit equivalence fidelity we end up with sound context for Linked Data fidelity appreciation and comprehension. The same applies to any kind of functional exploitation of a Read-Write-Web modality.
I was not always in this field :-)
Okay :-) Kingsley
Best Hugh On 23 Mar 2012, at 16:37, Kingsley Idehen wrote:On 3/23/12 12:12 PM, Hugh Glaser wrote:Thank you Jenny, Leigh, Dave and Ian and Jonathan. I was quite excited about Jonathan's request to start with, but then decided that the context for the decision was probably much the same as before, and so there was unlikely to be much change. I would have hoped that by now the context in which we work would include large numbers of people who were building apps that consumed LD, and so could report whether a change would cause them a problem. In my case, I am pretty sure there is no problem - in fact, as a developer I should be ashamed to build a system that was so sensitive to its input data that it broke if people did not adhere to the standard. I wonder, do we have more knowledge and experience than last time? So my question here is to people who have built a real app that consumes LD, by which I mean something in use every day by someone other than the builder and their friends - preferably where someone paid you to do it. ***Would your app break under this proposal?***No, none of our apps break. Supporting this suggestions literally took seconds to implement i.e., uncomment old code for the very first implementation of Linked Data we ever implemented. Yes, that was based on internal redirection assuming clients groked relation semantics. TimBL then explained the Tabulator problem to us, and in the process the non disruptive nature of his suggestions became clear to us.My basis for supporting this change proposal is that our experience is that apps do not break, and so I would be really keen to hear about counter-examples to show me I am wrong. Although we may all be bored with the endless discussions, I think that it may actually be make-or-break for LD as it stands.I do not see HttpRange-14 recommendations as a make-or-break issue for Linked Data adoption. If that were to be true, why hasn't adoption stalled? Put differently, it isn't stopping many of us from building up customers bases where *paying* customers are doing really serious work at massive scales. In addition, it isn't impeding our ability to recruit new community members, especially those already familiar with the fundamental concepts associated with data-access-by-reference. Folks familiar with ODBC, JDBC, ADO.NET etc.. have no problem understanding Linked Data when anecdotes are tailored accordingly. To conclude, you have a growing Linked Data cloud, growing customer base (where the companies are doing serious work), a massive target community of data-access-by-reference savvy developers, integrators, and power users who are all comfortable with HttpRange-14 recommendations when translated into specific audience lingo. Adding yet another recommendation doesn't help whatsoever right now. We need to work on better anecdotes that are tailored to target audiences and profiles. KingsleyBy the way, I read Giovanni's email as intending irony. Best Hugh On 22 Mar 2012, at 20:21, Jeni Tennison wrote:Hi there, Hopefully you're all aware that there's a Call for Change Proposals [1] to amend the TAG's long-standing HttpRange-14 decision [2]. Jonathan Rees has put together a specification that expresses that decision in a more formal way [3], against which changes need to be made. Leigh Dodds, Dave Reynolds, Ian Davis and I have put together a Change Proposal [4], which I've copied below. From a publishing perspective, the basic change is that it becomes acceptable for publishers to publish data about non-information resources with a 200 response; if a publisher want to provide licensing/provenance information they can use a wdrs:describedby statement to point to a separate resource about which such information could be provided. From a consumption perspective, the basic change is that consumers can no longer assume that a 2XX response implies that the resource is an information resource, though they can make that inference if the resource is the object of a wdrs:describedby statement or has been reached by following a 303 redirection of a 'describedby' Link header. The aim of this email is not to start a discussion about the merits of this or any other Change Proposal, but to make a very simple request: if you agree with these changes, please can you add your name to the document at: https://docs.google.com/document/d/1aSI7LpD4UDuHiDNqx8qN1W400QeZdzWYD-CRuU0Xmk0/edit That document also contains a link to the Google Doc version of the proposal [4] if you want to add comments. We will not be making substantive changes to this Change Proposal: if you want to suggest a different set of changes to the HttpRange-14 decision, I heartily recommend that you create a Change Proposal yourself! :) You should feel free to use this Change Proposal as a basis for yours if you want. Note that the deadline for doing so is 29th March (ie one week from today) so that the proposals can be discussed at the TAG F2F meeting the following week. Thanks, Jeni [1] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html [2] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html [3] http://www.w3.org/2001/tag/doc/uddp/ [4] https://docs.google.com/document/d/1ognNNOIcghga9ltQdoi-CvbNS8q-dOzJjhMutJ7_vZo/edit --- Summary This proposal contains two substantive changes. First, it enables publishers to link to URI documentation for a given probe URI by providing a 200 response to that probe URI that contains a statement including a ‘describedby’ relationship from the probe URI to the URI documentation. Second, a 200 response to a probe URI no longer implies that the probe URI identifies an information resource; instead, this can only be inferred if the probe URI is the object of a ‘describedby’ relationship. Rationale While there are instances of linked data websites using 303 redirections, there are also many examples of people making statements about URIs (particularly using HTML link relations, RDFa, microdata, and microformats) where those statements indicate that the URI is supposed to identify a non-information resource such as a Person or Book. Rather than simply telling these people that they are Doing It Wrong, “Understanding URI Hosting Practice as Support for URI Documentation Discovery” should ensure that: * applications that interpret such data do not draw wrong conclusions about these URIs simply because they return a 200 response without a describedby Link header * publishers of this data can easily upgrade to making the distinction between the non-information resource that the page holds information about and the information resource that is the page itself, should they discover that they need to Details In section 4.1, in place of the second paragraph and following list, substitute: There are three ways to locate a URI documentation link in an HTTP response: * using the Location: response header of a 303 See Other response [httpbis-2], e.g. 303 See Other Location: http://example.com/uri-documentation> • using a Link: response header with link relation 'describedby' ([rfc5988], [powder]), e.g. 200 OK Link:<http://example.com/uri-documentation>; rel="describedby" • using a ‘describedby’ ([powder]) relationship within the RDF graph created by interpreting the content of a 200 response, eg: 200 OK Content-Type: text/turtle PREFIX :<http://www.iana.org/assignments/relation/> <http://example.com> :describedby<http://example.com/uri-documentation> ; . Before the last paragraph of section 4.2 insert the following two paragraphs: In the third case, where the ‘describedby’ relationship is used, <http://www.iana.org/assignments/relation/describedby> and <http://www.w3.org/2007/05/powder-s#describedby> must be treated as equivalent, as defined in Section 4.1.4 Semantic Linkage Using the describedby Property of the POWDER Recommendation [powder]. In the last paragraph of section 4.1, for “(But see below for the case when retrieval is successful.)” substitute “The next section describes how to interpret a 200 response, and therefore applies in the last two cases described above.” In section 4.2, in place of the first paragraph (after the Editorial Note), substitute: If there is a nominal representation Z from the probe URI (a 2XX response), and the application is aware of a ‘describedby’ relationship of which the probe URI is the object, which may be the case because * the probe URI is itself a URI linked to through one of the mechanisms listed in Section 4.1 or * Z itself contains a statement in which the probe URI is the object of a ‘describedby’ relationship then this is equivalent to there being a nominal URI documentation carrier for the probe URI that says that Z is a current representation of the resource identified by the probe URI, and, moreover, that the identified resource is an "information resource" (see below). In other cases, no such inference can be made (the application cannot tell whether the probe URI identifies an information resource or not). We also recommend that a clear guide on best practices when publishing and consuming data should be written, possibly an update to [cooluris]. Impact Positive Effects * common usage of URIs in sites supporting RDFa, microdata and microformats are no longer deemed to be Doing It Wrong, which means this data can be interpreted in the way that it was intended by those publishers by conformant applications * publishers that cannot change server configuration (to use 303s or Link headers) can still use separate URIs to identify a non-information resource and the information resource that describes it * publishers who (through ignorance or preference) originally publish data about non-information resources without using 303s or Link headers can retain those URIs and add the ‘describedby’ statement * it is possible to have multiple description documents for a given URI, where a 303 response only allows one * it means the same method can be used to provide descriptions of non-information resources as is used for providing descriptions of information resources, which aids adoption * it means there is a standard method for providing links from documentation to the thing that it documented Negative Effects * existing applications that assume that a 200 response is only given for an information resource may make false inferences about what a probe URI identifies (but this happens already, as people already publish data in this way) * there are more cases where applications will have to draw on reasoning from other properties (eg declared types of resources) to work out what a URI identifies * where a URI is intended to identify a NIR but provides a 200 response, there remains no method of addressing the documentation that is returned by that 200 response (to assert its license, provenance etc); a set of best practices for linked data publishers would need to spell out what publishers should do and how consumers should interpret the information provided within the response and that found at the end of any ‘describedby’ links Conformance Classes Changes There is no mention of conformance classes in the document. Risks There are no risks. References [cooluris] Leo Sauermann and Richard Cyganiak. Cool URIs for the Semantic Web. W3C Interest Group Note, 03 December 2008. (See http://www.w3.org/TR/2008/NOTE-cooluris-20081203/.) -- Jeni Tennison http://www.jenitennison.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
-- 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
