TagIssue57Responses

Always-content proposals - status quo compatible

303 does not constitute a representation retrieval and is therefore not considered content opt-out in this categorization. This idea is easily challenged (303 looks just like 302 in a browser) but is stipulated in order to simplify the analysis. Proposals that deprecate 303 need to be analyzed separately.

Each of these proposals says that a retrieved representation is content (an instance, or encoding) of the identified resource. (Sometimes proposals make the weaker statement that such as the representation is of some unspecified information resource, but this has almost always been understood as implying the former, so this distinction is not considered informative.)

These proposals do not really address ISSUE-57. In effect they try to dismiss ISSUE-57 by saying people should be convinced to either use hash URIs or suffer with 303's defects.

A proposal for a new HTTP status code, which is of this kind, came up on the LOD list, but has not been turned into a change proposal yet. Other proposals of this kind have been made in the past but have not been promoted during the CFP.

No change

Given here

The key question is not answered as httpRange-14(a) is written, but most people take it to mean that the retrieved representation is content.

Jonathan Rees wrote this message which does not address ISSUE-57 but suggests strengthening httpRange-14(a) to say that retrieved representations are instances (content), or else retracting httpRange-14(a), see previous. It is not written in change proposal form as it does not address ISSUE-57; it is really just a clarifying amendment to "No change".

Mitigation: parallel properties

See http://decentralyze.com/2010/11/10/simplified-rdf/

Variant: Use hash or 303

Mo McRoberts submitted this proposal on 1 March. This proposal takes on a broader scope than just ISSUE-57.

A follow-up from the author expresses doubt of the proposition that hash URIs are unacceptable.

@@ This is really a opt-out proposal -timbl

Publish Redirect Rules

This from Sandro Hawke, most recently in Fix 303 With Client-Side Redirects.

Basically, when a web site has a generic redirect rule, it obviously saves a lot of time if the client could find out that rule.

POWDER has facilities for making statements about all URIs which match specific patterns.

New HTTP 2xx status code

Email from Kjetil Kjernsmo on 28 March suggesting a new 2xx status code to use instead of 303.

Content opt-out proposals

These proposals say that a retrieved representation is content, unless some special property holds of the HTTP response (headers or content). Therefore anyone trying to refer to content has to watch out for this special marker.

Proposal 25

Email from Tim Berners-Lee which links to

A change proposal using a HTTP header

The retrieved representation is non-content if the Document: header is present (if the response "opts out" of the content assumption).

In the opt-out case, the representation may be content of the resource, but the receiver cannot assume so without some other signal.

Look for contradiction

Email from Norman Gray on LOD list - not in change proposal form.

This says that to opt out of the representation being content of the identified resource, it says something that is recognizably inconsistent with this being the case.

E.g. suppose that :LinkedDatum is a type none of whose members have content. One could write

<> rdf:type :LinkedDatum

and the presence of such a statement would be a marker indicating opt-out of the representation-is-content default.

No-default proposals (content opt-in)

These proposals have in common that retrieved representations are not assumed to be content of the resource, or anything else in particular, in the absence of an opt-in marker. That is, a representation is not interpreted as content of the resource, or description of it, etc. absent a marker. To deduce that a representation is anything in particular (i.e. to opt in) additional information is needed, or assumptions not justified by the proposal itself.

Retract httpRange-14(a)

No consensus agreement that is; allow users to figure out solutions for themselves. Given here.

This does not directly address ISSUE-57 or the key question, and it presents some risk. It leaves open the possibility that ISSUE-57 might be addressed somehow in the future.

Variant: SHOULD not MUST

(not in change proposal form as it does not address ISSUE-57) A bit stronger than a plain retraction, Jonathan Rees proposes here that interpreting a response as content is good practice, while acknowledging that practices may vary so you have to be careful.

This is the only one of the opt-in proposals that specifies a way to opt in, although any content opt-in feature could be applied to any proposal, so this is not a significant difference.

Variant: "Middle ground"

Email from David Booth. This proposal is equivalent to "retract" as far as I can tell, since it removes the status quo agreement and doesn't replace it with anything else. This proposal appears to include the httpRange-14(a) advice, but "information resource" is redefined in the proposal to be meaningless, so in practice the effect is the same as retraction of the (a) clause.

"No longer implies"

Proposal email from Jeni Tennison; long thread on public-lod list with many interesting responses starts here.

"A 200 response to a probe URI no longer by itself implies that the probe URI identifies an information resource"

A limited opt-in mechanism is given, but it is only available in very special circumstances.

Variant: Always a description

Proposal email from Tore Eriksson. "Only information explicitly expressed in RDF is considered." "A representation retrieved from a HTTP URI will never be equivalent to what the URI denotes (the resource), but will always be a description (of the state) of the resource."

This is somewhat stronger than "no longer implies" since the presences of any RDF in the content would mark that the URI is to refer to what the content says it does (if I understand the proposal correctly).

Punning

No proposal was submitted, but the idea has been discussed frequently and it came up at the TAG F2F on 2012-04-04. The idea is that the URI could refer to either the content or to what is described, depending on some cue in the context of use (the message). In one variation the cue comes from anywhere in the message (as suggested by the RDF Semantics recommendation); in another variation it comes from the nature of the predicate used in the statement in which the URI occurs.

If there is no suitable cue from context, the URI remains ambiguous. In this case any of the above proposals, or any other default rule or lack of one, might apply.

Take cue from enclosing graph (message context)

The interpretation needs to be the same for the entire graph, but could be different from one graph to another.

This is an interoperability problem for clients that aggregate RDF content from multiple sources, and for content management systems in which multiple modules are generating RDF content independently.

This, in effect, the way things are supposed to work now, based on how RDF is documented. RDF Concepts makes no semantic connection between RDF URI References and URIs in the case of hashless URIs, so the only documented semantics would be what comes from RDF Semantics, and it says that the interpretation of RDF URI references is only constrained by the graph in which they occur and the meanings given to the RDF and RDFS vocabularies by RDF Semantics. (OWL adds some additional constraints but none having to do with the Web.)

In practice receivers choose to constrain their interpretations of RDF graphs in many ways that are not well codified, such as rdfs:comment properties both inside the graphs and found elsewhere on the Web.

(Analysis: Relying on graph content incurs interoperability risk: When content is merged from independently developed sources, a URI might be used in one way in one source, and in another way in a different source. When the sources are combined, inconsistencies or invalid inferences might result.)

Take cue from enclosing statement

If the URI appears to refer to different things in different statements in the same graph this is an apparent conflict with the RDF model theory, in which each URI has a single referent within any given satisfying interpretation. There are various ways to resolve this:

Change RDF semantics to allow for "overloading"
Interpret RDF properties to do type discrimination (only works with clear IR / NIR separation, which is problematic)
Interpret RDF values so that each one has a dual (or multiple) nature

Don't use http:

Christopher Gutteridge expressed some ideas on a blog post. Key quote: "I think it’s daft to use the same protocol to unqiuely identify real-world objects AND documents on the web. I have to explain this again and again to each person learning RDF, and it won’t take off if people can’t figure it out for themselves, like HTML, JSON, XML etc."

This has not been turned into a change proposal as of 29 March.

Comments on the baseline document

There have also been some comments on the baseline document that was prepared in preparation for the call for change proposals. These comments do not address ISSUE-57.

Some of the issues raised regarding the document are tabulated at UddpIssues.

JAR does not intend to work further on the baseline until the TAG has decided on a strategy for discharging ISSUE-57.