Re: Issues with @token scoping and hidden-data

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.

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

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.

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.

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.

*If* we go for a @profile file line I still believe that #1 is a clean
approach (with details to be sorted out of course)

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...

Ivan


On 2010-3-19 23:08 , Manu Sporny wrote:
> There were two issues that came to light during the discussion last
> Thursday during the telecon... documenting them here to see if any
> solutions or alternative viewpoints pop up.
> 
> So with the current @token proposal, it is asserted that the following
> will happen:
> 
> * @token declarations, when specified in RDFa Profile documents, will be
>   pulled into author documents via @profile.
> * @token declarations are processed differently in RDFa Profile
>   documents than they are in regular documents.
> 
> Here are the concerns with the previous points:
> 
> 1. Are we promoting the use of hidden data in RDFa Profile documents?
> Specifically, if one must do this to have their @token declarations seen
> via @profile:
> 
> <html token="Person: http://xmlns.com/foaf/0.1/Person; name:
> http://xmlns.com/foaf/0.1/name; depiction:
> http://xmlns.com/foaf/0.1/depiction;">
> ...
> </html>
> 
> Is that a good thing? Hidden data is commonly viewed as an anti-pattern
> in the semantics-embedded-in-HTML world - we do it only if there is no
> other alternative available.
> 
> 2. Are we comfortable with @token not following the standard
> all-RDFa-attributes-are-scoped design pattern that has served us well up
> to this point? So, if the RDFa Profile document contains something like
> this:
> 
> <html>
> ...
> <body>
>    <p token="Person: http://xmlns.com/foaf/0.1/Person">
>    You can use "Person" in the typeof attribute to specify that
>    the subject is a human being.
>    </p>
> ...
> </body>
> </html>
> 
> If we want to allow that markup, which one could argue is more desirable
> than the markup outlined in #1, it would mean that we must view @token
> as scope-less when processed as a part of an RDFa Profile. It's an
> exception that makes understanding RDFa slightly more complicated. Not a
> deal-killer by any means, but it's concerning none-the-less.
> 
> -- manu
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf

Attachments

Received on Saturday, 20 March 2010 10:01:18 UTC