[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] Questions about the Processing Model
1) Then is a topic's role in a scope one of its characteristics too? 'scope participant' had me confused for a while. I had to read a long way to realise that one wasn't a 'scope constituting topic/assoc'. 2) Sect 2.3.1 Subject-based Merging Rule: "Two t-nodes with subject indicator resources shall be merged if and only if: either: One of the two t-nodes has at least one subject indicator resource that is known to the processing system to be the same resource that serves as one of the subject indicator resources of the other t-node. " This seems to me to let in far too much ambiguity. If I point to the same document in two different senses from two separate t-nodes, they might be merged? 3)Sect 2.3.2 Topic Naming Constraint-Based Merging Rule "The "Topic Naming Constraint", which applies to all topic maps and on which the "Topic Naming Constraint-based Merging Rule" is based, is that no two t-nodes can have the same basename in the same topic namespace. " What are the results of a merger process where there are a large number of distinct topics each of which has only one name overlap (same basename in same scope) with at least one other? A name overlap chain, if you will, that destroys semantic nuances when merger is activated? How do you serialize the results? Peter -----Original Message----- From: Peter Jones [mailto:peterj@wrox.com] Sent: 04 January 2001 13:05 To: 'xtm-wg@egroups.com' Subject: RE: [xtm-wg] Issue with instanceOf >I do not believe the >type of 'scope' to be either topic or association or topic map as these >constructs are understood in TMs. Let me just qualify that statement a bit before everyone screams 'references to topics!' in my face. In a scope construct, you make references to topics. Those topics might have associations between them, so those are additional properties of the scope. So the scope is really a reference to a (possibly small) topic map (topics and their associations). This scope determines which properties of a topic map get, e.g., displayed when that scope is the 'active' scope. Bear in mind that topics in the scoping topic map can also be in the scoped topic map. With the HUGE caveat that I haven't read the processing model stuff yet, how does this scoping topic map enact its scoping effect? The way the scoping topic map scopes the scoped topic map does not look to me like any construct in a TM even though the scoping topic map may have been determined from a set of reference to topics in a scope attribute. Peter -----Original Message----- From: Peter Jones [mailto:peterj@wrox.com] Sent: 04 January 2001 12:43 To: 'xtm-wg@egroups.com' Subject: RE: [xtm-wg] Issue with instanceOf For reasons stated in other mails posted to the editors I do not believe the type of 'scope' to be either topic or association or topic map as these constructs are understood in TMs. Nor do I believe it can be effectively modeled using combinations of these. A scope is a different animal and requires a unique construct in the processing model (whether that is there in the existing text or not I do not yet know as I haven't read that bit yet). So...bearing that in mind I'll state my question in a different way. Should the contents of instanceOf _ever_ be unscoped (whether unconstrained or not), strictly speaking? To dig back down to the fundamentals of the original little diagram that Steve N drew in Paris... When it comes to nailing the zero-dimensional point to the board we use subjectIdentity. And, IMHO, that is the only property of a topic that should be nailed and that therefore should not be scoped; everything else should be allowed to be. Pete N wrote: (2) is unnecessary because having a single association with multiple types (each in a different scope) is equivalent to having multiple associations (each in a different scope) where each association has a single type. Except that for some reason I might want to ensure that I have the same set of endpoints (members) on an association to which I subsequently add many types. Or a many-typed association that I want to add a new member too under all the types of association at once. Amongst other things the scope mechanism is a powerful compression factor. Peter -----Original Message----- From: Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com] Sent: 04 January 2001 00:16 To: 'xtm-wg@egroups.com' Subject: RE: [xtm-wg] Issue with instanceOf Peter Newcomb's response points up the very issue I raised in my email about syntax issues. We should NOT be using the instanceOf subelement of association for the purpose Peter Newcomb describes (which is to identify an association that serves as a template for the current association). As Peter N rightly points out, this is a different thing from instanceOf on topic. Therefore (in accordance with the design decision already taken that things that are different in nature should have distinct syntax), the instanceOf element should not be used for this purpose. I have proposed the use of an associationSpec subelement of association for this (by analogy with roleSpec, which has exactly the same typing function with respect to roles). Peter Jones's question applies, however, to the ordinary use of instanceOf, whether it be on on a topic element, an association element, or an occurrence element. The purpose of instanceOf is to point to a class of which a topic (or association, or occurrence) is an instance. My position is that instanceOf is a syntactic shorthand for an unscoped class-instance association. There may be merit in allowing this kind of shorthand to be used for a scoped class-instance association as well. This is the question I understand Peter J to be asking, and it merits an answer. However, it's OK if the answer is to leave instanceOf unscoped, because there does exist a longhand way of creating scoped class-instance associations. The longhand way of creating a class-instance association (scoped or not) is to create an association element that has the public class-instance association template as its template. However, given the importance of typing to the topic maps paradigm, and the frequency with which it is used, it is useful to have a syntactic shorthand such as is provided by the instanceOf subelement. Similarly, the occurrence is a syntactic shorthand for an association between a topic and a reification of a resource, having the public topic-occurrence association template as its template. It is precisely these mappings between the syntax and the conceptual model that need to be spelled out, and I have offered to create a first draft of this. This task is intimately bound up with the declaration of the relevant "public subjects". I was supposed to do this prior to the Washington DC conference, but was unable to do so because there were (still are) unresolved syntactic issues. I have raised these issues in my earlier messages, and will allude to them again insofar as they are relevant to the mapping between the syntax and the conceptual model, which I shall be trying to produce in the next few dayus. Best regards Daniel -----Original Message----- From: Peter Newcomb [mailto:peter@techno.com] Sent: 03 January 2001 17:37 To: xtm-wg@egroups.com Subject: Re: [xtm-wg] Issue with instanceOf [Peter Jones <peterj@wrox.com> on Wed, 3 Jan 2001 14:34:27 -0000 ] > why are the contents of instanceOf not scoped too? In the case of an association element, the instanceOf element serves to type the association. If this typing relationship were to be scoped, it would have to be done in one of two ways: 1) by representing the typing relationship as another association in the topic map graph, or 2) by allowing (in the conceptual model) scopes to apply to typing relationships even though they are not associations. (1) is considered unacceptable because an association that models a typing relationship between another association and its type must itself be typed; if it is to be typed using the same mechanism as the first association, it creates an infinite regression. (2) is unnecessary because having a single association with multiple types (each in a different scope) is equivalent to having multiple associations (each in a different scope) where each association has a single type. -peter -- Peter Newcomb Epremis Corporation peter.newcomb@epremis.com http://www.epremis.com/ To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 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