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

Re: Role Attribute Module and vocabularies

From: Niklas Lindström <lindstream@gmail.com>
Date: Sun, 26 Feb 2012 01:13:28 +0100
Message-ID: <CADjV5jf-WKoGdik-Oivf-YOCHbxhuz2g5Eg5SG8+zMbJVKFmhQ@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: W3C RDFWA WG <public-rdfa-wg@w3.org>, Protocols and Formats Working Group WG <w3c-wai-pf@w3.org>
Hi Shane,

I don't think that @vocab should apply to @role. The scope of the
@role attribute is orthogonal to the scope where RDFa is applied. Role
is about the behavioural semantics of the markup structure itself,
whereas RDFa annotates the subject matter carried by this markup. In
the latter, @vocab works to set the scope of domain specific content
meaning, whereas @role is bound to markup mechanics such as
accessibility (navigation and other interaction). These two aspects
rarely overlap, and rarely share the same vocabularies, so @vocab
cannot reliably work for both concerns at once.

(This separation of concerns is also apparent in the fact that the
subject of @role is the element itself (using base + @id if present),
not any corresponding @about or @resource.)

Consider this piece of markup (based on our use of RDFa for legal
information but reduced here to plain Dublin Core for comprehension):

    <article vocab="http://purl.org/dc/terms/" lang="sv"
             resource="/publ/sfs/1999:175" typeof="BibliographicResource">
      <header role="banner">
        <h1><a property="isPartOf" href="/fs/sfs">Svensk
        <link property="publisher" href="/org/regeringskansliet" />
      <section role="main">
        <h1 property="title">Rättsinformationsförordning</h1>

Notice how the @role values don't have anything to do with the
bibliographical data captured by the RDFa. The role terms are expected
to represent the regular roles (defined in xhv), not resolved to the
dc vocabulary in @vocab.

So my advice is to keep the default vocabulary for @role hardwired to
<http://www.w3.org/1999/xhtml/vocab#> (in HTML-based host languages)
and have all standardised terms belong to that vocabulary. For
specific extensions to @role, use @prefix and CURIEs, or full IRIs.

Best regards,

On Wed, Feb 15, 2012 at 5:49 PM, Shane McCarron <shane@aptest.com> wrote:
> As many of you are aware, the PFWG is responsible for development of the
> Role Attribute Module [1].  This document will soon enter CR review.  Role
> is a very simple document, and it has a couple of dependencies on RDFa.  One
> is the definition of CURIE.  Right now the document points to RDFa Syntax
> because RDFa Core was not going to be ready in time.  Given the current
> schedule, it is possible that we could change this to RDFa Core.  I am
> pondering that now.
> The other is a dependency on the TERMorCURIEorAnyIRIs datatype.  @role takes
> this type, and the type is defined in RDFa Core.  The definition is not
> complicated, and we are of course able to just reproduce the definition in
> Role so that we have no dependency on RDFa Core. I am pondering this as
> well.
> Finally, there is a potentialy sticky issue.  The document indicates that
> additional role values can be defined (of course) but it does not say how.
>  It also does not say how such definitions would be referenced by a document
> written in a host language that uses @role.  Obviously (to us) the
> references would be done with @vocab, and the vocabularies would be defined
> using RDFa so that entailment could happen.  But this is not described at
> all in the Role spec.  My question for the RDFWA WG is "should Role
> reference RDFa Core and should Role mention the use of @vocab and the
> implied format of vocabulary documents as an example?"  Obviously if the
> answer to these questions is yes, then the Role spec should have a normative
> dependency on RDFa Core.
> Help?
> [1] http://www.w3.org/WAI/PF/src/role-attribute-src.html
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
> +1 763 786 8160 x120
Received on Sunday, 26 February 2012 00:14:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:30 UTC