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: Thu, 5 May 2011 18:24:03 -0400
Message-ID: <BANLkTin4rsNB=_qhOJOVqA9ZH8uRebu7Pg@mail.gmail.com>
To: Jeni Tennison <jeni@jenitennison.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Sorry to take so long to review this. Overall it's great. Just some nits.

First, I think the history around RDF is more nuanced than your
account allows. I think what happened is that in 2000-2005 there was a
desire to use fragids in the RDF mode. RFC 2396 (1998) didn't come out
and say that fragids *had* to refer to fragments, so they just did the
RDF thing with them. The practice wasdocumented by RFC 3870 (2004), so
there was harmony. 3986 (2005) expanded on fragids and made them a bit
more abstract, probably driven to some extent by the webarch work in
2002-2004, further clarifying that the RDF thing was OK.

So when you say "This led to a second set of problems..." - that is
true, but these problems got fixed by 3870, at least for a while. The
problem now is slightly different: the practice of using fragids in
RDF wants to expand to other media types, such as application/xml and
text/html, ones that do not have any accommodation for the practice,
and some cases may never have such. In other words, people get into
the RDF habit, and want to use it everywhere.

I just noticed that there is a problem for text/owl-manchester [1],
for example - which hasn't shown up in the IANA registry yet, but
that's a problem for a different section of the document... but this
is just an oversight, and is not the same as the xml situation, where
the authors of the media type reg. really don't want the RDFa thing to
be in there at all, as it messes with the pipeline.

So your treatment is basically correct, but I think it needs to
acknowledge that (1) there is a solution in principle (fix the media
type registrations) that worked until recently, but (2) doing that is
difficult and we're sort of expecting people to do something hard that
they don't care about, and that's a recipe for a disconnect between
spec and practice.

Second point:

I really would like to stamp out this NIR business if possible. I
understand that it's a very convenient device, but the idea is
contagious and spreads the wrong idea about how URIs work in RDF.

The distinction being made is not between two kinds of thing. It is
between two modes of definition, basically id= vs. RDF graph.  There's
nothing that says a graph can't be about an information resource or
even a fragment - in fact it often is - that's what metadata is.

So if possible I'd like different jargon for the purposes of this
exposition. For

    compared to a non-information resource (NIR) in RDF/XML

how about: "compared to a resource defined by an RDF/XML description"
(which strays close to NIR without really being wrong).  For

    get from a URI for a NIR to a document about that NIR

how about: "get from a URI to a document containing RDF that defines that URI"

These are not rigorous and can be improved on probably - just suggestions.

Thanks
Jonathan


http://www.w3.org/TR/owl2-manchester-syntax/#Appendix:_Internet_Media_Type.2C_File_Extension_and_Macintosh_File_Type

On Tue, May 3, 2011 at 4:28 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi,
>
> To fulfil my ACTION-543, I'm going to take a second stab at pulling together some text for Larry's document on MIME and the Web [1].
>
> Note that the aim here is not to recommend solutions but to describe the issues. It is intended to replace the current text of Section 4.6 (Fragment identifiers) [2].
>
> ---
> The Web added the notion of being able to address part of an entity
> and not the whole content by adding a 'fragment identifier' to the
> URL that addressed the data. Of course, this originally made sense
> for the original Web with just HTML, but how would it apply to other
> content types?
>
> The URL spec stated that "the definition of the fragment identifier
> meaning depends on the Internet Media Type", but unfortunately, few
> of the Internet Media Type definitions include this information,
> and practices diverge greatly.
>
> Interpretation of fragment identifiers based on media type led
> to a set of problems when they are combined with content negotiation,
> in which multiple representations with different media types might be
> provided at a single URI. For example:
>
>  * A particular fragment may be supported by one mime type but not
>    another, such as the element() XPointer syntax for XHTML being
>    unsupported for HTML.
>
>  * Two mime types may define completely different fragment syntax
>    for the same fragment, such as an area of an image in SVG [3] and
>    other image types [4].
>
>  * Two mime types may have a different semantic interpretation of
>    the same fragment, such as a portion of a document in HTML
>    compared to a non-information resource (NIR) in RDF/XML.
>
> These issues are addressed at least in part within the Architecture of
> the World Wide Web Volume 1 [5].
>
> Later versions of the URL spec also widened the scope of fragment
> identifiers to any 'secondary resource', which includes not just
> parts of entities but any other resource 'defined or described by
> the representation'. This led to a second set of problems with the
> use of Hash URIs within the Semantic Web [6]. In these cases, fragment
> identifiers are used as a mechanism to easily get from a URI for a NIR
> to a document about that NIR. Standard practice in these cases is to
> use a bare name fragment identifier (usually used to address a portion
> of a document) without there being a document that contains a portion
> named in that way.
>
> The third set of problems comes particularly with HTML, where web
> applications use fragment identifiers to encode application state
> rather than addressing part of the document, a technique that isn't
> covered within the media type definition for text/html.
>
> In summary, interpreting fragment identifiers based on the media type
> of the representation returned by a URI does not make sense in all
> cases, and the definitions for their interpretation within media type
> definitions are regularly ignored in practice.
> ---
>
> Does this summarise the issues sufficiently correctly and comprehensively?
>
> Thanks,
>
> Jeni
>
> [1]: http://tools.ietf.org/id/draft-masinter-mime-web-info-02.html
> [2]: http://tools.ietf.org/id/draft-masinter-mime-web-info-02.html#anchor16
> [3]: http://www.imc.org/ietf-xml-mime/mail-archive/msg01153.html
> [4]: http://www.w3.org/TR/media-frags/
> [5]: http://www.w3.org/TR/webarch/#frag-coneg
> [6]: http://www.w3.org/TR/cooluris/#hashuri
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>
>
Received on Thursday, 5 May 2011 22:25:31 GMT

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