- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 5 May 2011 18:24:03 -0400
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
Sorry to take so long to review this. Overall it's great. Just some nits. First, I think the history around RDF is more nuanced than your account allows. I think what happened is that in 2000-2005 there was a desire to use fragids in the RDF mode. RFC 2396 (1998) didn't come out and say that fragids *had* to refer to fragments, so they just did the RDF thing with them. The practice wasdocumented by RFC 3870 (2004), so there was harmony. 3986 (2005) expanded on fragids and made them a bit more abstract, probably driven to some extent by the webarch work in 2002-2004, further clarifying that the RDF thing was OK. So when you say "This led to a second set of problems..." - that is true, but these problems got fixed by 3870, at least for a while. The problem now is slightly different: the practice of using fragids in RDF wants to expand to other media types, such as application/xml and text/html, ones that do not have any accommodation for the practice, and some cases may never have such. In other words, people get into the RDF habit, and want to use it everywhere. I just noticed that there is a problem for text/owl-manchester [1], for example - which hasn't shown up in the IANA registry yet, but that's a problem for a different section of the document... but this is just an oversight, and is not the same as the xml situation, where the authors of the media type reg. really don't want the RDFa thing to be in there at all, as it messes with the pipeline. So your treatment is basically correct, but I think it needs to acknowledge that (1) there is a solution in principle (fix the media type registrations) that worked until recently, but (2) doing that is difficult and we're sort of expecting people to do something hard that they don't care about, and that's a recipe for a disconnect between spec and practice. Second point: I really would like to stamp out this NIR business if possible. I understand that it's a very convenient device, but the idea is contagious and spreads the wrong idea about how URIs work in RDF. The distinction being made is not between two kinds of thing. It is between two modes of definition, basically id= vs. RDF graph. There's nothing that says a graph can't be about an information resource or even a fragment - in fact it often is - that's what metadata is. So if possible I'd like different jargon for the purposes of this exposition. For compared to a non-information resource (NIR) in RDF/XML how about: "compared to a resource defined by an RDF/XML description" (which strays close to NIR without really being wrong). For get from a URI for a NIR to a document about that NIR how about: "get from a URI to a document containing RDF that defines that URI" These are not rigorous and can be improved on probably - just suggestions. Thanks Jonathan http://www.w3.org/TR/owl2-manchester-syntax/#Appendix:_Internet_Media_Type.2C_File_Extension_and_Macintosh_File_Type On Tue, May 3, 2011 at 4:28 PM, Jeni Tennison <jeni@jenitennison.com> wrote: > Hi, > > To fulfil my ACTION-543, I'm going to take a second stab at pulling together some text for Larry's document on MIME and the Web [1]. > > Note that the aim here is not to recommend solutions but to describe the issues. It is intended to replace the current text of Section 4.6 (Fragment identifiers) [2]. > > --- > The Web added the notion of being able to address part of an entity > and not the whole content by adding a 'fragment identifier' to the > URL that addressed the data. Of course, this originally made sense > for the original Web with just HTML, but how would it apply to other > content types? > > The URL spec stated that "the definition of the fragment identifier > meaning depends on the Internet Media Type", but unfortunately, few > of the Internet Media Type definitions include this information, > and practices diverge greatly. > > Interpretation of fragment identifiers based on media type led > to a set of problems when they are combined with content negotiation, > in which multiple representations with different media types might be > provided at a single URI. For example: > > * A particular fragment may be supported by one mime type but not > another, such as the element() XPointer syntax for XHTML being > unsupported for HTML. > > * Two mime types may define completely different fragment syntax > for the same fragment, such as an area of an image in SVG [3] and > other image types [4]. > > * Two mime types may have a different semantic interpretation of > the same fragment, such as a portion of a document in HTML > compared to a non-information resource (NIR) in RDF/XML. > > These issues are addressed at least in part within the Architecture of > the World Wide Web Volume 1 [5]. > > Later versions of the URL spec also widened the scope of fragment > identifiers to any 'secondary resource', which includes not just > parts of entities but any other resource 'defined or described by > the representation'. This led to a second set of problems with the > use of Hash URIs within the Semantic Web [6]. In these cases, fragment > identifiers are used as a mechanism to easily get from a URI for a NIR > to a document about that NIR. Standard practice in these cases is to > use a bare name fragment identifier (usually used to address a portion > of a document) without there being a document that contains a portion > named in that way. > > The third set of problems comes particularly with HTML, where web > applications use fragment identifiers to encode application state > rather than addressing part of the document, a technique that isn't > covered within the media type definition for text/html. > > In summary, interpreting fragment identifiers based on the media type > of the representation returned by a URI does not make sense in all > cases, and the definitions for their interpretation within media type > definitions are regularly ignored in practice. > --- > > Does this summarise the issues sufficiently correctly and comprehensively? > > Thanks, > > Jeni > > [1]: http://tools.ietf.org/id/draft-masinter-mime-web-info-02.html > [2]: http://tools.ietf.org/id/draft-masinter-mime-web-info-02.html#anchor16 > [3]: http://www.imc.org/ietf-xml-mime/mail-archive/msg01153.html > [4]: http://www.w3.org/TR/media-frags/ > [5]: http://www.w3.org/TR/webarch/#frag-coneg > [6]: http://www.w3.org/TR/cooluris/#hashuri > -- > Jeni Tennison > http://www.jenitennison.com > > >
Received on Thursday, 5 May 2011 22:25:31 UTC