[sc34wg3] Re: Going beyond SIPs?
Steven R. Newcomb
sc34wg3@isotopicmaps.org
06 Sep 2004 16:31:43 -0400
Robert Barta <rho@bigpond.net.au> writes:
> On Fri, Sep 03, 2004 at 10:05:03AM -0400, Steven R. Newcomb wrote:
> > Robert Barta <rho@bigpond.net.au> writes:
> > > But I can top it. Now I would like to identify as equal all persons
> > > who are involved in more than 5 associations of type "knows". Slightly
> > > bizarre, but possible. Or what about "all persons with the same
> > > distance from G.W. Bush should be regarded equal" (not sure how
> > > bizarre that is).
> > >=20
> > > In these cases there is no property involved.
>=20
> > But the last example, too, is completely amenable to this approach.
> > ..... In this example, each of the "knows" associations triggers the
> > operation of a conferral rule that confers a value component on each
> > of the SIPs of each of its role players.
> That's exactly what I find unnecessary and actually rather
> un-topicmappish:
> First someone builds a map concentrating on relationships, because
> it is them, which carry most of the "meaning" for us humans. The
> topics are as boring as bookmarks (if we ignore for a second the
> "exciting" task to connect them with the reality). Then someone
> else comes along and says "yes, I know that all your relationships
> are completely unbiased, but now I pull some topics out of this map
> and dogmatically say 'one is now a property of the other'".
That's not the same scenario I was talking about. You are positing
"someone else" who is deliberately mis-determining the meaning of what
the original asserter asserted. Of course, it's always possible for a
person to take the statements of another person and characterize their
significance in ways that the original asserter would not recognize.
(Indeed, at a time when I'm frequently observing the disingenuous
statements of U.S. politicians with my mouth literally hanging open
in shock and dismay, such a scenario seems all too commonplace!)
But that scenario is not relevant to the question of how to make it
*possible* for the person who asserted the relationships in the first
place to be sure that those assertions at least *can* be understood in
exactly the way he intended them to be understood. Whether someone
else *chooses* to understand them in that way, or in some other way,
is another problem entirely -- a problem I hope we're not attempting
to solve.
In the scenario I was talking about, the person who asserted the
relationships knew all along what the implications of asserting them
would be. Those implications, including the conferral rules, were
comprehensively disclosed by the TMA. If the person who asserted the
relationships didn't want those implications, he should have made
assertions that were governed by a different TMA. If he didn't like
any of the TMAs available to him, because none of them allowed him to
say exactly what he meant, with the exact implications that he
intended, he should have created a TMA whose conferral rules and other
implications were exactly the ones he wanted.
> The strange thing with this exercise is that this only happens to
> "create these properties for the sake of being combined and then
> compared", just to figure out whether two topics are now the same or
> not. Maybe these 'conferred properties' are just thrown away, after
> they have served their purpose. What is the benefit (for me, for
> the formalism, ...) that I have to make two steps instead of just
> one?
You seem to be saying that, in topic maps, there is something more
important than "figuring out whether two topics have the same
subject". I'd be interested to know what that more important thing
might be. What, for you, are topic maps all about? For me, topic
maps have always been about facilitating the collation of information
around subjects. Thus, for me at least, in topic maps there is
nothing more important than discovering whether two assertions are
being made about the same subject.
There are several benefits in making the subject identity properties
of subject proxies explicit. I mentioned one of them in my last note:
facilitating users' ability to point the finger of blame. (If I had
to say the same thing in one word, that word would be "auditability".)
Another benefit of making SIPs explicit is that such explicitness
makes it possible for subject proxies to appear simultaneously in
multiple "semantic coordinate spaces" (or, to use the philosophical
lingo that I find most intuitive, but which seems to make most people
cringe: multiple "universes of discourse"). It wouldn't be easy for
the semantic address "Q" to be understood in terms of another *kind*
of semantic address (an instance of which, for example, might be
semantic address "orange") if the mapping function that is supposed to
map "Q" to "orange" must first understand and duplicate the entire
process whereby address "Q" came into existence. It is relatively
easy, however, if all that the mapping function has to know is that
the semantic address is "Q". It's easier because, in that case, all
that the mapping function has to know is a way to understand "Q" as
"orange". (Which may or may not be easy, but at least it's
significantly easier than having *also* to know how to make "Q" come
into existence as an implication of various assertions made in some
universe of discourse.)
Let me put the benefit in another way: If we require that the values
of subject proxies are always explicit, then TMAs can be modular.
There doesn't have to be one monolithic TMA. The Topic Maps paradigm
becomes applicable to maps of all kinds of universes of discourse.
Aside: Personally, I think the modularity of TMAs will turn out to
be essential for the success of topic maps, for the same
reason that it has been essential for the success of XML that
XML documents don't all have to conform to one monolithic
Document Type.
(But if we're comparing XML with Topic Maps, it's important
to recognize a big difference between the two paradigms. XML
does not directly facilitate the collation of information
about subjects of conversation, whereas the Topic Maps
paradigm does (or at least is supposed to). In other words,
it has never been important for XML documents to provide
explicit information about how they identify the subjects
that they're talking about, but topic maps really *must*
provide such information if, as has always been claimed,
independently-created topic maps will merge meaningfully (or
at least predictably).)
> Unless TMRM frees itself from this ambivalence "sometimes I only
> look at the assertions, sometimes at the properties" it will not be
> a minimal model. \tau is minimal in this sense. Only assertions,
> topics are reduced to - infinitesimal small - points.
> For me this sounds as if there are two layers, amalgated into one:
> The lower layer, TMRM-A of completely neutral assertions. They only
> connect things, but do not have any bias, what is the "object" and
> what is the "property".
TMRM has a two-layer vision, too. Properties are the low level layer;
properties aren't objects, but they are what objects consist of. (If
we're willing to call "subject proxies" "objects".)
> And there is the second (OO) layer, TMRM-O which blesses some things
> to be more equal than the others by making them objects. Here you
> can declare existing connections as properties or even define
> derived (conferred?) properties which are combinations of other
> properties.
Sounds good to me, Robert. I can see how a TMRM "property instance"
might be modeled as a \tau "assertion". Am I getting your point, or
missing it?
> > In TMRM-land, an "Application" governs a "topic map view". It
> > does *not* govern any [... uh, phooey, I can't use the term
> > "information resource" the way I used to any more. Hmmm. Let's
> > try this:] A TMA does *not* govern any representations of
> > information resources. It only governs *explicit understandings
> > of representations of information resources* (here, "explicit
> > understandings" are sets of subject proxies). This means that we
> > can have different *understandings* (i.e., different topic map
> > views [TMVs]) of the same representation of a given information
> > resource, and that those different TMVs can be governed by
> > different TMAs.
> I have to use a Rorschach method to guess what this could mean. I
> could imagine that this means that someone is looking at a
> 'information resource', say, an Excel sheet about bank accounts,
> with TMRM-A glasses on. The only things which are visible are the
> connections between the things and with - more or less - certain
> identification of proxy with the real world. Theoretically, a
> programmer could sit down and write an API which wraps the Excel
> sheet and offers an "assertion-only" view to the surrounding
> application(s).
> This is the "bare bones view" of the resource, pretty boring and
> unsophisticated.
In TMRM terms, I would say it's one of very large number of perfectly
reasonable ways of viewing the resource. It's a TMV, as far as I'm
concerned. (Let's call it the "bare-bones TMA".)
> Now the bank manager wants to have the information interpreted in a
> particular way. He wants to see "customers" (with names and
> addresses), "bank accounts" (with balances and numbers). And some
> information should be completely ignored. Is this what you call a
> TMV?
In TMRM-land, it's just another TMV, governed by a more complex and
semantically more-specific TMA. This more-specific TMA can be built
on top of (it can "include") the "bare-bones" TMA.
However, in TMRM-land, *every* TMA is fundamentally a set of property
classes, and both the "bank-manager" and "bare-bones" TMAs must be
disclosed as such. Therefore, we could say that, fundamentally, the
"bank-manager" TMA decomposes into a set of connection types. (Which
I guess is what you're saying...?) In the latter case, there is no
"bare-bones" TMA, and there are only two levels of abstraction: (1)
the connection types, (2) the "bank-manager" TMA that is expressed in
terms of those connection types. Or, we could say that there is a
"bare-bones" TMA, and that the "bare-bones" TMA decomposes into a set
of connection types (as all TMAs ultimately must), but the
"bank-manager" TMA is built on top of (or "is derived from" if you
prefer) the bare-bones TMA. In this scenario, there are *three*
levels of abstraction: (1) the connection types, (2) the "bare-bones"
TMA, and (3) the "bank-manager" TMA. In TMRM-land, both scenarios are
supportable. Either way, everything ultimately boils down to a set of
connection types (property classes) and the things that they connect
(subject proxies and data).
> If so, then there only needs to be a language to map a TMRM-A
> instance into a TMRM-O instance. Piece of cake. Maybe ...
Don't we also have to say something about the connection types that
are needed? If there is only one kind of low-level connection, then
how do we distinguish between the connections available from a given,
uh, object?=20=20
> > (For this discussion, let's call such rules "Topic Map View
> > Construction Rules" (TMVCRs).)
>=20
> ...this could be its name. Sounds scary enough to me!
Touch=E9. I'm cursed with a propensity to create names that scare
people. But, so far at least, I have resisted the temptation to use
Greek letters as names. (I'm not sure which approach is scarier,
actually. (;^)
> > An additional but important detail: If the two TMVs are governed
> > by different TMAs, then, obviously, the rules used to understand
> > the representation of the information resource must also be
> > different, because they produce subject proxies that have
> > different properties.
>=20
> Accordingly, we would have two different instances of TMRM-O, but
> only one TMRM-A. You would need two of these mappings then, yes.
I think we're approaching an understanding.
> > It's also possible, however, for two different sets of TMVCRs,
> > both of which produce TMVs that are governed by the same TMA, and
> > both of which know how to handle the same kind of representation
> > of an information resource, to produce different TMVs, even though
> > both TMVs are governed by the same TMA and both TMVs were created
> > from the same representation of an information resource.
>=20
> Mumble. :-)
I'm not sure how to interpret or respond to your reaction, here. I
suspect you're too polite to point out that my prose is completely
incomprehensible.
> > So there are several things here that we need to distinguish
> > among, if we're going to understand each other:
> >=20
> > (1) A representation of an information resource (which may or may
> > not be represented in a syntax that we call a "topic map syntax"
> > -- in the TMRM, that distinction doesn't matter).
>=20
> In my framework this would be the Excel sheet. Does not look like a
> TM, but certainly can be "thought that way". This is still _outside_
> the TM framework.
Outside. Yes.
> > (2) An understanding of a representation of an information
> > resource (a "topic map view" -- TMV -- a set of subject proxies).
>=20
> In my 'framework' this would be the a representation of a resource
> in form of assertions only. No bias here, just the facts. Like the
> neurons in a brain.
Good. (Well... it's not really "facts". Facts are unattainable.
Assertions of presumed facts, yes. Facts, no.)
> In the Excel sheet example above this would be captured by a
> "low-level ontology". That simply says, we have these roles and
> these association types and everything has to be this and that way.
This is where I get confused about what you are saying. Here's why:=20
* On the one hand, at the lowest level, you say there's nothing but
connections.
* On the other hand, you say that at the lowest level there are roles.
I don't understand how these can exist at that level, except as
things whose existence is independent of the existence of individual
connections.
> \tau path expressions (or something which is derived from them)
> should be able to do that. Let us call this ontology level OA
> (Ontology for assertions).
Here I know I'm completely lost. I thought I had a glimmer of
understanding as to what a \tau path expression was, but the above
statement persuades me that I don't have a clue, really. How can a
\tau path expression be used to define or declare an assertion type?
> > (3) The schema and rules that govern the TMV -- the kinds of
> > properties that the TMV's subject proxies have, its conferral
> > rules etc. -- a "Topic Map Application (TMA)".
>=20
> OK, this is just another "description how your data looks like",
> i.e. another ontology. Let us call it 'level OO' (Ontology for
> Objectified view).
>=20
> > (4) The rules under which a representation of an information
> > resource is understood as a TMV -- the Topic Map View
> > Construction Rules (TMVCRs). Every such set of rules is
> > necessarily TMA-specific, but TMAs are not TMVCR-specific.
> > I.e., there is no limit on the number of sets of TMVCRs that
> > can be used to understand different (or even the same) kinds
> > of representations of information resources as TMVs governed
> > by exactly the same TMA.
>=20
> Then the rules are simply (!, well) a mapping between OA and OO. If
> you are curious how this works, then have a look at
>=20
> http://ausweb.scu.edu.au/aw03/papers/barta2/paper.html
>=20
> There I have mapped literature references (according to one
> ontology) into a more object-oriented ontology for BibTeX. This also
> was the motivation for me to argue that TMQL has an "transformation
> component" between topicmappish data.
>=20
> > ............In an effort to move things forward, I propose to try
> > to avoid using the unqualified term "topic map" in our
> > conversation. If by "topic map" I mean "a representation of an
> > information resource that is in XTM notation", I'll try to
> > remember to use the term "representation of an information
> > resource" instead of "topic map". If by "topic map" I mean the
> > information that a topic map document presumably conveys, I'll try
> > to remember to use the term "topic map view".
>=20
> In my framework, I do not need to distinguish between the two. An
> "XTM File" is at the same level like the Excel sheet above. Yes,
> maybe the work to be done with an XTM file is less, but both are
> resources, have a syntax and can be interpreted as containing
> topicmappish data.
You and I apparently agree that any information can be seen as a topic
map. Good, that helps a lot, because I think we can then agree that
modularity is a design requirement at all levels.
*** SIDE-ISSUE DISCUSSION BELOW: ASSERTION REIFICATION ***
I have a remark about a side-issue raised by your paper,
http://ausweb.scu.edu.au/aw03/papers/barta2/paper.html, which says:
---
Worth noting it is, that associations themselves cannot take part
directly in other associations. To allow to make statements about
statements we first have to reify a statement with a new topic. That
can then play an association role:
(covers-theme) is-reified-by statement-1
document : ltm-spec
theme : topic-maps
(claim)
contender : p-lars-marius-garshol
claim : statement-1
Using this technique any levels of meta information can be compiled.
---
If Topic Map A contains an unreified assertion Alpha, and Topic Map B
contains an assertion about assertion Alpha (and, in order to do so,
it reifies assertion Alpha), then the result of merging Topic Map A
with Topic Map B cannot accurately reflect both A and B; there is no
way to avoid some sort of consistency problem, in which the users of
at least one of the the original topic maps will find that the merged
result is not consistent with one or more of the originals. Such
outcomes are highly undesirable, and they are quite likely to destroy
the credibility of the topic maps paradigm as a general tool for
creating master indexes from independently-created indexes.
At the level of pure logic, the Topic Maps paradigm can either:
(1) require that reification policies are ontological commitments, or
(2) accept that the result of merging independently-created topic maps
may be inconsistent with any or all of the topic maps that were
merged. (Yech!)
The TMRM's attitude is that relationships between subjects should be
viewed as being exactly as reified as the TMA(s) that govern the views
say that they are, no more and no less. In other words, whatever the
TMA (i.e., the ontology) says is reified, is reified, and whatever the
TMA doesn't say is reified, isn't reified -- at least as far as that
TMA is concerned.
Is the post-facto "reification" of assertions that your paper proposes
possible under a TMA that has been disclosed in accordance with the
TMRM's disclosure requirements? Well, no and yes:
* No, because reification policy is an ontological commitment under
the TMRM. Period. It's not possible for the paradigm to provide a
basis for deterministic viewing if it does not provide a foundation
that requires deterministic reification. We can't collate
information around subjects if we're not sure which subjects to
collate information around.
* Yes, because it is possible to define a TMA in which assertions are
always reified, but that declare (redundant) property classes that
allow the fact that all assertions are reified to be concealed by
implementations of that TMA. In this scenario, every role player
has redundant properties whose values are the other role players of
every assertion in which it participates. Implementations can then
create the illusion that the reifiers of assertions only become
visible to users when certain syntactic conditions exist in the
information resources to be viewed as topic maps, such as the
syntactic conditions that both TMDM and your above-quoted paper
propose.=20=20
(The TMRM doesn't impose any constraints on what implementations
of TMAs must or must not deliver to the users of topic maps that
are governed by those TMAs. The only constraints it imposes are
on what must be disclosed when a TMA is disclosed.)
The result of having implementations create the illusion that
assertions aren't always reified is that, once again, the users of
the original topic maps may be unpleasantly surprised by the
*appearance* of the merged result: the implemented result may
*appear* to be inconsistent with the *appearances* of the original
topic maps. Thus, the only difference is that, under the TMRM, any
apparent inconsistencies are the results of implementation policies,
rather than being symptomatic of an
information-integrity-compromising bug in the Topic Maps paradigm
itself. It's awfully important that the paradigm be bug-free.
(Note: it may be perfectly reasonable for implementations to
create the illusion that unremarked-upon assertions are not
reified. For example, it's quite possible that, for usability's
sake, users of at least some kinds of topic maps should not see
any assertions about which nobody has ever asserted anything.
Indeed, put that way, this particular illusion sounds like a
pretty good idea!)
*** SIDE-ISSUE DISCUSSION ENDS HERE ***
> Why make differences for things which are the same? Actually my
> software just uses different "drivers" for different data. If you
> say
>=20
> my $tm =3D new TM (tau =3D> 'file:map.xtm + file:map.atm');
>=20
> then it is the task of the selected drivers (XTM in the first place,
> and then AsTMa in the second) to _provide a TM view_. It also would
> work for an Excel sheet:
>=20
> my $tm =3D new TM (tau =3D> 'file:map.xtm + file:accounts.xls');
Good. We envision similar requirements. I vigorously applaud the
modularity of your vision! I hope we can persuade more people of the
overwhelming importance of such modularity.
> > I think we need to make a distinction between "constraints" that
> > are:
> >=20
> > (a) criteria of subject sameness detection that, when subject
> > sameness is detected, require subject proxies to be merged
> > (or, more precisely, to appear to have been merged), and
> >=20
> > (b) criteria of semantic, stylistic, etc. validity, such as=20
> > SteveP's exemplary constraint that the names of countries
> > must include at least one that is in the primary language of
> > the county.
> I cannot yet see, why this distinction must exist in the choice of
> the language to describe it. Yes, the distinction is there, what you
> want to achieve (teleologic distinction), but you would not use two
> different versions of, say, Java, only because you write two
> different applications.
Ah. You are right, of course.
My only objection to using TMCL for both is that it gives two very
different missions to the TMCL effort. Each of the two missions is
extremely important, quite independently of the other. Personally, I
feel that each of the two missions deserves the full attention of a
dedicated editorial team, and each should proceed without being hung
up by the problems and requirements encountered by the other. I don't
see why the two missions are necessarily inseparable, either. True,
both need a foundational metamodel for the properties of subject
proxies, on the basis of which subject proxies and their properties
can be addressed in an implementation-neutral fashion. The
credibility of our process and of our standard would suffer if we
attempted to promote multiple different metamodels for addressing.
(Aside: I'm thinking about some SGML history, dating from the early
1990's. A cautionary tale with lots of lessons for us, and
a happy outcome, too.)
> > We need to distinguish these two kinds of "constraints" because
> > one of them actually determines the shape of the TMV, while the
> > other only determines our attitude toward the TMV -- whether we
> > think the TMV (or, more likely, the source materials from which
> > the TMV was constructed) meets certain criteria of consistency,
> > etc.
> I would mean that "shape we want to see there" and "attitude we want
> to take" are too close to call. I would have to see a very good
> example why both should not be captured with an ontology.
Let me try again. (Maybe the distinction I'm trying to draw is too
obvious. I find that one of the most effective ways to create
confusion is to say something that's completely obvious and that
everybody already knows.)
(1) Ontologies constrain what's sayable, and they state the
implications -- for the "shape of the view" -- of saying it.
(2) On the other hand, it's quite possible, in many topic maps, for
conflicting assertions to be made, and it's not the ontology's
business to prevent that from happening. On the contrary: the
ontology's business is normally to make sure that it's possible
for that to happen! It's normally also possible (and necessary)
for a topic map to be able to contain incomplete information. The
detection of conflicts and incompletenesses are the proper
business of something other than an ontology language.=20=20
SteveP's memorable example of a constraint statement makes no
ontological commitments (it assumes plenty of them, but it makes
none): "The names of countries should include at least one whose
language is the principal language of the country." This "constraint
statement" is a query with the added semantic that, if there are any
results (any countries whose sets of names don't include one that's in
the country's principal language), the topic map is considered not to
have met the declared constraint.
This constraint statement is only meaningful in terms of an ontology
that allows for proxies whose subjects are countries, for those
proxies to have names and principal languages, and for the names to
have language properties. But all that happens elsewhere -- wherever
the ontology is declared. SteveP's constraint statement is something
quite different; it's not constraining or allowing things to be said,
and it doesn't have any impact on the view. It's only detecting and
reporting on specific combinations of things said in the view. The
only thing that SteveP's kind of constraint impacts is our attitude
toward the view: whether we regard the topic map as valid, invalid,
complete, incomplete, consistent, inconsistent, etc.
> > > My view is that this is a "constraint": It says "if I had my way,
> > > then no two topics in a map exist which have a sufficiently
> > > congruent geographic range".
> >=20
> > You always get to have your way; there's no "if" about it. All you
> > need to do is to make either the TMA, or the TMVCRs, or both, be such
> > that the TMV is the way you want it to be.
>=20
> Yes, this is exactly how I meant it.
I think that's ontological, then, and I guess you do, too. It affects
the shape of the view.=20=20
But I think that saying "No two topics exist which have a sufficiently
congruent geographic range" doesn't say how the ontological constraint
is supposed to be achieved. If our standard is going to be
meaningful, it must allow us to view representations of information
resources as topic maps in a *deterministic* way, so that, given the
same resource, and the same rules, the same topic map results. I
therefore would prefer a statement more like the following: "Whenever
two topics have a sufficiently congruent geographic range, they merge,
and the result of their merger is a topic that exhibits the union of
their geographic ranges as its geographic range." (Or something like
that -- something that makes the operation of viewing deterministic
and implementation-neutral, anyway.)
> > > (b) what must TM software do to make this constraint TRUE, i.e.
> > > change the map in such a way that it does not violate the
> > > constraint?
> > >=20
> > > For (b), the answer seems easy: The software must remove all
> > > situations which would conflict with the constraint. It will detect
> > > the topics and will - without further control - merge them into
> > > one. (A query/transformation language could actually put more control
> > > on how the 'merged' map looks like)
> >=20
> > Wait. Please be patient with me, Robert; I'm having more
> > communications problems here.
> >=20
> > Before we can transform something in any rigorously deterministic way,
> > we must first understand its existence in a rigorous way. Until we
> > know, with comprehensive explicitness, exactly what we're
> > transforming, we are not in a position to be explicit about any
> > transformation processes, or about the results of any such process.
>=20
> Perfectly correct. Let's have a diagram (hopefully it will not be
> messed up in transit):
> Level | Data Stack App1 | Data Stack App2 "is-describ=
ed-by" Ontology Stack
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> | |
> ----------------+-----------------------+--------------------------------=
--- -------------------------
> TMRM-O | think that as objects | think that as objects =
OO_1 and OO_2
> | for bank manager | for internal review people
> ----------------+-----------------------+--------------------------------=
--- -------------------------
> TMRM-A | assertions only =
OA
> |
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> Resource Level | Excel Sheet =
[ syntax by microsoft,
> =
data by Excel clerk ]
> At the resource level (outside the TM space) there is the
> resource. Just inside the TM space someone described this resource
> via a OA: without any bias like what is a property and what is an
> object. That is all done in the OO layer.
Are you saying that you want the core model to provide a limited
repertoire of property types, which you call "assertions"? Is it your
vision that these property types are then used to assemble objects in
various ways? If so, that's a very interesting approach!
As I think about it, though, it seems *not* to be what you're
proposing, because I don't see how such a "lower level" can represent
any particular knowledge, or be a view of anything in particular.
(Well, I don't yet get it, I guess. I know you're trying to answer my
question, and you probably think you've answered it, but I haven't
understood the answer yet.)
> If so someone wants to transform data from the OA level into OO_1,
> then - as I assume both are described using a computer interpretable
> language - a transformation can be done. It can actually be done in
> one or in some cases also in both directions. The latter you need
> when you deal with resources which are not read-only.
What's the point of requiring this transformation? If we have to
"see" an information resource as a bunch of assertions, and then
"transform" that into an OO view, isn't that just an extra step? Why
isn't it more "minimal" just to "see" the information resource as an
OO view directly?
> --
>=20
> What does this now mean? I think it means that we should keep it
> architecturally simple:
>=20
> - adopt the concept of "data is governed by an ontology"
> - this the same as for XML: there is data and there are
> schemas
I like this, but I think you put it too simply. There's also the
possibility that the same data can be viewed through multiple
ontologies. Also, at your lowest "assertions-only" level, the same
data can be seen as multiple different sets of assertions, given a
different set of rules.
> - define an appropriate ontology language which
> - allows us to define "sameness" (or reciprocally
> "distinction")
Aside about sameness vs. distinction:
"Distinction" is not possible unless you're willing to forego the
possibility that "sameness of subject" will be detected under other
ontologies, for the same subject proxies that are also governed by
your ontology. You can certainly forego that possibility, but it
necessarily excludes the views that it governs from being merged
with views that are governed by other ontologies. You need to be
aware that the views governed by the other ontologies will
collectively form a mainstream from which the views governed by your
ontology will exclude themselves.
Personally, I'm more interested in ontologies that define sameness
of subject without also insisting that any subjects that they don't
explicitly merge must necessarily be distinct. I'm interested in
merging independently-created topic maps, with independent
ontologies. I find the idea of a de-facto mainstream of ontologies
that can work together much more intriguing than a bunch of
uncooperative ontologies whose views cannot be merged without
violating their integrity.
> - allows us to define what the structure of a map is
> - equivalent: how an application could "talk" to the map
> - can be object-focussed, but does not need to be (if it
> helps, why not?)
What else could it be? I'm baffled by your assertions-only level,
frankly. Aren't the role players there, too? Is an assertion *not*
an object? Why isn't it?
> - unlike in XML: one schema language rules all
Good luck. We can only control the one(s) that we choose to
standardize. If we really succeed in this endeavor, we are not going
to be able to control the profusion of languages, any more than the
SGML standard can prevent YASSL (yet another SGML schema language)
from appearing every alternate Thursday.
> - have a language to transform map
> - similar to XML: XSLT, but using _semantic transformations_
Are semantic transformations something other than data
transformations?
> Everything else follows from that. A "view" to a map is provided by
> either
>=20
> (a) a second ontology: then somehow it has to be figured out
> how a map should be translated (uni- or bi-directional), or
>=20
> (b) by a transformation mechanism itself: then the ontology follows
> from what this outputs.
>=20
> See http://ausweb.scu.edu.au/aw03/papers/barta2/mediate.gif .
Robert, I'm still not getting it, but I'm trying. I will be more
convinced that I understand what you're saying when I feel confident
that I understand exactly what's going on at your assertions-only
level:=20
* What the semantics of it are and aren't,=20
* Why you say it's minimal,=20
* What the benefits of such minimality are, and
* What was traded away in order to achieve that minimality (there's no
benefit without cost, I suppose).
-- Steve
Steven R. Newcomb, Consultant
Coolheads Consulting
Co-editor, Topic Maps International Standard (ISO 13250)
Co-drafter, Topic Maps Reference Model=20
(http://www.coolheads.com/SRNPUBS/ontolog040610)
srn@coolheads.com
http://www.coolheads.com
direct: +1 540 951 9773
main: +1 540 951 9774
fax: +1 540 951 9775
208 Highview Drive
Blacksburg, Virginia 24060 USA