Re: Understanding 'chaining'

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

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Over One Million Songs Available on Bitmunk
http://blog.digitalbazaar.com/2007/10/29/one-million-songs-on-bitmunk/

Received on Tuesday, 27 November 2007 19:46:43 UTC