[sc34wg3] draft Reference Model

[Steven R. Newcomb]

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

> Hi Michel, SteveN,
> 
> I read the draft and I am delighted by its simplicity
> and power.

We're very glad that you feel this way about it.
Simplicity and power are the goals, here.

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

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

> 	Maybe someone with graph theory background
> 	(Bernard are you listening?) could help here.

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

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.

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 miss a longer explanation of the built-in
> 	assertion type "assertionPattern-role-rolePlayerConstraints".

> 	I found only two sentences. No example. 

You're right; the paper is deficient in this respect.
A bigger explanation and a relevant diagram are coming
soon.

> 	As I understand it, it is the constraint how an
> 	assertion (instance) of a certain assertion type
> 	has to look like: means which roles are possible
> 	and which role player are allowed.

> 	I doubt that the current definition (those two
> 	sentences) is substantial enough to explain
> 	something DAML+OIL spends pages on.

> 	Anyhow: It is my strong opinion that a constraining
> 	mechanism does *not* belong into the RM. It has to
> 	go into TMCL.

I agree with what you're saying 100%.

> 	SAM assertions we should do this in the standard text
> 	but we should not try to put this in the RM. On the 
> 	one hand it just makes RM unnecessary complicated 
> 	and on the other hand it does not fulfill the
> 	real requirements for constraining.

Agreed.  See my answer to your last remark, below.

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

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.

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.

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.  The Reference Model
could provide an "assertionPattern-role" assertion
pattern for this purpose.  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.

The assertionPattern-role-rolePlayerConstraints
assertion pattern needs to be in the Reference Model in
order to standardize the connection between an
assertion pattern, its role topics, and its
rolePlayerConstraint topics.  Requiring that instances
of this assertion pattern be used to establish the
roles and role player constraints of assertion patterns
does not constrain validation in any way.  It doesn't
constrain the nature of constraints, or how constraints
are expressed, or how they are combined.  Any number of
instances of any Application-defined assertion types
can be involved.

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).  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.  The draft Reference Model simply provides
a convenient, sensible, and standard place for such a
topic to be found, with what we believe to be the
minimum overhead while preserving the maximum
flexibility for Applications.

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