James, On 24 Mar 2012, at 00:38, James Leigh wrote: > On Fri, 2012-03-23 at 21:42 +0000, Jeni Tennison wrote: >> The big thing that *is* different under this proposal is that if you have an >> HTML+RDFa 1.1 document like: >> >> <!DOCTYPE html> >> <html> >> <head> >> <base href="http://example.org/me"/> >> <link rel="stylesheet" resource="style.css"/> >> <title>Me</title> >> </head> >> <body typeof="foaf:Person"> >> <h1 property="foaf:name">James</h1> >> </body> >> </html> >> >> returned with a 200 response from http://example.org/me then the application >> knows: >> >> * <http://example.org/me> is a Person >> * <http://example.org/me>'s name is "James" >> >> and does not have a stray and inaccurate >> >> * <http://example.org/me> is an information resource >> >> hanging around which was contrary to the publisher's intent. > > In the above example, the last statement is stray and inaccurate, but > that it is not always the case. Consider: > <!DOCTYPE html> > <html> > <head> > <base href="http://example.org/me"/> > <link rel="stylesheet" resource="style.css"/> > <title>Me</title> > </head> > <body typeof="foaf:Document"> > <h1 property="dc:title">Me</h1> > </body> > </html>
Yes, absolutely. Interestingly, if someone does publish something documents like that they can easily ensure that the document is interpreted as an information resource by adding a describedby link (which does have built-in semantics in RDFa 1.1): <!DOCTYPE html> <html> <head> <base href="http://example.org/me"/> <link rel="stylesheet" resource="style.css"/> <link rel="describedby" resource=""/> <title>Me</title> </head> <body typeof="foaf:Document"> <h1 property="dc:title">Me</h1> </body> </html> >> Anyway, I wonder how we might change the paragraph that you quoted to remove >> the implication that publishers can get away with one URI when they want to >> identify two things. Would this work better: >> >> 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); publishers still need to support >> a separate URI if they want to make statements about the >> documentation distinct from the NIR. An updated set of best >> practices for linked data publishers would need to spell out what >> publishers should do and how consumers should combine the >> information provided within the response with that found at the >> end of any ‘describedby’ links. >> > > Good suggestion, but I don't think we can make the decision for all > cases like this. I think we need to leave interpretation up to the > agent, who perhaps knows more about the publisher's intents. > > If an agent is looking for foaf:Person, let it disregard the statement > "this is an information resource" (no disagreements here). However, if > an agent is looking specifically for information resources, let it use > the URL (w/200 response) as the identifier of an IR, regardless of what > it contains. How is "let it disregard the statement 'this is an information resource'" is the same as "don't infer that it's an information resource". I don't see how it makes sense to infer something that you later disregard? > I would be more happy with something like this: > > When a URI is served with a 200 response, agents may use the URI > to address the IR that is returned by that 200 response, or use > the URI to address a NIR described in the response (if a > description exists). Publishers still need to support two > distinct URIs if they want agents to have a more consistent > interpretation. Can I just cast that into the language used by the rest of the proposal? What about: when documentation is served with a 200 response from a probe URI and does not contain a 'describedby' statement, some agents (including the publisher) might use it to identify the documentation and others a non-information resource. Publishers still need to provide support for two distinct URIs if they want to enable more consistent use of the URI. How does that sound? Thanks, Jeni -- Jeni Tennison http://www.jenitennison.com
