- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 9 May 2011 07:37:10 -0400
- To: Michael Hausenblas <michael.hausenblas@deri.org>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
Yes, it helps. Thanks for the information (which I could have found myself had I been more diligent). I wonder if the mention of 'Text/Plain' in that section is correct? Looks like a possible copy/paste error. Best Jonathan On Sun, May 8, 2011 at 12:41 PM, Michael Hausenblas <michael.hausenblas@deri.org> wrote: > > Jonathan, All, > >> Are these being done with no intention of referencing these docs from >> some future media type registration? If so they are great examples for >> the presentation. > > > As for 'text/csv Fragment Identifiers' [1] the intention seems pretty clear > to me - section 5 says: > > > [[ > IANA is requested to update the registration of the MIME Media type text/csv > at http://www.iana.org/assignments/media-types/text/ with the fragment > identifier defined in this memo by adding a reference to this memo (with the > appropriate RFC number once it is known). > ]] > > Does this help? > > Cheers, > Michael > > [1] http://tools.ietf.org/html/draft-hausenblas-csv-fragment-00 > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 8 May 2011, at 14:56, Jonathan Rees wrote: > >> On Sat, May 7, 2011 at 9:32 AM, Jeni Tennison <jeni@jenitennison.com> >> wrote: >>> >>> On 7 May 2011, at 05:13, Noah Mendelsohn wrote: >>>> >>>> This phrasing is a bit vague on whether [fragment identifier] semantics >>>> must be >documented< in the media type registration (which certainly seems >>>> like good practice in any case), or whether the semantics are just a >>>> function of the media type used. Read narrowly, I think RFC 3986 says the >>>> latter. >> >> I agree with where Noah is going. I was probably stating the case a >> bit too strongly. But if the loose interpretation is fine, then a >> consequence might be that putting prose in *any* document - >> text/plain, text/html, or otherwise - such as the following >> >> The fragment id 'k' in this document is defined to identify the >> Krakatoa >> volcano eruption of 1883. >> >> would be a perfectly acceptable way to specify fragid semantics. (All >> I'm doing is substituting natural language for RDF.) This is FYN after >> a fashion. >> >> Is this what either of you thinks could be meant by 'dependent on the >> media type'? >> >> Teasing out how current practice might be interpreted as conforming to >> 3986 on the basis of an inclusive interpretation of 'dependent on' >> seems like a good idea. >> >>> That seems to happen a bit in practice. For example, the "Media Fragments >>> URI 1.0" WD [1] and the "URI Fragment Identifiers for the text/csv Media >>> Type" draft [2] specify how fragment identifiers should be interpreted for >>> particular media types outside the relevant media type specifications. >> >> Are these being done with no intention of referencing these docs from >> some future media type registration? If so they are great examples for >> the presentation. >> >>> It seems to me that for findability, you'd really want the normative >>> definition of fragment identifiers to be referenced from the media type >>> registration, but that it might be in a separate location from the media >>> type specification. >> >> In case I wasn't clear I consider normative reference to be one way to >> be part of a media type registration. And I think this is the way it >> works already. There are specifications for document formats that >> never (to my knowledge) say anything about fragids, and that's fine. >> Then there are separate documents that are the media type >> registrations that essentially do two things: (1) reference the >> document format spec, (2) define fragid semantics. I think 3023 and >> 3870 follow this pattern. Then there might be another pattern where >> fragid semantics is specified in a normative reference; I'm not aware >> of any instance but there easily could be. For FYN the question is >> whether there is *any* evidential chain from the media type >> registration to the fragid semantics, and in the case of the RDFa Core >> 2nd last call draft, there isn't. >> >> And at the risk of repeating myself, media type registration based >> 'findability' only works in the absence of conneg. It's hard to defend >> against the following view: that conneg already defeats FYN, so why >> should we kid ourselves by insisting on documenting all fragid use in >> media type registrations - it wouldn't accomplish the goal of FYN. >> >> Jonathan >> >>> Jeni >>> >>> [1]: http://www.w3.org/TR/media-frags/ >>> [2]: http://www.ietf.org/id/draft-hausenblas-csv-fragment-00.txt >>> -- >>> Jeni Tennison >>> http://www.jenitennison.com >>> >>> >> > >
Received on Monday, 9 May 2011 11:37:39 UTC