RDFa Core, fragids, 3023bis, and FYN

ACTION-509

The question is what, if anything, would we like for the RDFa
Core 1.1 specification to say about fragment identifiers.  On Thursday
I volunteered to come up with more options, and here they are.

Why should it say anything at all?  Because documents utilising RDFa
Core will use fragment identifiers with the same semantics as in other
RDF serializations, and this should be documented somehow.  There are
two reasons to think this even though the spec doesn't call it out.
The first is examples like the following:

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

The other reason is that users will simply proceed to assume this
semantics, and it will be supported by processors.  They won't ask
permission and won't need encouragement.

I think the question can be put as follows:

  Is RDF-style fragid semantics for RDFa Core to be documented

  (a) only in the RDFa Core spec,
  (b) only in media type (or namespace?) registrations referencing RDFa
      Core,
  (c) neither, or
  (d) both?

Note that "documented" could be via a chain of normative references,
e.g. by reference to RDF Concepts, which is what RFC 3870 does.

The WG wants (b) to push it off to the media type registrations - even
though their examples depend on it - with a brief informative note
such as the one that's in the editor's draft.

For (b) and (d), RDFa Core could give this advice:

  "Those preparing registrations for media types that support RDFa
  Core are advised not only to reference RDFa Core but also to
  document this style of fragment identifier semantics, following the
  example of RFC 3870 section 3."  [for "this semantics" see their
  current note, prior to 2.1]

This might help going forward, but does not really do the trick for
current users.  It would be helpful to say something about particular
existing registrations, and revisions to those in progress. Might we
want to alert people to these, as a "health warning"?

  "As of the time of publication, the media type registrations for
  text/html and application/xml are under revision.  We expect RDFa
  Core to be referenced (perhaps indirectly) by the text/html
  registration, but are not sure what the registration will say about
  fragment identifier semantics.  The current application/xml
  registration (RFC 3023) is compatible with use of RDFa Core [?] and this
  fragment identifier semantics, but the relation between the three
  going forward is under discussion."

That's pretty horrific prose. I'll try to wordsmith in background
but didn't want to delay sending something. The problem is that
it tries to deal at the same time with connecting media type to
RDFa Core, and connecting fragids to RDF-style, while hedging
around FYN being helpful but not required. When Core and fragids
are specified in different documents you just have a mess.

This is starting to sound like an appendix.

One might also say something about application/xhtml+xml, but I'm not
sure what it would be.

>From what I understand the situation with text/html is pretty good and
we're on good ground saying so, but I'm not sure what to say about XML
as we have no information.  3023bis might end up being incompatible,
compatible but without FYN, or compatible with FYN.  What I wrote
seems to be telling people NOT to serve XML that uses RDFa Core with
media type application/xml until things settle out.  Is that really
the message we want to send?  If not, is there any other message we
can send?  Can we in good faith tell them that it's going to be OK?

N.b. IF we think that the current 3023bis draft sets up a real
conflict with RDFa Core, then the 3023bis draft is also in conflict
with deployed XHTML+RDFa 1.0 content - of which there is tons - and I
don't see how the 3023bis editors can ignore that.  That is, deployed
content either makes 3023bis untenable, or it forces us to admit that
RDF Concepts is right and RDF fragids simply aren't subject to what
the media type registrations say.

For (a) and (d), RDFa Core would have to add normative language about
fragment ids, i.e. that in an RDFa-Core-conforming document, fragment
ids have RDF-style semantics.  (The spec-ese language would have
to be crafted and I won't attempt it now
since it hasn't been on our radar.)  This would be going well past
issuing a "health warning" - it would be a substantial new provision
of their specification.

There is probably no need for (d) since the Core spec could document
fragid semantics; but documenting in both places would be good
citizenship.

Answer (c) shouldn't be dismissed out of hand; here's the case: (I
don't buy any of this, just trying to make sure it's heard)

  RFC 3986 only says the interpretation "depends on" the media type;
  that is too vague to be construable as a requirement for FYN.
  Fragid semantics could depend in some obscure way, it could depend
  on other things as well, and so on.

  RDF Concepts seems to imply that the FYN story for RDF is different
  from that of 3986, and that media types are not really involved
  after all.  That is, it says that for RDF, you get an
  application/rdf+xml representation (or you imagine doing so), then
  look at the triples to see what they say.

  Among existing media types the only one that connects fragids to
  RDF-style semantics is application/rdf+xml.  text/n3, text/turtle,
  and other RDF media type registrations say nothing.
  application/xhtml+xml handles RDFa via the XHTML namespace
  declaration, but the RDFa specification cited by the nsdoc says
  nothing about fragid semantics.  (There is a non-normative reference
  to a GRDDL transform, but the wording is too weak to make a good
  connection.)

  Some consider RDF-style FYN to be handled simply by interpreting the
  document itself.  If you read in a text/plain representation a
  sentence that says "The URI '#wh' identifies the White House",
  shouldn't you take the URI #wh as identifying the White House?  That
  is, why should the content itself be any less believable than any
  other aspect of the document, in this regard?

---

There is the other, more serious issue we raised, which is what to
do about potential conflicts between specifications of fragment
identifiers (e.g. between RDFa Core and the application/xml media type
registration).  We can declare that they're not really conflicts
(similar to what RDF Concepts does).  We can observe that there are
conflicts and ak that the conflicts be documented.  We can get
involved in the process reconciling them.

I don't consider this to be important for the question at hand (what
RDFa Core should say).  It may be important, and we should encourage
interaction between RDFa Core and 3023bis, but this particular problem
is simply not raised by their document.  If people are moved to think
about fragid FYN, then potential conflicts will become prominent
pretty quickly.  If they're not then there's not much we can do
anyhow.

---

For reference here is the complete "health warning" in the current
RDFa Core editor's draft:

  In some of the examples below we have used IRIs with fragment
  identifiers that are local to the document containing the RDFa
  fragment identifiers shown (e.g., 'about="#me"'). This idiom, which
  is also used in RDF/XML [RDF-SYNTAX-GRAMMAR] and other RDF
  serializations, gives a simple way to 'mint' new IRIs for entities
  described by RDFa and therefore contributes considerably to the
  expressive power of RDFa. Unfortunately, this practice is not at
  present covered by the media type registrations that govern the
  meaning of fragment identifiers (see section 3.5 of the URI
  specification [RFC3986], [RFC3023], and [RFC2854]). For more
  information about fragment identifier semantics, see [WEBARCH]
  section 3.2.1.

There are four sentences here. I think the first two are fine (for a
note) and can stand - they establish what "this fragment identifier
semantics" means.  I suggest the third and fourth be deleted and
replaced by either, neither, or both of the two "health warnings"
above, or variants thereof.

The reference to webarch is not helpful.


--- Notes and references ---

  - RDF Concepts has a rather bizarre explanation of fragid semantics
    that may or may not be in conflict with 3986 and/or AWWW and/or
    the current opinions of TAG members.

      http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID

  - TAG ACTION-130: Consult with Dan and Ralph about the gap between
    the XHTML namespace and the GRDDL transformation for RDFa

      http://www.w3.org/2001/tag/group/track/actions/130

  - RDFa + FYN discussed at Sept 2008 F2F.  The proposed change to the
    XHTML namespace document was carried out, but it does almost
    nothing to address fragid FYN.

      http://www.w3.org/2001/tag/2008/09/24-minutes#item01 .

  - Discussion at May F2F.  TAG consensus that the RDFa Core document
    should have a "health warning" about fragids.

      http://www.w3.org/2001/tag/2011/05/05-minutes.html#item05

  - The current RDFa Core editor's draft, which is very close to LCWD.
    The requested "health warning" is there, right before section 2.1.
    It's the outcome of interactions between JAR (on behalf of TAG)
    and the WG.

      http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html

  - Noah didn't like "at present" as it sounded like a promise and no
    one is promising.  I agreed and proposed that we have them remove
    "at present".

  - Henry (and others) were still uneasy and asked for more options.
    [insert reference to 13 Oct 2011 telcon minutes]

  - HTML+RDFa

      http://www.w3.org/TR/rdfa-in-html/

Jonathan

Received on Monday, 17 October 2011 18:50:55 UTC