Re: FragIds in semantic web (ACTION-543)

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 Sunday, 8 May 2011 16:42:24 UTC