[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] XTM Requirements (Was RE: Is this valid per HyTime? - topicmapmai l thread)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC