Re: FragIds in semantic web (ACTION-543)

> I wonder if the mention of 'Text/Plain' in that section is correct?
> Looks like a possible copy/paste error.

You're right, thanks, should read 'text/csv'.

Indeed, a paste error from RFC5147. Will be fixed in -01 ...

Cheers,
	Michael
--
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 9 May 2011, at 12:37, Jonathan Rees wrote:

> 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:40:28 UTC