I think we might actually be on the "same page" here; I suppose I am musing at the implementation level. Let me explain. Suppose I go to some, say, Jack Park triple that happens to be not in the SRI org chart but, say, at the David Karger page where the annotation has something to do with this conversation. Suppose I change, say, the spelling such that it should have been John instead of Jack. At the implementation level, if I do that in the David Karger page editor, how does one make sure that change propagates back to the, um, original triple itself? For such changes to automatically propagate, as Ted Nelson suggested, the actual triple (the original -- pardon the hack vernacular here) is transcluded to pages where it is used. It's the transclusion process I am wondering about. Transclusion, the way I am using it here, means "linking" to the original triple in the same sense that images are actually transclusions from one image repository at the website. You can use one image identifier in the <img tag and if you change the actual image to something else with the same identifier, you change all the presentations of it. Ted Nelson was arguing for singleton representation of facts in a kind of repository such that you can use those facts everywhere you wish, but changes are reflected in the repository, even if they are made at the instances.
Jack David Karger wrote: > My assumption is that future semwikis will be general purpose tools for > presenting a chosen group of triples in a coherent fashion. For > example, I might ask to see all the triples "about" Jack Park, in which > case the way to present those triples might be as some kind of > address-book form. On the other hand, if I decide that I want to see > all the triples "about" SRI, then _some_ of the triples about Jack Park > might show up in an org-chart view that makes up part of that > presentation. If I edit the triples making up the Jack part portion of > the org chart, then I am _also_ editing the triples about Jack Park, and > future visits to the Jack Park page should show those edits. > > Someone asserted that it's important to make it easy to "find triples" > in order to edit them. I think the easiest of all ways is to allow the > triples to be edited wherever they turn up which, as in the example > above, might be in multiple locations. > I'm brushing aside the specific question of how you edit the triples you > see---in general, triples are a very primitive presentation of the > information, and it would be painful to have to edit an org chart as > triples. Better way would be to have an "org chart view" that produces > an org chart from triples, together with an org chart editor that lets > you edit the nice view the org chart, then updates the underlying > triples in response to your edits. > But if you want to be less ambitious, you can think about the > "infoboxes" that current wikis offer. Triples about a particular entity > fit naturally into the infobox for that entity. But in multiple > places---eg, the triple "Clinton vice-president Al-Gore" should be in > the infobox for Clinton, and _also_ the infobox for Al Gore, and should > be editable in both places. > > Jack Park wrote: >> David, >> >> When you say "edit that triple _wherever_ they encounter it", do you >> mean that the triple *itself* is a singleton and has just been >> transcluded (ala Ted Nelson) or do you envision that the triple stands >> as it is, an instance of a particular statement such that editing it >> does not affect other instances of the same statement? >> >> I've been watching this thread with the "topic maps" context in mind, >> and I think this thread is being at once instructive and enlightening. >> I am amazed that the many different ways we have come to interpret the >> term "page". I'll admit that the topic maps perspective can seem >> pretty limited, given that a "page" would be a >> representation/carrier/whatever for a *subject* -- doesn't matter what >> that subject is: it could just be a collection of representations of >> other subjects, as for example, the "first steps" page at the apache >> jackrabbit wiki; the subject of that page is just that: examples, each >> of which is, itself, another subject(s). (note to self: gotta watch >> syntax here). >> >> I tend to think of a page in the same sense as GOFAI frames would have >> me think: the page is the foundation for a particular frame, a subject >> if you like, and whatever else is contained in that page is, in some >> sense, a slot or slots in the frame. Said slots could be triples, >> text, HREFs, whatever. That's just the view I take of a page. Your >> mileage might vary. >> >> Cheers >> Jack >> >> David Karger wrote: >>> I would argue that a given triple can naturally show up in many >>> different context---on the page associated with its subject, on the >>> page associated with its object, and on a variety of pages >>> representing the results of queries that involve that triple. And we >>> might as let people edit that triple _wherever_ they encounter it. >>> Why should a triple have to have a single "home" page where it can be >>> edited? And what does it mean to edit a triple anyway? Pretty much >>> all you can do with a triple is create one or delete one. It seems >>> no big deal to let someone create a triple while they are editing any >>> page. Presumably they will _usually_ create a triple having to do >>> with the subject of the page, but as in the example that started all >>> this, they may be prompted to create a bunch of "supporting" triples >>> that go with but are not exactly bound to the page subject. >>> Conversely, if a triple shows up in any page, there should be a way >>> for a user to delete it---this seems doable, by having the wiki >>> compare the original text to the edited text, identify triples that >>> are no longer present, and remove them from the triple store. >>> >>> [EMAIL PROTECTED] wrote: >>>> (sorry for multiple copies - honestly this thread has too many To: >>>> and Cc: to understand ....) >>>> >>>> While I personally like the page-centric approach of SemMediaWiki, I >>>> always believed that an additional feature allowing a free flow of >>>> triples would be convenient. >>>> However, these should be, IMHO, confined in pages without subject, >>>> or with multiple subject. >>>> >>>> To attempt a parallel with the 'unplugged' wiki, there are >>>> 'encyclopedic' pages on specific subjects like [[Edgar Varese]], and >>>> 'flow of thought' pages like [[Influence of Varese music in Frank >>>> Zappa production]] without a clear subject. >>>> >>>> In the latter case, I would like to see a straight implementation of >>>> N3, instead of strange wiki-syntax deviations. Maybe something in >>>> the style suggested by >>>> http://www.wikisophia.org/wiki/Wikitex. >>>> >>>> Andrea >>>> >>>> >>>> Daniel Schwabe ha scritto: >>>> >>>>> It seems to me that some of the variance in views here regards what >>>>> each one understands as a "wiki", in this context. >>>>> Suppose we consider it, as, loosely speaking, a tool for the >>>>> collective production and editing of knowledge, by technically >>>>> untrained people. To some, this knowledge as being represented as >>>>> triples. Others view it as being represented in the text itself >>>>> (hence, not really processable), and still others may see it as a >>>>> combination of both. >>>>> The first alternative does not really look like a wiki as most >>>>> people would think of it; I suspect the third one is the more >>>>> common understanding of what a "semantic wiki" would be. >>>>> (Btw, I don't see such an advantage to regard a wiki as simply a >>>>> "text based" interface to directly edit RDF or OWL ontologies... >>>>> but this is another discussion perhaps). >>>>> I can't see how to analize advantages/disadvantages of any of the >>>>> alternatives before it is clear which paradigm is being followed, >>>>> If you take the first point of view, I'd tend to agree with Mark's >>>>> remarks. If you take the third point of view, it is not so clear... >>>>> This is essentially why I asked Mike to make the usage scenarios a >>>>> bit more explicit; I'd like to understand better how is the formal >>>>> (i.e. triples) knowledge is being created, edited AND USED in the >>>>> first and third alternatives above. >>>>> So, in summary, what is (more precisely) the problem being >>>>> addressed in using the wiki? >>>>> >>>>> On 26/4/2007 19:39, Mark Greaves wrote: >>>>> >>>>>> Mike, >>>>>> >>>>>> >>>>>>> Now I have a triple. I don't care where it is stored, it can be >>>>>>> associate with any page or no page. In fact I don't even want to >>>>>>> see it. I want the tool to take care of all that for me. >>>>>>> >>>>>> I disagree with this. In order for triples to enjoy the benefits of >>>>>> social editing and the social identification and correction of >>>>>> errors, >>>>>> they have to be simple to find, examine, and edit by a large >>>>>> number of >>>>>> relatively untrained people. In order to maximize the number of >>>>>> people >>>>>> who can access/edit the triples, the process of locating and >>>>>> editing the >>>>>> triples needs to be as parallel as possible to the already-known >>>>>> process >>>>>> for making corrections to ordinary wikitext. So, rather than force >>>>>> triple-editing to go through some kind of searchbox interface, it >>>>>> makes >>>>>> more sense to me to make the triples embed in the wikitext of the >>>>>> subject page. Furthermore, this strategy allows for a natural way of >>>>>> using associated wikitext to lay out arguments, in case there is >>>>>> dispute >>>>>> over the value of a triple. >>>>>> >>>>>> This does make the kind of freeform triple entry you desire a bit >>>>>> more >>>>>> cumbersome. Nevertheless, I think it is consistent with the goal of >>>>>> making the triples that exist as accessible as possible to the wiki >>>>>> editors. >>>>>> >>>>>> Mark >>>>>> >>>>>> Mark Greaves >>>>>> Vulcan Inc. >>>>>> 505 Fifth Ave S, Suite 900 >>>>>> Seattle, WA 98104 >>>>>> >>>>>> (206) 342-2276 (voice) >>>>>> (206) 342-3276 (fax) >>>>>> ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Semediawiki-user mailing list Semediawiki-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user