MEETING NOTES August 21, 2001
Ivanhoe Meeting 8.21.01 (Worthy, Jerry, Andrea, Nathan, Steve, Beth, Holly, Johanna)
N: Will send out questions to prep a meeting - screens of Ivanhoe and user interface. Webmode vs. applications mode. Will send out a Visio Document. On the web: will send the URLs.
JD: Planning/scheduling
A: Task modeling and graphical modeling/conceptual model coherent in 5-6 meetings, preliminary agreement - stop development on back-end (programming) until we have a task model concept more developed.
S: Reboard.
N: Architecture can be done for its own justficiation rather than to build for the sake of the project's.
J: Planning process concretized:
N: Defnitive, complete, and specific. Hardest: what you what, exactly what you want, and so it won't change.
A: Through September, early October do the task model. Then outside projects/elements.
Topics maps may play an important role in the information architecture/document structure of Ivanhoe.
History and point at which we are at with Topic Maps. Intro to Topic Maps. What Topic Maps Offer to Ivanhoe
W: Task structure, how Topic Maps relate?
A: Information architecture that underlies - XML and other documents - document for a move, a role, and have to have some sort of a master game file that keeps track of the relationships between player files, moves the original text, coordinates the chat etc. That the chat room would be the place where the relationships among these files would be mapped and logged. One topic map for each round of play. Multiple games on one text (source text can support any number of games).
Preview of what topic maps will offer: 1) built in is a distinction between conceptual level and resource level, the master game file is the conceptual level laid on the resource files (source text, moves, player files etc.) Topic maps have a mechanism to incorporate semantics into the file. Topic maps incorporate associations, and could incorporate the rules. Game play diagram could be generated from a topic map (SVG graphics or graphics built for this purpose.). Problems - TIME. No one has ever built these on the fly. Template would be built and the topic map would be populated as we go. Rules will have to be formalize.
JD: That Jerry and I were going to try and formalize the rules, at least a part.
A: Topic maps were introduced as a tool for creating semantically rich indexes of large collections of complex resources. Example that is frequently cited for "semantically rich" - index of a print book (some references printed in bold, or with an "n" by it, but the link allows you to figure out what kind of resource you are going to find).
S: Topic map lets you label a link in any way you like.
A: Build a topic map that can be applied to multiple collections of resources. No rules as to how the content is defined.
JM: Could she send the bibliography.
A: Will send this file. [LINK HERE]
S: Topic maps something he goes ga-ga over but looking at examples there's "so what" response unless syou understand that the ontology / structure is.
A: Ontopia.net is a great source for images. www.quid.fr. One example of a topic map on opera - commonly recycled example. Printed out a document/example of a topic map.
Work began in 1996 on topic map standards, 2000 ISO 13250, XML topic maps - Feb. 2001 XTM - NOT a W3C standard and won't be. Will join Oasis - industry consortium. Worthy or Steve may be able to say whether or not it is a good thing or a bad thing - but it is an established group that has some funding, demonstrates some energy/industry interest in topic maps. Supporting standards aren't there yet - query language (XQML) not developed yet. Schema - no way to parse a topic map. NO way to check to see if the rules have been followed.
N: Is XTM a DTD?
A: Yes, but none of the schema have been released.
N: Could check its validity (S--as an XML document) -- and does it conform to the DTD - parsers that will do that.
A: Most are encyclopedias. Steve Pepper is the Ontopia guy, opera is his thing.
SVG graphics created from topic maps. (http://mondeca-publishing.com/s/anonymous/titl10213.html)
A grad student in France working on a 3-D representation. Benedict Legrand. [SP?]
Kirk Hastings at IATH has talked with Steve Pepper at Ontopia about getting someone here to do a class, experiment with them. Empolis has published some topic map material that can be used for educational purposes (but KH has reservations about this material).
Can open up notepad and make a document that is a topic map, but the software packages have a validation mechanism and with Ontopia packaged with it is a viewer. Not visual, more text based.
JD: Isn't part of the appeal the visual scheme?
A: Topic maps and XSSLT to make a visualization. (SVG Scalable vector graphics) depends on an Adobe viewer, not on the Legrand Viewer.
Concepts of topic maps: 3 basic components: topics, associations, and occurrences
Topic: Opera = Puccini, Italy, Tosca - anything - nouns/things
Associations = Describe relationships among topics
"written by"
"is in"
Associations are bi-directional
W: Step back. Element says Author, then relationship is between author and work as an element in the document. What is the advantage?
A: One of the advantages: conceptual level vs. resource level, topic maps allow structures to be related that don't relate to the resource level.
S: Stand-off markup vs. embedded markup. Difference is that stand-off is mix and match. Suppose you have operas related by some notion of influence then can express that network of influence relationships, both can relate back , can literally lay either one on.
N: Analogy of embedded roadsigns - in the road, the content of the road is the content of the marked-document. Topic map can have any scale/application.
W: But the issue about layers that
S: Style sheets are bad at concurrent structures
W: If we just want to display and not mention the other scheme. Difficulty is all tagged information still has to be made. Other influences to be scrolled through. For Ivanhoe, the issue of tagging might not be so important.
S: The other issue about topic maps is that you could come along and use a topic map to handle documents that that topic map doesn't know - separate entity
JM: DTD and Topic map differences?
S: DTD's don't describe relations among documents.
JM: Scale issue/ granularity - can't do with a DTD.
W: Why can't you do it with a DTD?
N: A document is a thing at a particular scope.
W: But if you have conceptualized what tags are relevant at what level, then you can display the docs at that level.
JM: Have to have parallel DTDs to do this. Whole series of overlapping relationships in a topic map, while a DTD doesn't tolerate that.
S: Topic map isn't in the markup
W: But it has to refer to these things, which requires a granularity like that of a DTD, so question is what pieces can you pick out - can you refer to them in the way that you want to - so are topic maps actually hierarchical, so how you "dice" the data underneath still determines how you can access. If you aren't careful with how you do the topic map then you'll have difficulty.
[DIAGRAM #1] - Element and element - naming the relationship
A: Association tag would be "is written by" or "wrote" - association types are named bi-directionally.
W: Text field as "first class object" - don't want to trap it inside the object, not just as character content, put a link in - the question remains, WHERE does the information sit? Do we create another structure for this?
S: If another item at the same hierarchical level as "book" - and try to express it in the document, then
W: An association among these things?
B: Then why would it be at the same hierarchical level?
S: Not the same thing but at the same class/hierarchical level? A concurrent mark-up example?
A: In the game: novels
N: Novel written from journal entries - chapters and journal entries might not be the same. Ultimately the topic map isn't what determines whether you can describe the relations - still have to define the resource in a system. Ultimately the ontology of the resource defines whether you can make the link. Not a huge difference between a DTD and a topic map.
S: DTD doesn't describe intra-document relations. No client parser will validate it.
W: What matters is what defines "the document" - for Ivanhoe.
N: Yes, the practical issue -
W: Chapter 2 and 3 (example) in different places, can we link them in a topic map even though they are in different books.
A: Topic would be "chapter" and Joe would be associated by "wrote" association.
JM: Does the authoring, through the scaling process, get all the "children" of the topic - authoring moves down and mark at the granular level of text.
A: Topic map can define whatever you want it to be. But in your documents if you have a closed chapter, then in your software system you can say, this association ends when the chapter closes.
JM: If you use stand-off, then ALL the children are called. Then anything in there is called?
W: Another system that would allow these properties to be inherited by these parts. Then inherited down.
A: Inference engines. How do you reason from this statement?
JM: Is this the force of it? Why not use DTDs? What does it do that a DTD structure won't do.
A: The inference engine is a power of this technology.
N: Inference engine for a DTD as well. But the real distinction is the stand-off effect, if you want to process - you don't have to process the whole document, you only see what's important for your agenda for this map.
S: The Stand-off markup concept is important. Can go through an mark up everything, "this is about cooking etc. etc. etc. to every instance" OR you can have an index that says "for cooking see: x, y,z"
W: What do we have in Ivanhoe that needs this? If we are building up a body of information.
JD: The linking operation that makes the topic map.
A: Topic map template, types of moves allowed, rules that permit certain patterns/types of play.
W:Don't expect people to do their moves by editing the XML. In the playing of single game where does this come into play? If we got the specific book that we are playing on, then we have a book that is marked up for its own purposes, and we want some other scheme that can be used to point INTO that book
N: We'd want to start with the document and enter these things in it
J: That the playing of the game becomes part of the showing "what's here" in the book.
W: Not have to add them in an extrinsic way (the extra index) if in the play we are going to try to identify things, and indicate relationships among them, then link back to specific resource that's there, player file, individual documents, then be able to refer into these.
A: The topic maps allow us to use XML or DTD for player file or source text, but what we think of as the move is in the player files, but the topic map (moves become occurences) describe the relations. Allows you to take your player file with you to other games.
W: Player file associated with a particular player, role persona being used.
A: Roles make moves, players make roles.
N: The topic map is most useful when you want to make an SVG image of the game being played. Not so useful as a way to the text as intervened in a serialized way. Processing document for markup. Something that says, there's an intervention here, render it.
S: Topic Map - go into the document and render the pieces.
N: This is too round-about
S: But it is round-about if we want the semantic label on the association.
W: Early September - What Do We Really Want as the Intervened Text. What do we mean or want by display of an intervened text.
N: Need to get very specific about what we want to be able to display.
A: If game play occurred in rounds then you could see these displayed as such.
W: Scope?
A: Scope is a way to filter information in topic maps in the sense that you can have a topic that can mean two different things in two different contexts. So scope is a way of saying context. You could have a scope of "Tosca" which is an opera and a character. You can say, "Let's see all characters" and the character Tosca would show up. Ivanhoe scope would be round #1, round #2 - another way of filtering resources, want to see only the ones that fit.
B: Show things that correspond to a particular association.
JM: Attributes on the topics?
A: Scope topics, not associations.
S: If we could define moves as erasures, intervention, golden move, etc. then certainly topic maps are on the model of an index - show me all the erasures, show me the text with just erasures, just things taken out, etc. If you tried to encode a text with all of that then it would be cumbersome.
N: All moves within a Rowena but only in the Johanna context, not the Jerry context (the role was sold).
S: Show Scott, not the character/role that Jerry was playing, but the author.
B: Unless you build in some kind of causality - could you encode ordering of moves? Two kinds of associations? Erasures from this point back?
A: Time is a difficulty, occurrence could be a time stamp. Could reference the occurrence as a time stamp. Some people want to do time lines - only way to do that is a topic for every unit you desire.
N: This highlights the issue brought up earlier - hundreds of different ways - does it make sense to use topic maps. Player moves have to record their time somehow - but is this the best way to do it? We need to decide what we WANT the game to DO - so we can decide which is the best way to go to make it happen. One area where there is practical usefulness is in generating a whole game view and if you try to process the data in its individual location it would mean a whole long wait for the user but might be easier for the topic map to do.
A: The document is the material instantiation of the game.
S: Ivanhoe is at root an annotation system, here an extremely fancy annotation system, that does things like step through the temporality of the annotations, lets you move through it in many different ways, a constant of our discussion is that we are interested in capturing and analyzing the process of annotating a text, keying this up so high that the process is itself a game.
N: The rules engine - these are not annotations that just happen, but need a powerful record of the annotation in order to be able to test these against the rules engine.
A: Even before AI engine, have to have a way to put the moves against the rules - gameplay diagram would be facilitated by topic maps
N: Indices that J and J wanted on our diagrams - all the pages on which Rowena speaks -
JM: Where events take place
N: Would clutter the document up - but a topic map would work to show the location of renderable source texts
S: Not sure that this will cut the work down
JD: But the work of tagging would be part of the game
W: Try to identify things as part of the play - concern about granularity of the what the players/roles provide access to - what is it you can refer to as resources? Have to say the topic thing is X, what is that - built in granularity that you have to refer to -
N: A flow chart of screens or views that can provide the user access - to what can the user refer. If we want to them to refer to it - then marked up somehow.
S: Comes back to Nathan's point that we have to think through what we want to do.
N: Who can initiate a game, once it is initiated then how is permission granted, initiating permission granted etc. - not just storyboards - but a task model - game design document.
A: An occurrence is an instance of a topic, it points to an external physical resource - an article, a web-page.
W: When the topic is a representative of a category of objects, then an occurrence indicates an example of that.
A: Occurrence is at the level of resource structure
JM: RAWS (WORK) would be topics, RAPS would be occurrences. (INSTANCE).
ADDENDUM: (Worthy, Jerry, Johanna, Andrea)
W: What will the intervened text look like. Overlaid? Intervention? Footnote indicating intervention? Seamless integration of whole?
JD: Can we have several kinds of display? Save each version/iteration? Show the "seamless" image of the fully intervened text or filter according to various factors (J's interventions, A's as Role X etc.?)
W: Topic maps still a question. Are the associations named according to the types of moves? Is a move recorded as a Topic or an association?
(The discussion that followed focused on whether topic maps will offer useful functionality to the game - if the main value is to generate the display of game play on the fly, then that may not be sufficient - also, how is the visual organization of that display determined? Most of these topic maps look like they are somewhat random in their visual form rather than schematized according to some semantic metric/structure. Is there a gain over using XLINK and XPOINTER that is to be had through the use of Topic Maps? )
More discussion on how a MOVE is valued - a "good" move is one that demonstrates insight into complex sets of relations - do you have to say WHY or simply claim this? Assert it through links? Do you have to explicate each of these links (to get points/credit etc.)? X can make the connection, Y can explicate X's move.
W: Is there a way to create a workspace for moves that allows a fairly "ham-fisted" way of using links/references to record connections and the move without any analysis of content. Move #38 - lists 3 xrefs, then the rationale in "plain English". (Worthy's "0.0" version of the Ivanhoe application.)
JM: Could types of associations be defined by this set:
Player to own moves
Player to discourse field
Player to other Player Moves
Any combination of the above
And if so, could these then be "coded" in the display.
A: And a subset of each of these could be comprised (as appropriate) out of:
Expansion of
Rebuttal of
Challenge to
Deletion of
Revision of
Can associations be encoded in the topic map in such a way as to be useful for visual/graphic display? Is the information worth encoding?
W: The complexity of a visual stream and coherent display doesn't necessarily correlate to complexity of data structure (and vice versa).
J/J: We'd want to be able to display any set of relations among moves already made, or not yet made, or to be made …..
W: It's that "or to be made" sort of thing that makes me a little nervous...