- From: David Booth <david@dbooth.org>
- Date: Fri, 21 Oct 2011 00:41:11 -0400
- To: Dave Reynolds <dave.e.reynolds@gmail.com>
- Cc: Norman Gray <norman@astro.gla.ac.uk>, Leigh Dodds <leigh.dodds@talis.com>, "public-lod@w3.org" <public-lod@w3.org>
On Thu, 2011-10-20 at 22:31 +0100, Dave Reynolds wrote: > Hi Norman, > > On Thu, 2011-10-20 at 12:13 +0100, Norman Gray wrote: > > > On 2011 Oct 20, at 10:34, Dave Reynolds wrote: > > > > Benefit 1: You can provide (meta)data separately about the IR and NIR > > > [...] > > > Counter argument: this is problematic anyway. If your IR can conneg to > > > both an HTML and an RDF representation then by webarch they should be > > > equivalent. > > > > Where is this written (I can't find support for this in a quick > search through <http://www.w3.org/TR/webarch/>? > > Good point. I've been in a number of discussions where equivalence (up > to some fuzzy notion of quality) has been assumed to be required. > However, you are right, I can't see any documentary evidence backing up > that assumption. Happy to relegate it to a red herring. There is this in the discussion of URIs with fragment identifiers: http://www.w3.org/TR/webarch/#p134 [[ The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution are therefore dependent on the type of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and, effectively, unconstrained. Fragment identifier semantics are orthogonal to URI schemes and thus cannot be redefined by URI scheme specifications. ]] And this: http://www.w3.org/TR/webarch/#p137 [[ Individual data formats may define their own rules for use of the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. Therefore, representation providers must manage content negotiation carefully when used with a URI that contains a fragment identifier. ]] That same section goes on to explain that if you use content negotiation to serve different media types with inconsistent semantics for a fragment identifier then that leads to URI collision (i.e., ambiguity): http://www.w3.org/TR/webarch/#URI-collision -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Friday, 21 October 2011 04:41:37 UTC