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
