[xtm-wg] XTM Requirements (Was RE: Is this valid per HyTime? - topicmapmai l thread)

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

This very interesting discussion that is going on in
topicmapmail@infoloom.com emphasises the need to develop the Requirements
document for XTM. I agree that this can be done in parallel with the work of
the Modeling Group, if that is deemed appropriate.

Eliot has said of HyTime that it was "not intended to be complete with
respect to knowledge
representation". Is XTM intended to be complete with respect to knowledge
representation? What do we mean by that? These are requirements-definition
issues.

My personal position is that "complete with respect to knowledge
representation" is an unachievable goal, since humans have not yet managed
to understand what knowledge is sufficiently clearly to know what it would
mean. However, the ability to express some of the semantics that are under
discussion in this and other recent threads, to do with classification,
subtyping, class-instance relationships, transitivity and symmetry of
relationships, etc, is important enough in my view to provide a useful set
of candidate requirements. We'd need to decide which of these candidate
requirements we include in the formal requirements for XTM. Then we'd need
to decide how they are met, and this could include meeting some in the
formal core model and others in public subjects.

Eric asks "Do public subjects have the same degree of enforceability as
something stated in the standard?" The answer is "Yes if they are stated in
the standard".

This rhetorical answer is not a joke. I suggested in the modeling group that
we could have a formal "core" model AND a set of public subjects in the
standard. I believe this is what the ISO WG is coming round to also. We
could also have a base syntax (which is a syntactic representation just of
the core model, so that users of the public subjects would make them
explicit using the core syntax) AND a fuller syntax in which the public
subjects get enshrined in special element types or attribute names. This is
already done in the ISO standard, where alternative syntaxes are provided
for certain constructs, with the express statement that they are
semantically equivalent. My suggestion would be that the base syntax provide
only one syntactic representation for each construct in the core model, but
that the  alternative syntax might provide more than one, with clear
mappings back to the core model plus public subjects.

Daniel


-----Original Message-----
From: Eric Freese [mailto:eric@isogen.com]
Sent: 26 June 2000 14:30
To: W. Eliot Kimber; topicmapmail@infoloom.com
Subject: RE: Is this valid per HyTime?


> HyTime defines essentially two types of association: "true"
> relationships and aggregation. In short, if you think you only have one
> anchor role, what you really have is aggregation. It's not clear to me
> from the above example that aggregation is really what Eric intended to
> express.

What I used as an example really does appear to be an aggregation, thus more
reflexive instead of symmetrical.  The semantic I wanted to attach was that
each member shares the association between each of the other members.

<assoc type="is-married-to">
  <assocrl type="spouse">eric rita</assocrl>
</assoc>

OR:

<assoc type="is-sibling-of">
  <assocrl type="sibling">eric becky dawn</assocrl>
</assoc>


> Eric: which of these most closely matches your intent?


My intent was to define an association whose property was symmetrical.
However, looking at the example it appears to be more reflexive since I am
using a single topic type (according to Holger and Steve's definition and
examples).  A symmetrical assocation would look like:

<assoc type="is-married-to">
  <assocrl type="husband">eric</assocrl>
  <assocrl type="wife">rita</assocrl>
</assoc>

where one could say "eric is-married-to rita" and "rita is-married-to eric".
Based on the comments received, I'm also guessing that this would be valid
per HyTime and 13250.  The symmetry would have to be done via an
appliciation, since the standard doesn't address the reflexive and
symmetrical association properties.

The aggregation discussion, although unintended, brings up some very good
points to be considered.

> I think this analysis raises at least three important questions:
>
> 1. Should 13250 codify an "aggregation" form of topic association? If
> so, what are the knowledge representation implications of such an
> association? Or, should 13250 be clarified to make it clear that topic
> associations cannot be used for aggregation (and thus the sample is not
> semantically valid).


It might be useful to add aggregation of some sort.  RDF has "bags",
"sequences" and "alts" which are aggregates with specific semantics attached
to them and their members.  Interchange-wise, it would be helpful if it were
in the standard so everyone could process it in the same way.  Another
option may be to define "public subject" associations with the same
semantics.  Do public subjects have the same degree of enforceability as
something stated in the standard?


> 2. Should 13250 (or XTM) codify additional specialized forms of
> hyperlink that better represent symetric relationships?


As far as 13250, my guess is that Steve N. and Michel would say that this is
to be left up to the application.  Basically what I (and others) are trying
to do is assign some sort of semantic processing to associations.  The
standard, intentionally I believe, is mute on semantics on associations.
Whether it should be in XTM, I cannot say, but my gut feel is that we need
to get the initial XTM document completed/published and then worry about
defining special semantics (public associations?).  I'm open to debate on
this one.


> 3. Is HyTime underspecified with respect to either aggregration or
> symetric relationships? If so, how can it be corrected?
>
> I don't have an opinion on questions (1) and (2) because I haven't
> thought enough about the semantics of topic assocations--I would leave
> it to the editors to decide.
>
> For question (3), I think the answer is probably "yes" (aggregation is
> underspecified), but I don't see an obvious way to correct it within the
> syntactic constraints of the HyTime interchange syntax. There are
> probably many more sophisticated ways to think about aggregation and
> symetric relationships that are simply too compliciated to render in a
> simple attribute-based syntax.

Are there ways in HyTime to define the semantics that RDF has for its 3
types of aggregations?

bag = unordered group of items (order is not significant)
sequence = ordered group of items (order is significant)
alt = any item in the list is acceptable without regard for the other items


One place where I can see these aggregations being useful would be in
occurrences.  One could then say that the items within an aggregation of
occurences are unique and need to be processed individually (bag/sequence)
or they are basically equivalent and any of them will serve (alt).


Thanks for the info Eliot!

Eric

------------------------------------------------------------------------
Replace complicated scripts using 14 new HTML tags that work in
current browsers.
Form the Web today - visit:
http://click.egroups.com/1/5769/4/_/337252/_/962043504/
------------------------------------------------------------------------

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com