The following issues are currently ongoing with respect to RDF/A.
Issues not yet resolved:
There is strong desire (?requirement?) for using QNames in place of URIs in order to achieve compactness of an HTML document instance. One use case expects to have substantial numbers of such URI references within a single document and wants to save storage space and transmission time.
Option A: qhref and qabout parallel href and about with datatype QName. see 2005-07-12 meeting record
Option B: a new syntax for distinguishing a QName from a URI; "compact URI". see Mark Birbeck message of 2005-07-19 and Jeremy Carroll's summary of qname/bnode proposal.
RESOLVED: Option B, we are using CURIEs. See telecon notes.The concept of reification has been confusing and awkward to use (in RDF/XML at least).
Proposal: RDF/A does not need to support a compact notation for reification.
Initial Motivation: to reduce the use of rdf:type in some examples.
Discussions:
TENTATIVE RESOLUTION: class is rdf:type, while role is xhtml2:role.
How to refer to "blank nodes" (nodes that do not have an externally referencable identifer) from within an XHTML document. See "how do we get anonymous nodes?".
TENTATIVELY RESOLVED using CURIE: with the current CURIE approach, this is resolved.
HOWEVER, further discussion is under way.
UPDATE 2006-12-17 and TENTATIVE RESOLUTION: current tentative resolution is to use the REL attribute on other elements to allow striping and thus bnode creation without explicit names (see thread.)
Images and Objects have a src attribute. There is currently no way to attach metadata to the URI value of that attribute without repeating the URI in an about attribute. Should we find a way to change this such that the image or object URI is not repeated?
A few options:
TENTATIVELY RESOLVED as YES: but pending some further report
from MarkB and the HTML WG on the nature of the src
attribute.
TENTATIVELY CHANGED to NO: src should behave like href for RDF/A, it's an object, not a subject. See telecon notes.
class
attribute
Should the class
attribute be syntactic sugar
for rdf:type
? Consider the following XHTML:
which would, under this new syntactic sugar, provide the following triples:
The class
attribute would allow for multiple values, just
like the current definition. Each value would be the object of a new triple.
CLOSED: this is the same issue as Issue #4. Resolution will come from resolution to that issue.
link
or meta
.
We may want to reify any existing RDF/A statement, not just those
expressed with link
or meta
. In fact, we can
do this without complicating the processor at all. Simply, when trying
to determine the subject or object of an RDF/A element by traveling up
the DOM tree (or checking the immediate parent in the case of
a link
or meta
), if an element with
a rev
,rel
, or property
attribute is encountered first, then the child RDF/A statement has, as
subject or object, that reified parent statement.
For example:
would yield the following:
DEFERRED: No action will be taken on this proposal in this task force, as per telecon.
link
content clickable
Should a link
element be allowed to have content which
would then be clickable? The reason for this is that link
plays a special role, e.g. in reification and blank node annotation,
and it doesn't seem like a good idea to exclude clickable links from
those special roles.
For example, assuming one wants to say that "Fyodor Dostoyevsky" is the author of a quotation, one could write the following statement:
RESOLVED: Any visible HTML element with an href attribute is clickable. However, at the XHTML WG's discretion, link and meta may be display:none by default. See TF Telecon Notes from 2006-02-06.
It may be possible to reintroduce predicate inheritance without exploding the complexity of the processor. The way to limit this feature while maintaining its advantage is to mandate that a predicate is always inherited along with its subject, and that children elements cannot override the subject and expect to inherit the predicate.
Here's how it's useful:
Note how the ul
element clearly inherits
the about
from the div
, which is then the
subject of all triples with predicate taxo:topics
. The
result is:
The general rule is that an RDF/A element without a predicate will search up the DOM tree for the closest predicate-containing element. That predicate-containing element cannot have its own object within the same element. Subject resolution then begins on that predicate-containing element.
RESOLVED: NO further inheritance, as per telecon.
If a CURIE is unqualified, what is its base? It could be either the current URI base, or the default namespace.
RESOLVED, in telecon, as Default Namespace.
Currently, about
and href
attributes are of
type CURIE/URI, which means that the value of the attribute can be
either a CURIE or a URI. When it is a CURIE, it needs to be wrapped in
square brackets as follows: [cc:license]
, in order to
differentiate CURIEs from URIs.
Should rel
, rev
, property
have
the same CURIE/URI type? Or should they be CURIE only, since there is
no precedent for them being URIs?
The advantage of CURIE only is that we get automatic backwards
compatibility for things like rel="next"
, which would be
interpreted as CURIE in the default XML namespace of xhtml2
.
If we go with CURIE/URI, then we can always declare parser-level
legacy conditions for things like rel="next"
, which would
immediately be transformed into rel="[next]"
or maybe
even more directly to rel="[xhtml2:next]"
.
Details discussed during telecon.
Debate continuing on the mailing list.
Given the RDF/A statement:
How might one designate that the value of the object should be the plain literal "Ben Adida"? Should there be some means of instructing the parser to concatenate all the text elements of children elements?
TENTATIVE RESOLUTION: The complications of solving this case seem unnecessary for the problem at hand. Currently, we recommend using the content attribute.
In the current RDF/A Syntax document (as of 2005-11-27), xml:lang is discarded for XML literals. While this may have been okay for RDF/XML, it's much worse for XHTML, which should be treated with "more respect." The fix for this may involve adding an extra SPAN or DIV as appropriate to XML literals.
We need to address all comments from Christian Hoertnagl.
The RDF/A Containers proposal does not address DL. We should eventually address it.
What happens if the head of an HTML document has an explicit about attribute?
Proposed Resolution: the default subject for the whole document is then the value of that about. This is particularly useful for those web pages that describe a non-information resource.
RESOLVED: NOT the above proposal. Instead, about is consistently inherited, but there is an assumed about="" on the head to ensure that meta and link are backwards compatible. See telecon notes.
What happens if we nest meta's and link's
This is closely tied to the issue on reifying any statement
Proposed Resolution: the subject of the inners are the same as the subject of the outer. In particular, if the outer has a about, then that's the subject for the inners. If the outer has not about, then the subject is the outer's immediate parent. A good example is found here.
How can we resolve CURIEs?
Note (2006-05-13): as the TF is considering grounding CURIEs in the current URI (possibly followed by "#"), this may no longer be an issue.
RESOLVED: CURIES, plural, as per telecon
The task force needs to cooperate with the GRDDL folks to think about the hGRDDL proposal.
In addition to this proposal, the task force is considering default hGRDDL profiles for XHTML1 and XHTML2, which would resolve issues such as rel="next". This may require GRDDL to think about pipelining for multiple transformations.
Gary Ng says that Section 3 of the Primer should be better motivated, a bit more like section 2.
The RDFa Syntax document has some bugs and is out of date. This is a non-inclusive list:
EliasT sent comments on June 3rd, 2006 regarding the RDFa Syntax document.
LeeF sent comments on May 31st, 2006 regarding the RDFa Primer document.
These comment should be addressed ASAP.
$Revision: 1.38 $ of $Date: 2007/02/14 13:09:20 $