W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2007

Re: Understanding 'chaining'

From: Ivan Herman <ivan@w3.org>
Date: Wed, 28 Nov 2007 09:54:23 +0100
Message-ID: <474D2CBF.7070602@w3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>
Just a quick note here, to clarify the issue(s) form my understanding.

As Ben emphasized in his mail, Mark's model means a change of the
process model as we have it even _without_ the instanceof issue. We have
to keep this in mind. My proposal was actually twofold: I would propose
to stick to the model we have in the current document _and_ the
@trel/@trev change (I do not care about those names, by the way, if you
find better ones, I am all for it!:-)


Manu Sporny wrote:
> Ivan Herman wrote:
>> Well, why don't we take the exact analogy and define _two_ shorthands
>> for typing. Bye bye @instanceof, let us have two of these instead; for
>> the time being I call them @trel and @trev (we can have happy discussion
>> for the right name). The semantics is
> This approach certainly is a welcome addition to resolving this
> deadlock... as it feels that we aren't really moving forward with the
> current proposals.
> The core of the issue still is that we are arguing two different
> approaches (Ben's and Mark's) that are largely based on authoring
> preference. Both are logical approaches, each with their drawbacks,
> given that everybody agrees with each respective mental model. However,
> each mental model seems to be assuming too much, which is why it seems
> as if we are going in circles (at least, to yours truly).
> Here are a couple of brief thoughts on Ivan's proposal:
> - This makes specifying the type an explicit action on behalf of the
>   user and thus there shouldn't be any sort of confusion on what the
>   author intended. This is a problem with both Ben and Mark's proposals.
> - This approach seems to unify both Ben and Mark's models.
> - Attempting to name this concept, while it might be a bit premature,
>   might lead to further understanding of what we're talking about.
> At the moment, we use the following attributes:
> @about, @instanceof, @rel/@rev, @property, @resource, @href, @src,
> @content, and @datatype
> Of those, only @rel/@rev provide any sort of explicit bi-directional
> relationship specification. If I understand Ivan correctly, his approach
> would add a mechanism to explicitly specify the type of the @rel and
> @rev. I'm going to call it @reltype and @revtype (sorry Ivan, I didn't
> like @trel/@trev :). Personally, I'd be very happy if we stopped using
> the term @instanceof :).
> If I understand all of the current positions, both Ben AND Mark's
> processing rules would change to the following if we were to adopt
> Ivan's proposal:
> 1) @about		[set the subject]
> 2) @rel 		[set one or more predicates]
> 3) @rev			[set one or more reverse predicates]
> 4) @reltype             [set type of the predicate's subject]
> 5) @revtype             [set type of the reverse predicate's subject]
> 6) @property 		[set one or more literal-object predicates]
> 7) @resource/@href/@src	[set object for @rel, subj for @rev]
> 8) @content		[set object for @property]
> 9) @datatype		[set datatype of object for @property]
> 10) The URI object becomes the CHAINING NODE, which becomes the
>     inherited subject for all contained elements.
> The above is quite clean and easier to understand from a publishers
> viewpoint than the current proposals.
> In addition, the current APPROVED test cases could all be changed where
> @instanceof is changed to @reltype, since Ben's @instanceof and the
> current processing rules is synonymous with @reltype from Ivan's proposal.
> Did I understand all of that correctly, Ivan?
> -- manu


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

Received on Wednesday, 28 November 2007 12:37:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:25 UTC