[sc34wg3] Re: Re: [sc34wg3] Illustrating SIDPs

[sc34wg3@isotopicmaps.org]

Robert Barta <rho@bigpond.net.au> schrieb am 07.05.2004, 15:07:13:
> On Tue, May 04, 2004 at 02:30:03PM -0400, Patrick Durusau wrote:
> > "Oh, I can distinguish between people who have the same name by means
> > of their spouses.  If they have different spouses, even if they have
> > the same name, they must be different persons."
> ...
> >     * Property name:              "personID"
> > 
> >     * Value type:                 complex:
> >                                      "name"   : string
> >                                      "spouse" : topic
> > 
> >     * SIDP or OP?:                SIDP
> 
> > There is only one SIDP per topic (per TMA). (note that personName was
> > replaced by personalID)
> > 
> > SIDPs (and, for that matter, OPs) can be arbitrarily complex.
> 
> Patrick,
> 
> I agree with (almost) everything you say here, but I think my
> conclusions are quite different from yours.
> 
> As I read the TMRM document(s), I understand the objective to provide
> a framework to define these TMAs. What I am missing, though, is a
> notation to formalize this properly.

As you say, the RM provides a *framework* and thus it explicitly does
not provide a notation for TMA definitions. A TMA definition syntax
is somewhat bound to a the technological environment in which the
Topic Maps Paradigm is deployed at a given time. So, given the
current situation that we deploy Topic Maps to an SGML/XML/WWW
based world it makes sense to have some coupling between these
technologies
and a TMA def. syntax (e.g. retrievability of TMAs via HTTP). It makes
no sense to couple the RM itself with these technologies. That's why
the TMA def. syntax is not part of the RM.

> 
> I think that the whole concept of an 'identifier' is rather misleading
> (not only in TM universe, I mean in general): as long as you have such
> an identifier at hand for your topic maps everything is neat and nice.
> In general, though, the concept of identity is an inferred one, coming
> - as you also say - from a combination of values, or - more
> abstractedly - being the result of an application-specific rule.

In order to serialize Topic Maps you need identifiers, but I think
itis more appropriate to call them 'keys' as in the relational
world.

> 
> If we assume a rule like "two persons should be regarded the same if
> they have the same email address", then this rule is actually nothing
> else as a function which computes an "identity value" out of the email
> address and the fact whether the object is of class 'person' or not.
> If two (or more) objects have then same function result, then they are
> identical _for this very application_. Technically speaking, the
> objects are all in the same equivalence class as induced by the
> function.


Yes....and?

> [ This is how deductive databases work in general: They have explicit
> knowledge (facts) together with identity and they have implicit
> knowledge as provided by the inference rules. ]
> 
> My conclusion now for TMs is that
> 
>   - such rules are simply part of the ontology which characterizes an
>     application. One (or more) of such identity-inducing rules might
>     exist in a single application.

Sure. And an 'ontology which characterizes an application' is nothing
else than a TMA.

> 
>   - it would be an overkill to put such a formalism into TMRM to
>     express this.  Why not burden TMCL with the ability to express
>     such rules?

Sure. TMCL (however it might look) is conceptually a part of a TMA
definition language.

> 
>   - TMRM could then be simplified in that it merely captures the "nature
>     of TMs", making the association concept explicity as it already does.

The essence of the RM is 'how to define TMAs' there is no point in
taking that out.

What exactly do you try to achieve with that proposal?

Jan


> This is roughly my argumentation line I had in Amsterdam.
> 
> \rho
> 
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
-- 
Jan Algermissen                <algermissen@acm.org>
Consultant & Programmer

http://www.topicmapping.com
http://www.gooseworks.org