W3C home > Mailing lists > Public > www-tag@w3.org > May 2011

Re: FragIds in semantic web (ACTION-543)

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 9 May 2011 07:37:10 -0400
Message-ID: <BANLkTinNTieEWnwAktgvY8DhXeD4SWZvig@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:35 GMT