Fragment Specification for RDFa

[csarven]

At the moment, I think the dcterms:conformsTo for an oa:FragmentSelector for (X)HTML+RDFa could go either way; HTML or RDF/XML, i.e., namedSection or a namedResource. In cases where the fragment has a IRI with an RDF description behind it (i.e., the triple through the RDFa markup), my understanding is to use the RDF/XML's fragment specification. If the fragment is an HTML @id with no IRI used in RDFa (with base + fragment), then the HTML fragment specification makes sense.

I think there is an alternative to above which is specific for RDFa IRIs, given that RDFa Core 1.1 CURIE and IRI Processing refers to RFC3987.

RFC3987 is also listed under http://w3c.github.io/web-annotation/model/wd2/#terminology

Am I looking at this right? Should RFC3987 be added as a fragment specification for (X)HTML+RDFa?

[iherman]

Unfortunately, this is not clear. Formally, a fragment is defined for a media type; but HTML+RDFa is not a separate media type. Ie, there is no choice in defining the fragment, it is simply for HTML. In practice, applications may have a different interpretations, but this document should not go there. The list of fragment types in the document is not a closed list, actually, applications may consider other ones.

B.t.w., the documents are now officially in feature freeze. I propose closing this issue. Can you do it please?

[azaroth42]

Agree with Ivan -- the examples in the table shouldn't be considered as the only ones, but some common examples. If that's not clear from the current text, we could work on the editorial side?

[csarven]

The text is fine as is. Okay to close the issue based on the idea that the current spec doesn't prevent any of this.

[ I acknowledge @iherman 's response but with some concern because of how it might play out in the wild. I suspect that HTML namedSection will be the common case for fragments, but this is rather inaccurate since the IRIs in RDFa are within the scope of RFC3987, and that there is no requirement for the IRI with a fragment to have a corresponding HTML @id in the document. My inquiry was that perhaps it'd be better to mention this instead of causing divergence in implementations. Which brings me to wonder whether the selection is intentionally flexible, i.e., is it solely about the nodes in HTML+RDFa or resources in HTML+RDFa? What I'm raising is primarily about the latter. ]

[iherman]

@csarven,

first of all, thanks for having closed the issue; I think that for this group, now, this is the only choice we have.

That being said, let me comment on the original technical issue is a real issue (just not for this group to solve).

For those who do not know the details of RDFa, the problem is, I believe, that there are different ways of defining, in RDFa, URI-s with fragments that only appear in the generated RDF. Eg, taking an example from the RDFa Primer, the @resource="#me" within the file http://www.ex.org/e.html is valid, and yields the URI <http://www.ex.org/e.html#me>, although there is no @id=me setting in the HTML file itself. The fragmented URI appears in the generated RDF only. The current fragment selector is therefore of no help to select it; what would be needed is a selector that refers to the generated RDF rather then the HTML file itself. And the problem is that there is no standard way to do that.

In fact, the issue is more complex. Indeed, there is no proper definition for a fragment identifier for RDF. RFC3870 is defined for RDF/XML and not for the abstract RDF graph. In particular, formally, it is not usable as a fragment identifier for, e.g., a Turtle serialization of the graph, let alone the abstract RDF graph it serializes (and RDFa is defined in terms of the abstract graph!). Ie, even if the RFC3870 were used in a fragment selector for an HTML5+RDF, it is not really precise (although implementations may probably gloss over these niceties).

(The problem is, probably, with the very notion of a fragment identifier. Formally, it is defined for a specific media type, and that does not fit the abstract RDF graph view...)

All that being said, I see some possibilities for an implementation to approach this in practice, although none of these are ideal:

1. Useing a CssSelector it is possible to access to the elements that use, e.g., @resource. Ie, it is possible to locate the elements that set those URI-s. For the purpose of an annotation that may very well be enough.
2. Use some RDFa distiller to create a URI for the generated RDF file (e.g., http://www.w3.org/2012/pyRdfa/extract?uri=http://www.ex.org/e.html), and then use the RFC3870, with the caveat described above.
3. Define a new, currently implementation specific Selector type (either a top level Selector or a subclass of the fragment selector) that, in its specification, makes it very clear what is really selected. Although the usage of a fragment may not be 100% correct in terms of the formal specification of a fragment id, this may still work.

The third option is probably the cleanest approach. If the RDF or RDFa community provides such a proper selector specification, I can imagine adding this to a future version of the specification, although it may not be necessary to do so: it should be perfectly o.k. to specify a new selector as an extension without adding it to the core spec.

(I am happy reopening the issue as a 'postponed' issue added to the V2 milestone if others think that this makes sense.)