[sc34wg3] revised draft Reference Model document N0298

[Martin Bryan]

Steve

When I wrote

> > ...Concepts should be "definitions that allow one to
> > determine whether or not the labels of a topic can
> > legitimately be applied to a particular object."

you responded

> Now, if that's right, and if your patience with me has
> not been completely exhausted, all you need to do is to
> explain what you mean by "labels of a topic", "object",
> and "legitimately", and maybe I'll understand you!
>
> * Are the "labels of a topic" its names?  Are they the
>   senses of other kinds of assertions in which it plays
>   roles?

They are its names (note the multiple, as per Roma & Rome, Londres et
London)

(I have no idea what your second sentence means I'm afraid)

> * Is an "object" an addressable subject?  A
>   nonaddressable subject?  A node?  An arc?  An
>   assertion?  An XML element?

I would presume, though I am not sure, that there is some form of node that
represents the concept, as you need a node to which to assert the various
labels are its names. Whether it is addressable or not depends on the
definition of address. If you mean "does it have a unique point on a unique
computer that uniquely identifies it" then I doubt it. If you mean "does
some computer somewhere have something that can be pointed to as identifying
it" then it is addressable. (The post office will tell you you cannot
address a state or a city!)

Whether it has already been expressed as an XML element does not concern me:
it is represented electronically as an identifiable SGML element that may or
may not conform to the rules of the XML subset of SGML.

> > > A *relationship type* whose instances are relationships
> > > between published things, on the one hand, and
> > > publishers, on the other, is absolutely not the same
> > > thing as the *role* played by publishers in such
> > > relationships, even if we describe or name both of them
> > > using the same words.
>
> > I agree, but this was not the distiction I was
> > making.
>
> > The distinction was between the internal
> > "relationship type" that exists because there is an
> > association between an ISO13250 topic element that
> > identifies a particular edition of a particular
> > publication and an ISO13250 topic element that
> > identifies a particular publishing organization
> > (e.g. the relationship between the ISO13250 standard
> > itself and ISO and/or IEC) and that between the
> > "role" of an information occurrence within a
> > particular ISO13250 topic element and an externally
> > identified organization that happened to have the
> > same relationship as the association, but which
> > cannot be expressed as such without creating a new
> > ISO13250 topic element which, for some reason, the
> > author of the map does not wish to do.
>
> I'm having trouble parsing the above huge sentence.
> Either there's an error in it, or there's some sort of
> bug in my brain's English parser.

The bug is in the English parser:-)
I was trying to be very very precise.
Lets try to be very very concise.

Let A = an ISO13250 topic element that identifies a particular edition of  a
particular publication
Let B = an ISO13250 topic element that identifies a particular publishing
organization
Let C = a publishing organization that is not represented as a topic within
the topic map but which does have a reference point that can be expressed as
a valid HyTime or XML link
[Example: A = the ISO 13250 standard, B = ISO and/or IEC, C = Coolheads Inc)
Let Q be the internally expressed "relationship type" that exists between A
and B (as expressed by the type attribute defining the association role
type, as far as I can gather from the dRM model)
Let R be the role played by an occurrence element that provides a link from
A to C (as expressed by the type attribute defining the occurrence role
type)
According to my reading of your rules R and Q cannot be the same because Q
is what you term an assertion-type and R is what you term a role descibing
the casting of an assertion.
Yet in ISO13250 terms the same topic element could serve both purposes.


> I begin to suspect that, throughout this confusing
> conversation, you've been saying "role" and thinking
> "occurrence role", while I've been seeing "role" and
> thinking "role type".

I don't understand how you restrict the meaning of "role type". What I mean
by role are the things called role types in ISO 13250, viz "occurrence role
type" and  "association role type". I presume that things such as
association type, topic type and facet type, which are not defined as roles
directly, cannot be defined using the role defined in the dRM. The
occurrence role defined by the GI of an occurrence by default should not be
confused with the topic that defines the occurrence role type as specified
in the type attribute. (Though if there is no specified occurrence role type
the occurrence role name is used to identify the occurrence role in place of
the names associated with the occurrence role type topic.)

> I think we'd better start with an example of a HyTM
> <topic> and identify all the subjects in it.  Having
> done that, we can decide what "types" they are.  There
> is more than one taxonomy of topic types that can be
> brought to bear, here, so it's not very helpful to say
> that they are (or are not) of different types.
>
> <person
>  HyTM=topic
>  id=abeLincoln
>  identity=abeLincolnSI>
>   <topname>
>     <basename scope="foo">Abraham Lincoln</basename>
>   </topname>
>   <biography
>    scope=bar
>    type=unauthorizedBiography>
>     <idloc>abeBio</idloc>
>   </biography>
> </person>
>
> The above is a HyTM <topic> element (HyTM=topic) whose
> generic identifier indicates its topic type (person).
> Its subject indicator is the element whose unique
> identifier is "abeLincolnSI".  It has a basename
> "Abraham Lincoln" in the scope of "foo".  It has an
> occurrence which is the element whose unique identifier
> is "abeBio", in the scope of "bar".  (Please take my
> word for all this; some of the HyTime incantations that
> make all these things true are not shown above.)
>
> Here is a list of dRM-level subjects that are directly
> demanded by the above HyTM <topic> element:
>
>  #0. A specific human individual commonly known as
>      "Abraham Lincoln".  This is the subject of the
>      <topic> element.
>
>  #1. The topic type of human individuals.

This does not appear to be defined in the example, though it could be by
adding a topic type attribute to the topic element, e.g. types="human". (NB
GIs used for topic names do not provide default values for defining the type
of the element, as they do with occurrences: they only define linktypes. It
is clearly stated in ISO13250 that "Neither the value of the linktype
attribute nor the generic identiier of a topic has any significance with
respect to the topic mapping semantics defined by this International
Standard." I fail, therefore, to see how you can make a node based on a
topic type derived in some way from the GI of the topic element.)

>  #2. The name "person".

This is solely a linktype name in ISO13250. I'm not sure how linktypes get
represented in the dRM. Are link types assertion types, as would seem to be
implied by your #3?
>
>  #3. The assertion that #2 is a name of #1.

This derivation is far from obvious, as the above comments show.
>
>  #4. The addressable subject that is the subject
>      indicator for the subject of the <topic> element.
>      It is the piece of information referenced by the
>      string, "abeLincolnSI".
>
>  #5. The assertion that #3 is a subject indicator of
>      #0.

I take it you mean #4 rather than #3. (If you meant #3 then I am totally
confused!)

>  #6. The name "Abraham Lincoln".  (Note: this is *not*
>      the string "Abraham Lincoln" as it appears in the
>      above example; if it were, it would be an
>      addressable subject.  Subject #6 is
>      nonaddressable; it is the name "Abraham Lincoln"
>      in the abstract sense; it is the name that is
>      meant by *any* copy of that string, anywhere.  In
>      this list of subjects, I'm not bothering to use
>      the appearances of names in the example as subject
>      indicators for those names.  There is no need to
>      do that if they already have subject indicators
>      located elsewhere, and I'm assuming that they do.)
>
>  #7. The assertion that #6 is a name of #0.
>
>  #8. The subject of the topic that is referenced by the
>      string "foo".
>
>  #9. The set of subjects that has #8 as its only
>      member.
>
> #10. The assertion that #8 is a member of #9.

I can see no purpose in making this assertion
>
> #11. The assertion that #9 is the scope of #7.
>
> #12. The occurrence type of unauthorized biography.
>      (In dRM terms, this is an assertion type.)

There is no such thing as an occurrence type in ISO 13250 . Do you mean
occurrence role type? If so why is this an assertion type and not a role
type? If you mean that the occurrence role name somehow serves as an
assertion type name can you please explain where the role of the occurrence
node is defined.

> #13. The name "biography".
>
> #14. The assertion that #13 is a name of #12.

This assertion confirms that the GI is the value of the occrl attribute as
no specific value has been specified.
>
> #15. The name "unauthorizedBiography".
>
> #16. The assertion that #15 is a name of #12.

This is incorrect. The assertion should be that #15 is the unique identifier
of the topic that defines the names to be associated with #12. (The type
attribute is a HyTime reference.) You need at least two more levels of
indirection here.
>
> #17. The addressable subject that is the occurrence of
>      an unauthorized biography.  It is the piece of
>      information referenced by the string, "abeBio".
>
> #18. The assertion that #17 is an unauthorized
>      biography occurrence of $0.
>
> #19. The subject of the topic that is referenced by the
>      string "bar".

> #20. The set of subjects that has #19 as its only
>      member.
>
> #21. The assertion that #19 is a member of #20.

Again I cannot see the purpose of this being a formalized assertion.
>
> #22. The assertion that #20 is the scope of #18.

There seems to be a stage missing here. I think you also need to have a link
between the scope attribute and scopes of the names associated with the
element identified by the type attribute.

> #23. The assertion that #0 is an instance of #1.
>      (Sorry, this one should have appeared earlier in
>      this list.)

So far I cannnot buy your model. You need to show me where the roles come
in, and how ones determines what are assertion types and what are roles. At
present I am thoroughly confused.

Martin