[sc34wg3] Enlightenment

[Lars Marius Garshol]

Steve's statements earlier about the simplicity of the PMTM4 core
model made me think, because I never felt that it was simple at all.
I sat down to look at it, and suddenly two ideas that I'd been having
about PMTM4 met, and there was light.

These ideas are just half-baked at the moment, but it would be
interesting to get some feedback on them. I think there really is
something here.


--- Simplifiying the model

I think you can unify all four arc types into a single arc type that
has these slots:

  - primary end: this is the node being characterized by the arc

  - secondary end: this is the node that characterizes the primary
    node 

  - label slot: this is the node that characterizes the relationship
    between the secondary and primary nodes

Association member arcs now become arcs where the association end is
the primary end, the member end the secondary end, and the label is
the label slot as it was before.

Association scope arcs now become arcs where the association end is
the primary end, the scope end the secondary end, and the label is the
topic whose subject is the "association scope arc type".

Association template arcs now become arcs where the association end is
the primary end, the template end the secondary end, and the label is
the topic whose subject is the "association template arc type".

Scope component arcs now become arcs where the scope end is the
primary end, the component end the secondary end, and the label is the
topic whose subject is the "scope component arc type".

This leaves us with a single arc type, where the primary end can be an
a-node or an s-node, the secondary end can be an a-node, a t-node, or
an s-node, and the label slot always contains a t-node.

This is a little messy, because s-nodes get mixed in with the
t/a-nodes, and there are two ways to solve this:

  - split out association scope and scope component arcs again, and
    have three arc types

  - get rid of s-nodes

As it is now, an association is scoped by connecting it with an s-node
that is further connected with the scope components that make up the
scope. S-nodes can be removed simply by having the association scope
arc go directly from the association being scoped to the scope
component, rather than going via an s-node. If we choose this solution
we no longer need the "subject component arc type" topic, and arcs of
the "association scope arc type" now have a-nodes in the primary end,
and a-nodes or t-nodes in the secondary end.

This leaves us with two node types and a single arc type, where the
primary end is always an a-node, the secondary end always a t-node,
and the label slot always holds a t-node.


--- RDF

After this reduction the model becomes very similar to RDF, because
the arcs now follow the same (subject, predicate, object) model that
RDF has. The differences are:

  - resources (nodes) can only have other resources (nodes) as
    property values

  - resources have a more complex structure, and there are two kinds
    of them

  - resources are always associations, while the objects are always
    either associations or "real" resources

Given this, the PMTM4 core model ends up looking like RDF done right,
while the 'Standard Application' might be the mapping between RDF and
topic maps.

The main difference is the way the triples are used; that is, the
primacy given to associations instead of their endpoints.


--- Infoset

The interesting thing is that this modified PMTM4 core model is
actually equivalent to the infoset approach. An arc in the modified
PMTM4 core model is a property value assignment to an item, where the
item having the property is the node in the primary end, the property
is the label, and the property value is the node in the secondary end.
When nodes are allowed to have several arcs of the same type the
properties become set properties.

There are two item types in this model: a-node, and t-node. T-nodes
have no properties, while a-nodes have one property for each public
subject used to define a label.

The core model can be said to have two properties: template and scope.
This leaves us with a problem in handling "association member",
because the label there is variable. The best way to solve this may be
to introduce another item type called r-node with two properties:
player and role.  In that case, the a-nodes have three properties in
the core model: template, scope, and roles.

--Lars M.