Re: RDFa Core, fragids, 3023bis, and FYN

Jonathan:
I would vote for d) i.e. document both in RDFa Core and the relevant media types.

As re. the conflict between spec re. frag id processing, I would pursue the other
thread we have discussed and write a note as a companion to 3896 that explains that frag id processing is influenced by the context and the agent.
All the best, Ashok

On 10/17/2011 11:50 AM, Jonathan Rees wrote:
> 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 20:05:29 UTC