[sc34wg3] draft Reference Model

[H. Holger Rath]

"Steven R. Newcomb" wrote:
> ...snip...
>
> > Some comments:
> >
> > -     You use the term "arc" but you do not explain
> >       (at least I have not found it) if the connection
> >       between the two nodes (the arc) has a direction
> >       (as an RDF triple has) or not.
> 
> No direction.  Or, rather, both directions at once.

Good.
 
> >       I assume it does not have a direction. If this
> >       is the case I would name it "edge" and not "arc"
> >       because (at IMHO) arc implies a direction.
> 
> I'd sure like to know who we're going to confuse or
> alienate by using the term "arc", versus who we're
> going to confuse or alienate by using "edge".  I have
> seldom seen the term "edge" used except by
> mathematicians.  "Arc" is a word that is vaguely
> understood by most people who have taken first-year
> computer science courses, and by everyone who has a
> passing familiarity with RDF.

And that's the reason why I am concerned. If people
hear "arc" and they know RDF arcs they might think the
TM RM arcs are directed as RDF arcs are.
 
> > -     I don't find any information where in the RM
> >       some literals (= value) are stored. The graphics
> >       show some bubbles with names in them but it is
> >       not explained in the text what this is and where
> >       is goes.
> 
> The draft Reference Model regards literals as subject
> constituters and subject indicators.  It does not treat
> literals in any exceptional way.

OK. But when I understand your merging rules (see below) right
this automatically forces merging of every topic that has the
same 'literal'. I don't see the escape door where to put arbitrary
values in SAM (e.g., the number 2002 - which could be this year or could
be something completely different). Background of my thinking:
where to put the values of resourceData occurrences in the SAM
without triggering name-based-merging?
 
> For example, when the SAM describes, in Reference Model
> terms, its handling of basename literals, it might say
> that an addressable basename literal is a subject
> indicator of a specific name, and that that name
> (considered abstractly) is itself a subject.  The topic
> whose subject is the name can have any copy of the name
> literal as one of its possible subject indicators.

And that makes the definition of named-based merging in SAM
quite easy. Nice but dangerous (see above).
 
> A similar question arises with addressing expressions,
> such as URLs.  As I see it, there are at least two
> positions that the SAM could take about them:
> 
> (1) Addressing expressions are themselves topics, and
>     they are subject indicators for the topics whose
>     subjects are the pieces of addressed information.
> 
>     Lots of overhead here.  How often does anybody
>     really need to make assertions about addressing
>     expressions?  On the occasions when they need to do
>     that, how terrible would it be if they couldn't?
> 
> (2) Addressing expressions are not topics.  They are
>     part of the implementation-specific hidden magic
>     that makes addressable subjects (pieces of
>     information) direct properties of the topics that
>     correspond to those addressable subjects.
> 
> The SAM has to decide how to handle this.

I know (from our experience in k42) that making the resources
(= addressed objects, or the link end of the address) part of
the model could make live much easier (e.g., for TMQL). So
I would go with (1).
 
> > -     I assume that you will add some text about how merging
> >       has to be done in detail. Similar to annex F in XTM spec.
> 
> Annex F is mostly concerned with SAM-specific assertion
> types. These don't appear in the Reference Model, so
> there's nothing to be said about them in the Reference
> Model.

Yes of course. What I meant was to copy the writing style of annex F
(with having two maps before and one map after merging), because
it makes everything crystal clear.

> Merging rules are pretty simple in the Reference Model:
> 
> (1) Topics merge if they have any subject indicator in
>     common.
> 
> (2) Topics merge if they have the same addressable subject.
> 
> (3) Assertions merge if they have:
> 
>     (a) the same role players playing the same roles, AND
> 
>     (b) the same assertion type.

Very good that you defined merging of assertions (assocs).
This was always an open point.

> That's just about all that the Reference Model has to
> say about merging, but Applications are free to add
> more rules, based on the assertion types they provide,
> that impact the merging process.
> 
> > -     What does "assertion validation" assigned to SAM means in
> >       first figure?
> 
> It's intended to mean that the Reference Model doesn't
> say anything about validation.
> 
> Validation is something that can only be done in the
> context of an Application.  Only Applications can
> define what validation is all about, and they can only
> do it for themselves.  They can't do it for each other.
> As far as we can see, there can never be a single
> universal approach to the problem of validation, so it
> would be self-defeating for us to legislate any single
> approach in the Reference Model.

OK.
 
> All assertions have roles, and specific roles are the
> most basic features of any assertion pattern. It's
> good and necessary to provide a standard way to
> determine, from the perspective of an assertion pattern
> topic, what roles it provides.  

I agree that it is good and necessary.

> The Reference Model
> could provide an "assertionPattern-role" assertion
> pattern for this purpose.  

I - vehemently - disagree that this has to be provided 
by the RM. 

> But, having done that much,
> it would be negligent to fail to provide an optional
> way to specify and to discover what the role player
> constraints are, too.  That's why, instead of providing
> an "assertionPattern-role" assertion pattern, the draft
> Reference Model provides an
> "assertionPattern-role-rolePlayerConstraints" assertion
> pattern.

This shouldn't be in the RM either.
 
> The assertionPattern-role-rolePlayerConstraints
> assertion pattern 

I am confused here. The document says that it is a built-in
assertion *type*???

> needs to be in the Reference Model in
> order to standardize the connection between an
> assertion pattern, its role topics, and its
> rolePlayerConstraint topics.  

May I misunderstood the purpose of the 
assertionPattern-role-rolePlayerConstraints? Let me ask two simple
questions which hopefully make the two possibilities visible:

(1) Is the purpose of the assertionPattern-role-rolePlayerConstraints
to define *how* assertion pattern, its roles, and role players
*are connected* in the model?

(2) Is the purpose of the assertionPattern-role-rolePlayerConstraints
to define *what* roles and role players *are allowed* to be connected
with assertions of a certain type?

If the intention is (1) my comment is: assertionPattern-role-rolePlayerConstraints
is a possible approach but when RM is defined in a formal way (with use of
some mathematics e.g., Z notation) I assume the formalism will provide better feature
to describe this.

If the intention is (2) my comment is: This is TMCL (!!!) and it does not
belong into the RM. 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) they 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. If it in the model it would unncessary confuse people (e.g., a
TM user may raise the question "what is this 
assertionPattern-role-rolePlayerConstraints doing and how does 
it relate to TMCL? what's the difference? what has precedence?" etc.)
and make it more complicated to sell.

Having said (written) this another questions comes into my mind:
Your diagrams only show assertion pattern connected to the assertion
by an AP arc. But where is the assertion type? I understood that
type and pattern are two different things. They are related because
the pattern describes (constrains) how an instance of such a type 
should look like but they are not the same. Am I right?

If I am right, then I would also argue that we don't need the concept
of the assertion pattern in the RM - just the concept of the assertion
type. For the same reasons I have already given and as the implication
of "if we don't have constrains in the RM then we don't need pattern'.

> Requiring that instances of this assertion pattern 

I assume you mean instances of 'this assertion type'?

> be used to establish the
> roles and role player constraints of assertion patterns
> does not constrain validation in any way.  

Whenever I read/hear/think about constraning or constraints
I think about validation. That's where constraints are about.
That's their purpose and reason of their existance (besides 
guided editing, but that's a kind of interactive validation).

> It doesn't
> constrain the nature of constraints, or how constraints
> are expressed, or how they are combined.  

Do you suggest that TMCL has to be built on top of
assertionPattern-role-rolePlayerConstraints?

If yes: I would say that this does not fit with our figure
how all TM standards are related. Because TMCL is build on top
of SAM and not on top of RM. And SAM will not (at least that's
my understanding) define any constraining mechanisms.

If your answer is no: I would ask "why is it in RM at all?"

> Any number of
> instances of any Application-defined assertion types
> can be involved.

I don't understand this. What do you want to say?
 
> Requiring the use of the
> assertionPattern-role-rolePlayerConstraints assertion
> pattern *does*, however, suggest that the combination
> of constraints that is applicable to players of a
> specific role _should be a topic_ (or, at least, that
> it *can* be a topic).  

When reading this I have the feeling that you that you
use assertionPattern-role-rolePlayerConstraints as described
in my question (1) (see above).

> However, even in this respect,
> the draft Reference Model doesn't constrain validation;
> it doesn't *require* it to be a topic; the
> rolePlayerConstraints role is not required to be
> played, so, in any given Application, there may be no
> such topics.  

This is hard to argue as long as we don't have a formal model
or at least more text describing what the RM want to require
and want not.

> The draft Reference Model simply provides
> a convenient, sensible, and standard place for such a
> topic 

What is "such a topic"? The pattern/type, the role, the
role player, or ???

> to be found, with what we believe to be the
> minimum overhead while preserving the maximum
> flexibility for Applications.

I assume we can easily figure out what should be in the RM
and what not when we have the requirements. Something Lars
Marius and others ask for for months. We did again the 2nd 
step before the first one. We are argueing about the model
without having an agreement on the requirements - which is
always a strange situation.

Regards,
--Holger

-- 
Dr. H. Holger Rath
- Director Research & Development -

empolis * GmbH
Bertelsmann MOHN Media Group
Technologiepark Pav. 17
97222 Rimpar, Germany

phone :  +49-172-66-90-427
fax   :  +49-9365-8062-250

<mailto:holger.rath@empolis.com>
http://www.empolis.com