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 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?


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

On 8 May 2011, at 14:56, Jonathan Rees wrote:

> On Sat, May 7, 2011 at 9:32 AM, Jeni Tennison  
> <> 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]:
>> [2]:
>> --
>> Jeni Tennison

Received on Sunday, 8 May 2011 16:42:24 UTC