[sc34wg3] N0391-0394: New SAM/XTM documents
Fri, 18 Apr 2003 09:06:29 -0400
Robert Barta wrote:
>On Thu, Apr 17, 2003 at 01:25:19PM -0400, Patrick Durusau wrote:
>>>Does TMM have a formalism for 'subsumption' and 'schema reasoning
>>>consistency'? Does it support reasoning (validation, not proof) at
>>>all? What complexity does the underlying logic have? Is it PSPACE?
>>>Without a minimal support of validation of schemas and theory behind
>>>query engines,RDF/OWL is a too strong competitor, especially in the US
>>>market, I would assume.
>>The TMM supports the building of TMAs, which is where you would find
>>support for 'subsumption' and 'schema reasoning consistence.'
>Sure. But why there?
I was briefly tempted to give the answer to the typical high school
psychology exam question: Why? which is: Why not? ;-) I think your
response illustrates a different understanding of the role of N393
(honoring Jim's plan to avoid names for what will probably become parts
of one unified standard, I hope so, see my post on reading the roadmap.)
>This is a perfectly valid while arbitrary
>decision. If my goal would be to create a generic infrastructure for
>Topic Map based information and I plan, of course, to allow queries
>against the infrastructure, then my choices might be (and will be)
Question: In what way would you choose differently, based on your
current understanding of N393 vs. N396?
Building a generic infrastructure for Topic Map based information
implies to me that you intend to follow some basic principles for that
infrastructure. Principles that would underlie any generic
infrastructure for Topic Maps. The goal of N393 was to enunciate those
principles in a way (the syntax that appears to have been mistaken for
yet another TM syntax) that would allow transparent declaration of the
infrastructure that you are seeking. In other words, I could look at the
declaration you have made, the TMA, and know how your infrastructure in
particular is operating on the more generic concepts of topic maps.
>Let's make an example: We develop an abstract, relational database
>model. As abstraction we first choose tables, so all the data is in a
>tabular form. This, by itself is worthless if we do not define (a)
>update and (b) retrieval functionality. It is actually (a) and (b)
>which convey the semantics of the data structure. The fact that these
>are tables with bells and whistles is completely irrelevant from a
>conceptual point of view.
Sorry, need to know a little more about how you are using "semantics of
the data structure." In my use of "semantics" I could certainly define
the "meaning" of data in a location in the table, the "key" field for
example, without resorting to update or retrieval functionality. Note
that I don't think the data has to be present or how it becomes present
in the table before I can declare its meaning.
(We may be seriously missing each other here, as is common in
discussions of semantics and syntax. If so, let's try again.)
>This is why RDBMS are based on "relation algebra" (or, more recent on
>the relational calculus). They define the operations. They constrain
>the abstract data type.
Hmmm, I would agree that relational calculus defines operations (I read
that as expressions) but that may or may not be semantics. You could be
using relational calculus to define valid expressions, which I take to
by a syntax issue. Does not say what the expression means (semantics)
but rather that it has the proper form (syntax).
>>say a bit more about what would be required to support either of those?
>Phew, that is no easy question. I actually completely lack the vision
>how resoning (again in the sense of semantic web) can be imposed
>aposteriori to TMM or SAM. I know that SAM was not built for it. And I
>assume the same for TMM. That's exactly my point.
Over the last several years of watching some of the development of topic
maps, I don't think there are any easy question. ;-) The easier case
would be an example of reasoning that cannot be imposed aposteriori on
the SAM (N396).
As I noted in my first post and above, the TMM (N393) was never intended
to build the framework you are seeking but to lay down the rules for
building such an infrastructure. It defines the semantics of topic maps
and provides a syntax that allows conversation with great precision
about those semantics.
For the TMM (N393) you would have to be saying that it does not allow
the construction of the infrastructure you are seeking. In order to
evaluate or respond to that statement, it would be necessary to know
what sort of infrastructure you are seeking to build. Hard to say in the
absence of an example of requirements whether a particular approach is
too much, too little or just right. Caveat: I understand that it is not
possible to state the full case in email exchange but even the smallest
portion of an example would get us a little further down the road.
>>>We have the big advantage as the 'second-comer'. Let's not throw this
>>Glad to hear we have a "big advantage" but not sure from your post what
>>that is or how to capitalize on it. Can you say a few more words about this?
>I also got the (possibly wrong) impression that we can profit a lot
>from the RDF efforts and from the noise they make in the SW arena. It
>is not always good to be the first in a market. You have to do things
>step-by-step. A second-comer (Microsoft is famous for that policy)
>can clean things up. Maybe.
Sounds like a plan to me!
Hope you are having a great day!
Director of Research and Development
Society of Biblical Literature
Co-Editor, ISO Reference Model for Topic Maps