[sc34wg3] draft Reference Model

[H. Holger Rath]

"Steven R. Newcomb" wrote:
...snip...
> > 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.

Yes, I did. And I raised the issue if SC34 WG3 should establish
a liaison. Will be on the agenda for Barcelona.

> [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.

OK. Good definition. But This has to be visible (explained)
in the RM, please. Otherwise everybody will be confused as
I was. 

When I follow you wording precisely it means for me that 
the AP arc should be an AT arc as long as the type node has 
been asserted to have one or more roles. And a P-node should
be a T-node for the same reason. And AT arc becomes AP arc and
T-node becomes P-node in that very moment when we add that
the type/pattern has asserted roles.

I suggest that -- if we stay with pattern -- we have to cover
this issue somehow, to make the difference and relationship
very clear. Esp. for processing of the model.
 
> [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.  

Thank you!

> And I have almost no
> German at all.  You put me to shame.

Well, English is the lingua franca in IT and probably in a lot
of other domains as well. So it is perfectly excused that you
(and all other native English speakers) are a little bit
'lazy' in this point :-)
 
> 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?

Even I argue against the assertion patterns in the RM
I am still open to be convinced that it is necessary.
I am thinking black-or-white here: means either it is
in the RM (for good reasons) or it is not in (for good
reasons). It is our job as a standards committee to
discuss the pros and cons and to come to a conclusion.

Finding all arguments pro and cons is the purpose behind 
this thread.
 
> > > 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.

The next text and diagram explained every thing very good!
I am still not convinced, but would like to learn more about
the pattern.

How would the diagram look like when we would define that the
second role of the "medical qualification" assertion type/pattern
is "MD degree holder" with the RPC "Person"? It would be a 
second assertion of type assertionPattern-role-rolePlayerConstraints,
right?

If it works like this I think I fully understand it now.
I looks that the patterm could be the foundation for TMCL
(or other kinds of application specific constraining). Maybe
SteveP should approve if the work done on TMCL so far (e.g.,
the Ontopia Schema Language) could be put on top of this.

Here are my "conditions" to be fulfiled before I agree
that the assertion pattern should be in the RM:

- We have to approve that assertion patterns are the *foundation*
of constraining.

- We have to make it very clear in the text - and you did a 
great step in that direction already - that this *is the foundation
of constraining* as regular RM assertions *are the foundation
of ontologies* but they are not constraints and do not want
to compete with constraining languages.

- We have to elaborate the difference between assertion type
and pattern and make it clear when a node is a type or a
pattern and make our text as well as examples consistent to
this definition. Might be that we have to introduce AT arcs
and T-node as superclasses (in OO sense) of the AP arcs and
P-node respectively.

- We have to find a solution for the RM->SAM->TMCL issue (see below).

This means that one real question remains open. How do we pass the pattern
approach from RM through SAM to TMCL. I just don't know
if Lars Marius and Graham (want to) cover with this issue.

NB: Was a pleasure to discuss this thread with you!

Regards,
--Holger