Re: Fragids status report [partial]: ACTION-567

Here are some of my notes on the subject...

Re ACTION-509 http://www.w3.org/2001/tag/group/track/actions/509

At the telcon of 11 August, JAR suggested to close ACTION-509 by
asking the RDFa WG to remove the words "at present" in the following
sentence RDFa Core 1.1

  "Unfortunately, this practice is not at present covered by the media
  type registrations that govern the meaning of fragment identifiers."

http://www.w3.org/2001/tag/2011/08/11-minutes
http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html

Henry is scribed as disagreeing, saying: "Fussing with the wording
before settling the architectural issue isn't necessarily the best
course. Not that I will necessarily understand the architectural
issue, and I have taken some responsibility for moving on the larger
cluster of fragid-related issues."

I interpret this as, at least in part, a challenge to the truth of the
"unfortunately, this practice" statement itself.  So I wanted to look
into this a bit more closely.

Here is one of the examples in question:

<p about="#bbq" typeof="cal:Vevent">
      I'm holding
      <span property="cal:summary">
        one last summer barbecue
      </span>,
      on
      <span property="cal:dtstart" content="2015-09-16T16:00:00-05:00"
            datatype="xsd:dateTime">
        September 16th at 4pm
      </span>.
    </p>

Consider what happens if this RDFa is retrieved via URI
http://example.org/summer and marked as application/xml.  (It wouldn't
have to be so marked; RDFa Core says nothing whatsoever about media
types.  This in itself is somewhat troubling.)  We would have the RDF
statement

  <http://example.org/summer#bbq> rdf:type cal:Vevent .

cal:Vevent is documented as follows: "Provide a grouping of component
properties that describe an event."  So the RDF statement seems to say
that the URI http://example.org/summer#bbq refers to a grouping of
properties (although this is not clear).

There is a similar example in the draft where the RDF seems to say that a URI
refers to something that can have a foaf:name and a foaf:homepage; and
a third example where the URI refers to something having a dc:source
property.

RFC 3986 says: "The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation."

http://www.ietf.org/rfc/rfc3986.txt

So, we look at the media type, defined by RFC 3023.  Here's what it
says:

   As of today, no established specifications define identifiers for XML
   media types.  However, a working draft published by W3C, namely "XML
   Pointer Language (XPointer)", attempts to define fragment identifiers
   for text/xml and application/xml.  The current specification for
   XPointer is available at http://www.w3.org/TR/xptr.

3023bis is more definite:

   A modular syntax and semantics of fragment identifiers for the XML
   media types is as defined by the [XPointerFramework] W3C
   Recommendation.

http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
http://www.w3.org/TR/xptr-framework/

Checking the XPOINTER framework we see:

   A shorthand pointer, formerly known as a barename, consists of an
   NCName alone. It identifies at most one element in the resource's
   information set...

Now, in order to make the RDF reference consistent with what is
"identified" according to XPOINTER, we would need for the instance of
ical:Vevent, which has an ical:summary and an ical:dtstart, as well
the owl:Thing (from the other example) that has a foaf:name and
foaf:homepage, to be XML elements.

Now it might be possible to do this consistently, and probably there
are people who will insist that the resources described by the
RDF are in fact XML elements, and there is no difficulty.  In this
case the warning paragraph in the Core draft can be removed.

But the result of such an interpretation would be both fragile and, I
think, not what is intended.  The idea, I think, is that hash URIs are
to be used in RDFa Core in the same way that hash URIs are used in RDF
generally: to talk about all sorts of things, not just the limited and
rather obscure domain of XML elements. Although this is not called
out explicitly, I would be very surprised if the RDF community didn't
read the RDFa Core spec in this way, given the examples
provided.

I think the WG agreed about this, thus their acceptance of the
"Unfortunately" warning.

Ways one might evade this difficulty:
  - Everything is (ontologically) an XML element
  - Don't use application/xml or ...+xml with RDFa Core
  - RDF "reference" is unrelated to "identification"
  - Fragid semantics just works differently at the representation and
resource levels
  - Change 3023bis
  - Look the other way

None of these has been done "at present", other than the last,
ergo the warning. No one is promising to do any of these, ergo
the misleadingness of "at present".

Jonathan

On Thu, Aug 11, 2011 at 11:25 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've reviewed the situation, and offer the following summary of where
> we stand.  Much of this starts from Jeni's earlier [0] introduction.
>
> 1) 'Official story': in general
>
> The two relevant high-level documents, namely RFC 3986 [1] and AWWW
> [2] place only minimal constraints on the syntax and semantics of
> fragids.  RFC 3986 in particular emphasizes the flexibility granted to
> user agents with respect to fragid processing.  The one moderately
> strong constraint expressed by both RFC 3986 and AWWW is that in the
> case of content negotiation, whatever subset of the possibly returned
> media types specify a fragid semantics should identify the same
> resource for all (types of) fragids.
>
> 2a) 'Official story': in particular, _status quo_
>
> Three obviously relevant existing media type registrations, namely
> HTML [3], XHTML [4] and RDF/XML [5], all appear to _assume_ that
> fragids are syntactically names, without actually mandating this, or
> specifying what, if anything, is to be done in the case of non-name
> strings.
>
> SVG [6] requires that a fragid for application/svg+xml docs is
> _either_ an 'XML_Name' (without further explanation) with or an SVG View,
> of the form svgView(...).
>
> 2b) 'Official story': in particular, in progress
>
> The draft application/xml and application/...+xml media type
> registration (RFC 3023bis [7]) covers both names (by reference to the
> XPointer Framework spec. [8]) and more complicated fragids which are
> in the form of registered XPointer schemes [9].  It _requires_ that in
> _all_ cases the semantics are such as to "[designate] that part of
> _the retrieved representation_ specified by [XPointerFramework] and
> whatever other specifications define any XPointer schemes used."
> [emphasis added]
>
> The draft N3 media type registration [10] mandates name syntax by
> reference to 'qname' (again, without any explicit reference or
> definition).  It explicitly makes the semantics completely
> unconstrained in the general case:
>
>  "The fragment identifier part of a URI where the rest of the URI is
>  that of an information resource which has a representation in N3 is
>  used to identify any thing whatever, abstract or concrete."
>
> The draft text/html media type registration [11] doesn't constrain the
> syntax beyond what RFC 3986 does, but specifies a semantics of DOM
> nodes identified by ID or NAME attribute matching.
>
> [out of time, so this stands as a partial introduction for the time
>  being -- to be continued]
>
> ht
>
> [0] http://lists.w3.org/Archives/Public/www-tag/2011May/0089.html
> [1] http://tools.ietf.org/html/rfc3986#page-24
> [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#fragid
> [3] http://www.rfc-editor.org/rfc/rfc2854.txt
> [4] http://www.rfc-editor.org/rfc/rfc3236.txt
> [5] http://www.ietf.org/rfc/rfc3870.txt
> [6] http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#SVGFragmentIdentifiers
> [7] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
> [8] http://www.w3.org/TR/xptr-framework/
> [9] http://www.w3.org/2005/04/xpointer-schemes/
> [10] http://www.w3.org/TeamSubmission/2011/SUBM-n3-20110328/#frag
> [11] http://www.w3.org/TR/2011/WD-html5-20110525/iana.html#text-html
> - --
>       Henry S. Thompson, School of Informatics, University of Edinburgh
>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
>                       URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail from me _always_ has a .sig like this -- mail without it is forged spam]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFOQ/RfkjnJixAXWBoRApg2AJ9nTceIu6zW0dSBCtFXgc39ncA95ACePi+X
> Y6nDTIfNLm1EYY+ZZVv11vs=
> =0LcM
> -----END PGP SIGNATURE-----
>
>

Received on Tuesday, 6 September 2011 21:26:02 UTC