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

On Mon, Oct 17, 2011 at 4:04 PM, ashok malhotra
<ashok.malhotra@oracle.com> wrote:
> Jonathan:
> I would vote for d) i.e. document both in RDFa Core and the relevant media
> types.

The implication would be that the RDF-style fragids would work for all
document types into which RDFa Core was mixed. I'm not even completely
sure that RDFa Core (as opposed to a document format spec, or a media
type registration) even has standing to say something like this.

If it does have standing, then the documentation saying it could be
either normative or informative - by (a)/(d) I had in mind normative.
Being normative would be an observable change to their spec since
currently you could theoretically use RDFa Core with a media type reg
that gave unconventional meanings to fragids, perhaps even ruling out
RDF-style semantics. Something like this could only make it into their
last call with swift effort (assuming the WG could even be persuaded).

I'm not sure that documenting the practice informatively is much
better. That would be a big deal in a different way, because we'd have
to come up with some justification for it coming from outside the
spec.

So I'm not too keen on this option, right now. But willing to try it
if there's support.

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

Sounds like a lengthy project. And I'm not sure I agree with the
premise. All the more reason to decouple this issue from the Core
draft.

Best
Jonathan

> 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 22:06:31 UTC