- From: Jonathan Rees <jar@creativecommons.org>
- Date: Tue, 6 Sep 2011 17:24:52 -0400
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- Cc: Noah Mendelsohn <nrm@arcanedomain.com>, www-tag@w3.org
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