Re: Understanding 'chaining'

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!:-)

Ivan

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