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
