[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] Reification of topic map constructs
>I like both the terms "node" and "graph". What I am trying to figure >out is if the specification will use the terms, or if they are only for >internal use by the AG. > >Personally, I'm for them, since graphs are a well understood formalism If the vocabulary of graph and node is considered helpful, then by all means let's use it. It will also have the merit of being familiar to the RDF community. Any vocabulary that can help to build bridges of understanding between communities is good, as far as I'm concerned. >> The boxes in the UKL diagrams represent types of object (types >> of node ...) that will exist, and the lines between them represent >> types of relationship that will exist betwen objects of those types, >> or between the types themselves. > >Uh, the "cheat sheet" you sent says, for the relationship between the >box labelled "human" and the box labelled "shelter" that the relation >is labelled "home" indicating that the type "Human" has an attribute >named home whose value is a single "shelter" object. > > "Human" -------- +home -----> "Shelter" > >What you write and what the cheat sheet says don't sound quite the same >to my untutored ear. I take it that by establishing a (typed) relation >(arc) ebetween two objects (nodes) I am also giving values to >properties of one (both?) object(s) (node(s)) in the graph? Your ear sounds pretty well "tutored" to me, Sam! Yes indeed, the relationship between human and shelter, with the shelter playing the role of "home", means that each object of type "human" will have a property named "home", whose value will be an object of type "shelter". In this case, because the connecting line had a terminator in the shape of a v arrowhead, the inverse property is not present. If this had been a simple line with no arrowhead, the other end of the line could have been labelled "resident", for example. This would mean tnat the shelter object would have a "resident" property, whose value is an object of type "human". > >> We happen not to be using the term "graph". We happen to be using a >> graphical syntax rather than a text-based syntax to express the >> model. But what we are developing is precisely a formal description, >> in a widely-known syntax (an imperfect one... > >I would be happy to be assured that the imperfections are not material >for XTM -- but even more happy to have that demonstrated. Agreed. We're doing the best job we can with the chosen syntax. It may be that when we're done, we decide to "translate" the model into other syntaxes also, such as EXPRESS. I'm sure that would please Lars, and probably Eliot, Chris and Matthew too. This would also build bridges to the the engineering community, who use EXPRESS extensively. > >> Operations, such as merging, or query resolution, can then take place >> on those objects, and the result will be (if we are successful in >> achieving "closure" > >I understand that a topic map engine does not operate directly on the >topic map markup, but only on a graph that contains properties (some >emergent) that derive from the markup. (This is why the graph is not >isomorphic to the topic map document, which is counter-intuitive to >someone brought up on the DOM, for example.) > >So far, so good -- but what is "closure" (on a postcard, please) and >what is the test to pass that tells me that I have achieved it? CLOSURE ON A POSTCARD: A set is said to be closed under a family of operations if performing those operations on members of the set always yields results that are members of the set. EXAMPLE 1: The set of positive integers is closed under the operations of addition and multiplication (i.e. adding and multiplying positive integers always yields positive integers.) EXAMPLE 2: The set of positive integers is NOT closed under the operations of subtraction and division (i.e. subtracting and dividing positive integers does not always yield positive integers.) EXAMPLE 3: The set of real numbers is closed under the operations of addition, multiplication, subtraction and division (i.e. adding, multiplying, subtracting and dividing real numbers always yields real numbers.) EXAMPLE 4: The set of relational tables is closed under the operations of relational joins and queries (i.e. joins and queries on relational tables always yields relational tables.) EXAMPLE 5: The set of topic maps will be closed under the operations of merging and querying. (i.e. merging and querying topic maps will always yield topic maps.) EXAMPLE 6: The set of XTM documents will be closed under the operations of parsing, then merging and querying, then serializing. (i.e. parsing, then merging and querying, then serializing XTM documents will always yield XTM documents) > >> other sets of objects that also conform to the structures >> and constraints of the model (in other words, a merging of two topic >> maps will itself be a topic map > >Sorry, I understood the result of a merge to be a topic map *graph* For me, the topic map graph *is* the topic map. >(from which markup that was a topic map document could indeed be >derived, although this would [????] suppress properties that emerged >from the merge -- nice sound to that -- although not those *added* to >the merge via <mergeMap>.) > I don't follow the distinction between "emerge from the merge" and "added to the merge via <mergeMap>". But then I have not been following the syntax group's work closely, and don't yet know what <mergeMap> is all about. No doubt I'll find out in Dallas. >> topic map that results from the operations of merging and querying >> (and perhaps other operations to be defined), will exist in memory > >In memory? When topic maps can be gigabyte-sized? Surely this is >dangerously close to implementation... "will exist in memory" should perhaps read "is available for further processing and may optionally be serialized as an XTM document." > >> in exactly the same form as the original one or ones > >I'm not sure how to test this.<snip> >So how do I know that the forms are exactly the same? I didn't mean they're identical in structure; just that they're of the same *nature* (closure again!) > >> and also to express the sytactic model (the DTD) in UML (thereby >> making it accessible to non-DTD-savvy developers who are familiar >> with UML) > >My primitive understanding of UML, at least from the ebXML world, had >led me to believe that although *a* DTD can be derived from a UML >model, it is not so easy to derive *a particular* DTD, and in any case, >a DTD doesn't "fall out" of the model. (In other words, DTD creation >has its own integrity as a design process.) Sure, many different DTDs could be developed based on on UML model. Likewise, there are no doubt many ways one could represent the same DTD as a UML model (it is this latter process we're talking about here). I hope Eliot will be available to help with this task, as he has the most experience in this area. > >But maybe you guys know something I don't. More than likely! I doubt it! ;-) Daniel > >S. > >===== ><?-- "To imagine a language is to imagine a form of life." > - Ludwig Wittgenstein, Philosophical Investigations --> > >__________________________________________________ >Do You Yahoo!? >Thousands of Stores. Millions of Products. All in one Place. >http://shopping.yahoo.com/ > > >To Post a message, send it to: xtm-wg@eGroups.com > >To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com > -------------------------- eGroups Sponsor -------------------------~-~> eGroups eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9698/1/_/337252/_/973815331/ ---------------------------------------------------------------------_-> 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