On 3/23/12 5:32 AM, Sergio Fernández wrote:
Do you really think that base your proposal on the usage on a Powder annotation is a good idea?Sorry, but IMHO HttpRange-14 is a good enough agreement.
+10000....We don't solve anything by passing more work over to developers of user agent (clients).
I've already made my views clear this matter. The issue isn't HttRange-14.We have Names, Addresses, and Resources as distinct components of a system for Web scale Linked Data (structured data that leverages hyperlinks).
The Linked Data system is comprised of:1. descriptor resources (a kindOf information resource) -- this is your typical RDF document that describes a Named Subject identified using a URI (typically an HTTP URI);
2. these descriptor resources have URLs (addresses) -- they are distinct from the URIs of the Subjects they describe.
An Information Resource is any accessible and addressable Web Resource. Thus, all HTML pages on the Web today are information resources in the generic sense.
The subject of a descriptor resource (a specific kind of information resource / document) is not a Web Resource. Said subject is just an Entity that's caught the attention of the author (creator) of a descriptor resource. The resource author has simply chosen an HTTP URI as the subject name/identification mechanism, with Web scale in mind.
To conclude:An RDF document is a descriptor resource. Again, a kind of Information Resource. The subject of said document is unambiguously named via a URI e.g., an HTTP URI.
Kingsley
Kind regards, On 22 March 2012 21:21, Jeni Tennison<j...@jenitennison.com> 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
smime.p7s
Description: S/MIME Cryptographic Signature
