[sc34wg3] revised draft Reference Model document N0298

[Steven R. Newcomb]

"Graham Moore" <gdm@empolis.co.uk> writes:

> 1. The scope issue I raised the other day - I see no
> scope no the basic model and accept that its a SAM
> based thing which I would like to see us define in
> terms of assocs on assocs.

That was our thinking, too.  Before we took them out of
the draft Reference Model, there were two assertion
types:

(1) "set-member" 

    The node that plays the "set" role is some set of
    subjects.  The node that plays the "member" role is
    a subject that is declared to be a member of the
    set.  The subject of the "set" role player is
    impacted by each "set-member" assertion in which it
    plays the "set" role: the subject is always the set
    of subjects that play the "member" roles in all
    such "set-member" assertions.

    We were thinking that "set-member" assertions is
    useful whenever a set of things plays a single role
    in any type of assertion, not just for
    "assertion-scope" assertions.

(2) "assertion-scope"

    The node that plays the "assertion" role must be an
    A-node -- its subject must be an assertion.  The
    subject of the node that plays the "scope" role
    must be a set of subjects.

> 2. I think that it is necessary to define node types
> as well as arc types. These would be association,
> topic and assocrole. The assocrole is - always - the
> one where we cant get agreement. I see that node as
> something tangible in the model - in any formalism -
> set theory etc I think that node would exist in some
> explicit fashion.

OK, I see how, in the dRM, your "association" node is
an A-node, and how your "assocrole" node is a C-node.

The dRM also recognizes the "semantic lift" nodes as
distinct node types: the R-node (which we may end up
calling "role" or "role type"), and the P-node (which
we may call "assertion type" or something else).

And then there's the "it-doesn't-matter-what" node
type, which the dRM calls "x", intending to imply that
role players are unrestrictedly variable with respect
to their subjects and node types.

> here is an extract from the abstract set based and
> FOL notation for the reference model that I'm trying
> to get completed (i.e. a formal view on what Steve
> and Michel present) - i'm fed up with powerpoint
> descriptions of something so formal: Please excuse
> the notation - i'm still trying to find the exact
> expressiveness.

COOL!

> 	Some node/ property definitions/ set relations
> 
> 	ASSOC    :=  (TYPE x MEMBER*)
> 	MEMBER   :=  (RPT x RDT)
> 	TOPIC    :=  (IDENTITY*)
> 	IDENTITY :=  (VALUE x isRes x isVal x isSubInd) 
> 	
> 	TYPE E TOPICS
> 	TOPIC E TOPICS
> 	RPT E TOPICS
> 	RDT E TOPICS
> 	VALUE E STRINGS
> 	
> 	Some instances:
> 
> 	roleplayingtopic, rtopic E TOPIC
> 	m E Member
> 
> 	Some basic rules:
> 
> 	playsRole(roleplayingtopic , roledefiningtopic) := 
> 			hasRolePlayingTopic(m, roleplayingtopic) /\
> 			hasRoleDefiningTopic(m, roledefiningtopic)

> 	Please note that it was 'm' was required in
> 	order to define this rule in a rigerous
> 	fashion.

I'm baffled.  I gather that 

":=" means "is comprised of"
"*" means "0 or more"

...but I'm unable to parse the rest.

> 	ok, I would really like to see nodes named and
> 	the rcognition that this member node really
> 	exists. I would imagine that even in a formal
> 	definition of hypergraphs that there is an
> 	explicit node used to express it.

Still lost.

> 3. I think this is my big concern: seperating out the
> node from the thing that identifies it? And losing
> the distinction between the different types of
> values.

What is a "value" and how are the distinctions between
types of values lost in the draft Reference Model?
(Maybe I understand more below; maybe not.)

> Using the subject indicator as an assoc type seems
> weird. I think that the identity properties of the
> Topic should be indicated clearly as first class
> parts of the model. In the model, as presented, if I
> have a name of 'foo' and an subject indicator of
> 'foo' then those two topics will merge even though
> the use of those two 'strings' have different
> meaning.

I don't think so, but maybe I'm not understanding you.

> The new model fails to express this...

> 	TOPIC    :=  (IDENTITY*)
> 	IDENTITY :=  (VALUE x isRes x isVal x isSubjInd)

> Which basically says that a Topic is comprised of a
> set of identities. Each identity has a value. That
> value is either a

>       - referenceToAResovableResource (resource ref)
>       - a piece of data (name string)
>       - a subject indicator (specifically some URI
>         etc - which isnt the topic but indicates the
>         nature of the topic)

> When I merge I should merge names that are the same,
> subj refs that are the same and res refs that are the
> same.

The dRM isn't concerned about the mechanisms whereby
pieces of addressable information become direct
properties of the nodes whose subjects are those pieces
of addressable information.  Any referencing mechanisms
involved in making those properties work are hidden
from the Reference Model's view.  They're just
properties, the values of which are the pieces of
addressable information, right where they sit in their
own contexts.

(Of course, an Application can take the position that
addressing expressions themselves are subjects, and
such addressable subjects are subject indicators for
other addressable subjects.  As far as I know, the
Standard Application hasn't articulated its position on
this issue.  But at some level, ultimately, it all has
to be founded on a direct connection to some piece of
addressable information, regardless of whether that
piece of information is a URI, or something that a URI
points at.)

Theoretically, at least, merging occurs because two
topics share a single subject.  If the subject is
nonaddressable, that's hard for computers to do.  So,
in order to facilitate merging, we encourage topics
that have the same subject to have the same subject
indicator.  That's the real basis of merging.  But, we
can gain a lot of efficiency if we *also* encourage a
situation to exist in which topics *refer* to their
subject indicators by uttering addressing expressions
(such as URIs) that are always the same for any given
subject indicator.  That way, we only have to compare
the strings of the addressing expressions.  It's a
hack, but it works well.  But we must not lose sight of
the fact that the real binding point is what's being
referenced; it's not the content of the referencing
expression.

So, I'm bothered when you say we should merge
references (resourceRefs or subjectRefs).  We should
merge *on the basis* of references, possibly *using the
simplifying heuristic* that identical references can be
assumed to reference identical binding points in order
to optimize the efficiency of our merging process.

About merging names that are the same: did you see my
recent long note in response to Holger's question about
merging literals?

> In addition the merging rules talk about merging the
> 'string' that is the identity - it should talk about
> merging the topic that is identified by this
> value.

That's what I was talking about in my recent note.

> I'm DEEPLY concerned by having identities not
> being first class properties of topics in the
> model. Attached is a small gif of the reference model
> where ID hasnt been abused.

I didn't get the gif.


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