W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2012

Re: Notification: Role Attribute Editor's Draft available

From: Grant Robertson <grantsr@gmail.com>
Date: Thu, 31 May 2012 20:34:28 -0700
To: <public-rdfa-wg@w3.org>
Message-ID: <4BC5CE0A044F4F56B521AD75BFC90E78@grantdesk>
Shane,
 
In Role Attribute[1], Appendix A:
 
Is/are the triple(s) created in ADDITION to any triple(s) created by normal
RDFa processing? 
 
Does this affect any aspects of the RDFa processing algorithm specified in
RDFa Core 1.1[2], Section 7.5? 
 
The first bullet says the value of @id is "used to supply the subject ..."
Does this mean just the subject for this one set of triples? Or does that
then set the [new subject] variable for all the rest of the RDFa processing
for that element? If so, does it override any other attributes that may
attempt to set the [new subject] variable?
 
If @id is not present, is the newly created bNode used ONLY for this set of
triples?  Is it possible to refer to this bNode from within the rest of the
RDFa within the document? How so? Given that the IRIs listed in @role should
only define roles rather than some other type of thing, I have to wonder how
much good it would do to have a set of triples floating around "loose" that
had its own - entirely unique - bNode as a subject with no way to attach any
additional objects to that bNode other than the roles listed in @role. The
power of bNodes lies in their ability to connect other nodes. If this bNode
connects to only a collection of roles with no way to indicate that those
are roles for some specific thing, it seems that it would be rather useless.
(Naturally, I assume the solution to this dilemma is to always use @id if
one is going to use @role.


If said triples are supposed to be entirely in ADDITION to the triples
generated by normal RDFa processing, then perhaps it would be nice to modify
Appendix A to read:
 
[[[
When @role is included in a markup language that also includes RDFa Core
[RDFA-CORE <http://www.w3.org/WAI/PF/role-attribute/#bib-RDFA-CORE> ], an
RDFa Processor must generate an additional set of one or more triples
according to the following rules:

*	If @id is present, it is used to supply the subject for these
triples by concatenating the document's 'base', a fragment separator '#',
and the value of @id. Otherwise the subject is a unique newly created bNode.
*	The predicate is the term 'role' in the vocabulary defined at
http://www.w3.org/1999/xhtml/vocab.
*	Each value of @role is an object, forming an RDF triple with the
subject and predicate defined above.

These triples must be included in the default graph returned by the
processor and may be included in any other graphs returned by the processor.

The generation of this set of triples must not affect the normal processing
of any other RDFa data contained within the document. This process is
entirely separate from the algorithm defined in RDFa Core 1.1, section 7.5
Sequence. 
]]]

(Note minor punctuation changes as well.)
 
 
Finally,  WHOA NELLY! Are you really allowed to just write a separate spec
that modifies an existing spec and specifies that the processors defined in
said existing spec must now incorporate this additional feature? How is one
to ever know that one has incorporated all of these "amendment
specifications" into one's processor or documentation? What good is to say
that a specification is now a "Recommendation" or give it a version number
if anyone can just tack on any additional features they want, any time they
want, using some other - entirely separate - document, without ever
modifying or annotating the original spec? Perhaps I am a bit na´ve, but
this just seems counter to the entire notion of having any "Standards"
whatsoever. Wouldn't it be best to simply save these additional features up
for incorporation into a later version of said existing specification?
 
 
[1] http://www.w3.org/WAI/PF/role-attribute/
[2] http://www.w3.org/TR/2012/PR-rdfa-core-20120508/


Thanks, 
Grant
Received on Friday, 1 June 2012 03:34:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:57 UTC