[sc34wg3] draft Reference Model

[Steven R. Newcomb]

"H. Holger Rath" <holger.rath@empolis.com> writes:

[SteveN]
> > arcs do not provide traversal services, and it would be
> > misleading for us to imply that they do, by saying that
> > they are "bidirectional".

> OK. I see they are not first class objects, they are
> 'just' pointers (in the sense of a programming
> language) wihtout an own ID and as such not
> addressable (was this your intension?).  But - and
> this is important - a single "arc" is visible at both
> ends - which is a kind of "double pointer" in a
> programming language.

Right.  For example, it takes 2 RDF arcs to make 1 arc
in the draft Reference Model.  Which is very good
reason to call a Topic Map arc an "edge" instead of an
"arc".  It's the negative marketing implications of the
term "edge" that worry me.  In ordinary conversation,
an "edge" is a boundary between two things, and it is
never a nondirectional connection between its
endpoints.  For non-mathematicians, it's techno-babble.

> > As a marketing principle, it's always better to make
> > people think they understand something we're trying to
> > sell them, even if they don't really understand it
> > immediately.  
> 
> But it depends on our target audience which term is known.
> Naming is always the first step towards good marketing
> so naming is crucial - but I accept to stay with "arc"
> for the moment until everything is technically ready.
> Then we can talk about naming again - having the whole
> RM in front of us. I assume SteveP has also some comments
> on naming ;-)

Right.  (It's going to be an interesting meeting in
Barcelona.)

[snip]
> > The draft Reference Model has very little to do with
> > logic.  It's really about semantic addressing.  The
> > draft Reference Model is nothing more or less than a
> > neutral envelope for both logical and illogical
> > ontologies.  It doesn't even have a class-instance
> > assertion type.
> 
> I agree. I mentioned mathematics as the formalism we
> could use to *precisely* define our model. If we are
> able to built it on top of e.g. first order logic or
> Z or whatever seems appropriate, we have built it on 
> top of a theoretical foundation, which is understood and
> respected. It is just for the sake of argumentation
> and marketing.

I think we agree about this.

By the way, did you see John Sowa's remarks, forwarded
by Jack Park, about Common Logic?  I have no agenda
here, but it does look like a lot of good work, already
done, that maybe we could take some benefit from,
and/or represent as published subjects.

[snip]
> > > If the RM really needs to constrain some of its
> > > built-in assertion types (and it seems that there
> > > will be only two predefined ones) then this should
> > > also be done by the formalism and not by a construct
> > > which is part of the model. It should be *outside*
> > > the model.
> > 
> > Here I must disagree with you.  If things are outside
> > the model, 

> When I wrote 'outside the model' I meant outside of
> the RM but in higher application layers. These higher
> layers (e.g. TMCL) might provide more complex
> assertion types for constraining.  These assertion
> types will finally make use of the RM and everything
> will be kept in the topic map model. As you postulate
> below.

OK, we are in agreement.

> NB: I and others are not absolutely convinced if we
> should built the TMCL data model completely on top of
> RM. There might be some procedural stuff in TMCL
> which does not really belong into the TM.  But that
> has to be discussed at an other thread - when TMCL
> starts off again.

I don't see how the necessity of describing/requiring
specific processing causes any conflicts, here.  The
definition of an assertion type can specify that its
instances, by their existence, demand that certain
kinds of processing be done.  For example, the
name-based merging rule is a merging process that is
one aspect of the definition of what PMTM4 calls the
"topic-basename" assertion type.

[snip]
> > The subject of the topic that appears at the P end of
> > an AP arc is the assertion type.  That subject is
> > impacted by playing the "assertionPattern" role in any
> > "assertionPattern-role-rolePlayerConstraints"
> > assertion.  By playing that role in an assertion of
> > that type, it becomes an "assertion pattern", as well
> > as an assertion type.

> I am still confused: are assertion type and assertion
> pattern just synonyms for the same concept or are
> they different concepts?  But see my text at the end
> of this email.

> I assume the latter - otherwise you would not have
> introduced two names here - but I still did not get
> the difference. Sorry.

In the lexicon we're proposing for the draft Reference
Model, the set of all "assertion types" is a proper
superset of the set of all "assertion patterns".  All
assertion patterns are assertion types.  Not all
assertion types are assertion patterns.  An assertion
type is *also* an assertion pattern if and only if it
has been asserted to have one or more roles.

Of course, if we get rid of the
"assertionPattern-role-rolePlayerConstraints" assertion
type altogether (which I still hope we won't do), we
won't need to use the term "assertion pattern" at all.

[snip]

> Above, I pointed out why I feel that RM does not meet
> the reqs.  But I might be wrong - because of lack of
> my English, sorry.

Holger, you are much too modest.  I wish my native
English-speaking neighbors could handle English even
half as smoothly as you do.  And I have almost no
German at all.  You put me to shame.

OK, let me argue your side:

  N0269 didn't say what the design implications of
  topic map self-description were going to turn out to
  be in the first draft Reference Model.  We can't
  expect everybody to say, "Oh, cool!"  when they see
  how those implications were handled in the draft.

Personally, I'd hate to surrender the requirement that
topic maps be capable of self-description, even across
Applications.  But maybe there's simply no way to save
this particular self-description feature.  I hated
taking scope out of the draft Reference Model, but
there was nothing to be done about that, either.  The
scoping assertions simply didn't belong there.  You are
saying that the
"assertionPattern-role-rolePlayerConstraints" assertion
type must also be removed, and for the same reasons
that we removed the assertion types required to support
the scoping facility.

Patrick Durusau suggests that maybe it can remain in
the Reference Model, but be informative, rather than
normative.  Does that approach work for you?

> > So far, all I really understand is that you
> > don't want a universal mechanism that allows patterning
> > information to be found in any topic map, regardless of
> > Application.  I don't know *why* you want to prohibit
> > the existence of such a mechanism, or what harm it
> > might cause, or how it might conflict with other
> > requirements, or what those conflicting requirements
> > are.
> 
> I am still not sure if I understand the *real* purpose of
> assertion pattern. Let me try to descibe how I understand 
> the draft RM (please read the complete text before commenting
> on details, everything is related and therefore needs 
> 'two parse' phases):
> 
> An assertion consists of three 'layers': 
> - instance, 
> - type, 
> - pattern.
> 
> One assertion 'instance' consists of: 
> - one assertion A-node,
> - one AT arc connecting the A-node with the assertion type 
>   T-node (I have invented the T-node and AT arc just to make 
>   my points clearer),
> - the role players X-nodes,
> - the casting C-nodes,
> - the CX arcs connecting the X- and C-nodes,
> - the AC arcs connecting the A-node with the C-nodes
> - for every C-node a role R-node,
> - the CR arcs connecting the C- and R-nodes.

Yes.

> One assertion 'type' consists of:
> - one type T-node,
> - as many AT arcs to A-nodes as this T-node is the type of
>   (I have added this here to show that you can get from the
>   T-node to the A-nodes, just to make the bi-directioness
>   of our arcs visible).

Yes.

> One assertion 'pattern' consists of:
> - one pattern P-node (being also an A-node),
> - one AT arc connecting the A-node with the
>   built-in assertion type assertionPattern-role-rolePlayerConstraints,
> - X-nodes representing the roles this pattern has, these X-nodes
>   are the R-nodes of the instances of this pattern,
> - the according C-nodes, CX arcs, and AC arcs,
> - but what are the R-nodes, are they also built-in?
> - where to put the sets of constraints on players of the
>   roles and how do these constraints look like?

This is pretty interesting, but it's not what we're
proposing for the draft Reference Model.  Please take a
look at the diagram we added to the revised N0298,
which is now posted (see my other note) at the
Coolheads secure website.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA