Re: FragIds in semantic web (ACTION-543)

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 13:57:14 UTC