W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: Issues with @token scoping and hidden-data

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 21 Mar 2010 11:52:02 -0400
Message-ID: <4BA640A2.7040706@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
On 03/20/2010 06:02 AM, Ivan Herman wrote:
> I must admit I do not fully understand; there is something that must
> have been said and maybe even written but I did not find or grasp.

Based on your most recent e-mail, I do think you understand the three
basic approaches we are discussing. In a separate e-mail, I'll try to
elaborate how I think that the default prefix proposal and the RDFa
vocabularies proposal can be merged.

> Let me try to write down what I understand in what you seem to be saying
> in some more general terms.
> 1. the model in the @profile document that was started by you and I then
> refined a bit was, schematically:
>    - @profile document is, in fact, a set of RDF triples serialized in
> something; conveniently in RDFa, can be something else
>    - the triples are interpreted by the author document to define
> keywords or, maybe, prefixes

That is correct.

I'd go one step further on your second bullet point and combine
keywords/prefixes into just a "list of mappings". See Mark's e-mail for


> 2. you seem to say that in this @token model the profile document is an
> RDFa file where, somehow, the RDFa attributes are interpreted
> differently if being pulled into an author document rather than when
> being used by itself. Ie, the RDF triples generated by that RDFa file
> are not really relevant, in fact.

That's correct.

> In other words #2 says (and this is what you seem to imply below) that
> the interpretation of the @profile document is context dependent,
> depending on whether it is being pulled into an author document or
> whether it is used to produce, for example, a documentation of the
> vocabulary, ie, used as a good old simple RDFa document.

Yes. Put another way:

* @token, when used in an author document, extends the "list of
* @token, when used in an RDFa Profile document, extends the "list of
  mappings". It also can extend the "list of mappings" in author
  documents if it is included via @profile.

> If this is really the case then... I am sorry, but I really really do
> not like alternative #2. Making the interpretation of RDFa attributes
> dependent on the context of where they are used is complex, difficult to
> explain and understand, error prone, ... and as you say, really an
> anti-pattern. We are totally overcomplicating things I am afraid.

I agree, but could live with the solution - the perceived complexity, I
believe, is largely a teaching problem. My core issue with this approach
is that it breaks from our general design for attributes (all RDFa
attributes are scoped) in RDFa without a strong need to do so.

Some might remember that we do this elsewhere in RDFa where the value of
@base is preserved in the RDFa Processor when detected in the HEAD
element. We did that because we were attempting to express HTML's
implied semantics in the triples that are generated. However, I would
argue that the @token proposal is different because we don't have a
precedent set by HTML and are thus inventing a new mechanism. Ideally,
the new mechanism should try to follow rules that we have already
defined (processing RDFa attributes in a scoped manner), if possible,
instead of inventing new ones (modifying whether or not @token is scoped
or not depending on how it's included in the authors document).

> I said 'If' because, I must admit, I find the argument of, I think,
> Martin and Toby, saying that all information should be local to the RDFa
> file more and more compelling...

I'll explain in a further e-mail why I think that the default prefix
proposal is addressing a slightly different use case than the RDFa
Profiles (RDFa vocabulary proposal/@token proposal) work.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
Received on Sunday, 21 March 2010 15:52:32 UTC

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