From: Daniel S. <dsc...@in...> - 2007-04-27 16:48:32
|
Interesting, David, you've just described what we call "navigation nodes" in OOHDM/SHDM... These are "ad-hoc" "views" (in the sense of "assembled objects") made out of the core concepts (triples if you wish). Such "assemblies" are determined by the tasks you wish to support. Incidentally, we still distinguish them from the actual interface, which is yet another level of abstraction, where you decide how you want to present these "assemblies" (nodes) to the user. In other words, what you present may include part, a single or several such nodes, and these nodes are "ad-hoc" assemblies of basic information elements (resources). But, at this point, I'm a bit lost as to where the "wiki" is in this discussion - is it just the fact that you can edit collectively a set of triples? This is becoming increasingly more like what we define as a general hypermedia application (in this case, using the Semantic Web as a basic vocabulary do describe the data and concepts, as we do in SHDM)! -D On 27/4/2007 13:29, David Karger wrote: > ... 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. > > |
From: Uschold, M. F <mic...@bo...> - 2007-04-27 17:13:15
|
There is a tension here between: Where do you create & edit the triples? Where/how do you view the triples? In the semantic media wiki currently, these are conflated. You create, edit and view them on the page where they live. If you separate creating/editing from viewing, then you can view them from anywhere as ad-hoc views, esentially answers to queries tha could be presented in various ways from tables to graphs to whatever. The question then arises: where and how do you create them? You could still create them on a page where they are most likely to be viewed.=20 But what if you created them separately, or imported them into your store say from other semantic web pages. Then you could view them any way you wanted from anywhere you put an inline query. There is an important question here:=20 To what extent do you want to see where triples are created on the wiki pages themselves.=20 Mostly we have been assuming that we want this.=20 But if we have separate ways to create triples on or off the wiki pages, maybe this is not necessary. Mike =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Michael Uschold M&CT, Phantom Works=20 425 373-2845 mic...@bo... =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D ---------------------------------------------------- COOL TIP: to skip the phone menu tree and get a human on the phone, go to: http://gethuman.com/tips.html=20 -----Original Message----- From: Daniel Schwabe [mailto:dsc...@in...]=20 Sent: Friday, April 27, 2007 9:48 AM To: David Karger Cc: Jack Park; sem...@li...; sw...@ai...; Uschold, Michael F Subject: Re: [swikig] Creating Triples Anywhere in a Semantic Wiki '' Interesting, David, you've just described what we call "navigation nodes" in OOHDM/SHDM... These are "ad-hoc" "views" (in the sense of "assembled objects") made out of the core concepts (triples if you wish). Such "assemblies" are determined by the tasks you wish to support.=20 Incidentally, we still distinguish them from the actual interface, which is yet another level of abstraction, where you decide how you want to present these "assemblies" (nodes) to the user. In other words, what you present may include part, a single or several such nodes, and these nodes are "ad-hoc" assemblies of basic information elements (resources). But, at this point, I'm a bit lost as to where the "wiki" is in this discussion - is it just the fact that you can edit collectively a set of triples? This is becoming increasingly more like what we define as a general hypermedia application (in this case, using the Semantic Web as a basic vocabulary do describe the data and concepts, as we do in SHDM)! -D On 27/4/2007 13:29, David Karger wrote: > ... Better way would be to have an "org chart view" that produces an=20 > org chart from triples, together with an org chart editor that lets=20 > you edit the nice view the org chart, then updates the underlying=20 > triples in response to your edits. > > But if you want to be less ambitious, you can think about the=20 > "infoboxes" that current wikis offer. Triples about a particular=20 > entity fit naturally into the infobox for that entity. But in=20 > multiple places---eg, the triple "Clinton vice-president Al-Gore"=20 > should be in the infobox for Clinton, and _also_ the infobox for Al=20 > Gore, and should be editable in both places. > > =20 |
From: Jack P. <jac...@sr...> - 2007-04-27 16:00:41
|
Imagine that large table indeed! What if one wants to annotate each of the table entries? That is to say, what if one wants to link a particular table entry, say, a television set, to other web pages, add user comments about the product, etc. How could one do that within the constraints of the lone wiki page that has that table? My own response is that there is nothing wrong with "cluttering up" the recent changes page with lots of new pages, each of which is a subject in its own right. For portal designers and programmers to presume what the ultimate portal users' needs will be, and to make judgments based on ideas like "cluttered up" navigational aids suggests a possible weakness in the core wiki architecture itself, that of relying on recent changes and title index as the primary means of navigating a wiki (I'm not forgetting search, here). Seems like there ought to be other options. I guess I am suggesting that semantic wiki creators, while working really hard to integrate with the semantic web, need also to think in terms of the navigation needs of human users; reliance on title listings and recent changes listings is perhaps ready for as much rethinking as are issues like where and how to put triples on pages. Jack Pär Lannerö wrote: > 27 apr 2007 kl. 13.19 skrev and...@se...: > >> 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. > > I second that. > > On the one hand, the page-centric approach means simplicity and ease > of use, which won't hurt the Semantic Web at all. > > On the other hand, when we discussed these matters in the Nepomuk > project, somebody (Max? Malte Kiesel?) provided the following problem > description regarding the page-centric approach: > > "Imagine a large table that lists 100 products along with a > short description and price. In order to express this in a semantic wiki > that identifies a page with a resource, one gets forced to create 100 > wiki > pages, one for each row of the table, both cluttering title index and > recent changes pages. " > > Preferrably, a semantic wiki should allow very simple page-centric > statements as well as arbitrary triples. > How can the two approaches best be combined? > > > Best regards from a sunny Stockholm > > > Pär Lannerö > par...@me... > Mobil: 073-944 20 43 > > METAMATRIX // INTERFOLIO > Sveavägen 31, 3 tr, 111 34 Stockholm > Tel: 08-50 65 33 43 > http://www.metamatrix.se > > KTH // NEPOMUK > Lindstedtsvägen 3, 6 tr, 100 44 Stockholm > Tel: 08-790 66 98 > http://www.csc.kth.se > http://nepomuk.semanticdesktop.org > > > _______________________________________________ > swikig mailing list > sw...@ai... > http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig > |
From: Sebastian S. <seb...@sa...> - 2007-04-27 19:04:08
|
Jack Park schrieb: > Imagine that large table indeed! > What if one wants to annotate each of the table entries? That is to say, > what if one wants to link a particular table entry, say, a television > set, to other web pages, add user comments about the product, etc. How > could one do that within the constraints of the lone wiki page that has > that table? > > My own response is that there is nothing wrong with "cluttering up" the > recent changes page with lots of new pages, each of which is a subject > in its own right. For portal designers and programmers to presume what > the ultimate portal users' needs will be, and to make judgments based on > ideas like "cluttered up" navigational aids suggests a possible weakness > in the core wiki architecture itself, that of relying on recent changes > and title index as the primary means of navigating a wiki (I'm not > forgetting search, here). Seems like there ought to be other options. > > I guess I am suggesting that semantic wiki creators, while working > really hard to integrate with the semantic web, need also to think in > terms of the navigation needs of human users; reliance on title listings > and recent changes listings is perhaps ready for as much rethinking as > are issues like where and how to put triples on pages. > I could not agree more. For me, the problem with current Semantic Wikis (including our own) is that they are very good at collecting metadata but very bad at doing something with it. The real step forward would be to use this data for intelligently supporting the user in navigation, personalisation, etc. Unfortunately (or luckily), there is still research to be done in this area - I'd say the really hard work is still ahead of us. > Jack > > Pär Lannerö wrote: > >> 27 apr 2007 kl. 13.19 skrev and...@se...: >> >> >>> 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. >>> >> I second that. >> >> On the one hand, the page-centric approach means simplicity and ease >> of use, which won't hurt the Semantic Web at all. >> >> On the other hand, when we discussed these matters in the Nepomuk >> project, somebody (Max? Malte Kiesel?) provided the following problem >> description regarding the page-centric approach: >> >> "Imagine a large table that lists 100 products along with a >> short description and price. In order to express this in a semantic wiki >> that identifies a page with a resource, one gets forced to create 100 >> wiki >> pages, one for each row of the table, both cluttering title index and >> recent changes pages. " >> >> Preferrably, a semantic wiki should allow very simple page-centric >> statements as well as arbitrary triples. >> How can the two approaches best be combined? >> >> >> Best regards from a sunny Stockholm >> >> >> Pär Lannerö >> par...@me... >> Mobil: 073-944 20 43 >> >> METAMATRIX // INTERFOLIO >> Sveavägen 31, 3 tr, 111 34 Stockholm >> Tel: 08-50 65 33 43 >> http://www.metamatrix.se >> >> KTH // NEPOMUK >> Lindstedtsvägen 3, 6 tr, 100 44 Stockholm >> Tel: 08-790 66 98 >> http://www.csc.kth.se >> http://nepomuk.semanticdesktop.org >> >> >> _______________________________________________ >> swikig mailing list >> sw...@ai... >> http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig >> >> > > _______________________________________________ > swikig mailing list > sw...@ai... > http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig > > -- Sebastian | Dr. Sebastian Schaffert seb...@sa... | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Knowledge Based Information Systems +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg PGP Key fingerprint = 13 1D 2E 4F 20 3E C9 1F 4C 57 52 87 8A 80 48 4D F5 E9 97 EC |
From: David K. <ka...@mi...> - 2007-04-27 12:29:15
|
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. and...@se... 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) >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Blanchard, Duane L [mailto:Dua...@bo...] >>>> Sent: Thursday, April 26, 2007 11:10 AM >>>> To: Uschold, Michael F; Daniel Schwabe >>>> Cc: ba...@ba...; Kelly Jones; Jones, David H; >>>> sem...@li...; Murray, William R; >>>> sw...@ai...; Mark Greaves; >>>> csh...@vi... >>>> Subject: RE: Creating Triples Anywhere in a Semantic Wiki '' >>>> >>>> See additional inline comments.... >>>> >>>> Thx, >>>> >>>> D >>>> >>>> ---- >>>> Duane L. Blanchard >>>> Computational Linguist >>>> Phantom Works - Mathematics & Computing Technology >>>> 425.373.2800 >>>> >>>> To pick up on this topic, Mike, could you clarify then what >>>> you have in >>>> mind when you think of a "wiki page"? >>>> >>>> MU: good question. I guess I mean when I click on a wiki concept, like >>>> say "Bob" and now I'm on Bob's page. Or I might be on the page for the >>>> wiki concept: Idaho. >>>> >>>> DB: Same here, but perhaps the question should be rephrased as what is >>>> the relation between a wiki page and an entity or a triple in >>>> your mind. >>>> -- >>>> >>>> Is it just a place to hold an exchange of information (analogous to a >>>> "thread" in a forum)? If so, what does it mean to attach an >>>> attribution >>>> (a triple) to this page - >>>> should I interpret that all triples have the page as subject, >>>> which is a >>>> resource in some sense, and the meaning is whatever you >>>> assign to these >>>> triples? >>>> >>>> >>>> MU: this is what Semantic Media Wiki assumes, as I understand it. That >>>> is why in the triples in the markup, you don't have the subject >>>> explicitly there, it is assumed. In which case the page only >>>> really has >>>> doubles there explicitly, not triples. >>>> >>>> This assumption makes it impossible to add a real triple that >>>> relates to >>>> something else. >>>> >>>> DB: This is correct for Semantic Media Wiki. Each page is a >>>> concept and >>>> each relation on that page uses this concept as it subject. >>>> >>>> DB: Mike, more please on attaching a triple to a page, or to the wiki >>>> but not to a page. >>>> -- >>>> >>>> Is it supposed to encapsulate some kind of concept or set of >>>> concepts - >>>> then the triples be interpreted as statements about these concepts? >>>> Must it be in some sense "self-contained" - relative to some >>>> discourse, >>>> or relative to some conceptualization schema? >>>> I'd be very interested in knowing more the requirements (and >>>> scenarios) >>>> you seem to have in mind when you state that "that's why I stopped >>>> trying to use the tool"... what kind of applicaton do you need? >>>> >>>> MU: I want to create a wiki page, classify that page as being an >>>> instance of some class. >>>> So say I create a page for Bob, he is an instance of Person. On that >>>> page, I want to be able to write unstructured text. Like Bob lives in >>>> Idaho. And to be able to create a triple that says that. And I also >>>> mention Montana in the text, and while I'm thinking about it, Idaho >>>> borders on Montana. So from the web page, I want to be able to create >>>> Idaho and Montana as wiki concepts. Then I want to select >>>> each of them, >>>> and then choose among a set of relationships which includes bordersOn >>>> and set that relationship between these two concepts. >>>> >>>> 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. >>>> >>>> Furthermore, the system now should know that Idaho and >>>> Montana are say, >>>> regions from the domain and range constraints of bordersOn**. >>>> >>>> ** Lets ignore the fact that a state is a political entity, and has an >>>> associated region. That's an ontology issue, not a tool issue. >>>> >>>> DB: Mike, it seems, from my limited exposure, that this is how Visual >>>> Knowledge operates. If you create a triple, but don't >>>> associate it with >>>> any page, how do you later make changes to that triple? In >>>> SemMedWiki, I >>>> would go to the page that is the implicit subject and make the change >>>> there. >>>> >>>> DB: In VK, are only pages instances of classes, or can instances exist >>>> without also being pages? >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> swikig mailing list >> sw...@ai... >> http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig >> >> >> >> > > _______________________________________________ > swikig mailing list > sw...@ai... > http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig > > |
From: Jack P. <jac...@sr...> - 2007-04-27 14:48:04
|
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. > > and...@se... 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) >>>> |
From: <par...@me...> - 2007-04-27 15:28:29
|
27 apr 2007 kl. 13.19 skrev and...@se...: > 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. I second that. On the one hand, the page-centric approach means simplicity and ease =20 of use, which won't hurt the Semantic Web at all. On the other hand, when we discussed these matters in the Nepomuk =20 project, somebody (Max? Malte Kiesel?) provided the following problem =20= description regarding the page-centric approach: "Imagine a large table that lists 100 products along with a short description and price. In order to express this in a semantic wiki that identifies a page with a resource, one gets forced to create 100 =20= wiki pages, one for each row of the table, both cluttering title index and recent changes pages. " Preferrably, a semantic wiki should allow very simple page-centric =20 statements as well as arbitrary triples. How can the two approaches best be combined? Best regards from a sunny Stockholm P=E4r Lanner=F6 par...@me... Mobil: 073-944 20 43 METAMATRIX // INTERFOLIO Sveav=E4gen 31, 3 tr, 111 34 Stockholm Tel: 08-50 65 33 43 http://www.metamatrix.se KTH // NEPOMUK Lindstedtsv=E4gen 3, 6 tr, 100 44 Stockholm Tel: 08-790 66 98 http://www.csc.kth.se http://nepomuk.semanticdesktop.org |
From: <and...@se...> - 2007-04-27 17:02:41
|
> > On the other hand, when we discussed these matters in the Nepomuk > project, somebody (Max? Malte Kiesel?) provided the following problem > description regarding the page-centric approach: > > "Imagine a large table that lists 100 products along with a > short description and price. In order to express this in a semantic wiki > that identifies a page with a resource, one gets forced to create 100 wiki > pages, one for each row of the table, both cluttering title index and > recent changes pages. " > Imagine this even simpler scenario - and very common - I suppose: I edit a page (subject) and I want to state a relation with an unexisting page, e.g. (Edgar Varese) [[owns a dog::/Bobby (dog)]]. I have nothing to say about [[Edgar Varese/Bobby (dog)]], so --> I will not edit that page. Nevertheless [[Edgar Varese/Bobby (dog)]] is part of a semantic relation, so it 'exists' in some way. Possibly, it is even the subject of the inverse relation 'owned by'. Let imagine that Varese [[dedicated to::/Bobby (dog)]] some composition, and some [[was inspired by::/Bobby (dog)]]' woof. Now the semantic wiki says that [[/Bobby (dog)]] is pretty important in the history of music, but nevertheless it has not a wiki page ... (!). So, maybe a possible behaviour for a semantic wiki could be: --> to make virtually 'existing' any page that is part of a relation, even if it is empty. Possible (simple) implementation: when showing an empty page, shoe also the list of relation having this page as an object (before or after the textarea box). ... Well, this is pretty similar to just ckick the 'what links here' button: in fact it is probably not a challenging feature... PS. BTW, the parsing of [[relation with::/subpage]] fails .... :-) > Preferrably, a semantic wiki should allow very simple page-centric > statements as well as arbitrary triples. > How can the two approaches best be combined? > > > Best regards from a sunny Stockholm > > > Pär Lannerö > par...@me... > Mobil: 073-944 20 43 > > METAMATRIX // INTERFOLIO > Sveavägen 31, 3 tr, 111 34 Stockholm > Tel: 08-50 65 33 43 > http://www.metamatrix.se > > KTH // NEPOMUK > Lindstedtsvägen 3, 6 tr, 100 44 Stockholm > Tel: 08-790 66 98 > http://www.csc.kth.se > http://nepomuk.semanticdesktop.org > > > > |
From: Markus <ma...@ai...> - 2007-04-28 14:18:41
|
Hi all! Not replying to any contribution to this interesting discussion in particul= ar,=20 here are some of my views (which are currently very close to "Semantic=20 MediaWiki's views" ;-). =3D=3D Separating pages and triples/axioms =3D=3D (1) "Relevant semantic content should be (read) accessible in many contexts= ,=20 not just where it was created." : I agree. SMW now has a simple data browser that shows all data relating t= o=20 some page, not just the data entered on that page. And there are many other= =20 ways to read semantic data in many contexts. (2) "Some semantic data should be decoupled from concrete pages." : Yes, probably. Take the disjointness of two classes as expressed in OWL.= =20 Even if you have pages for both classes, you cannot cleave the axiom to=20 either of them. Note how this is different from cases like subclass (or=20 subcategory) axioms, where you can just decide to make one of the involved= =20 classes the distinguished page to put such an axiom on. Users quickly learn= =20 this (at least I never heard a proposal to decouple subcategory statements= =20 from pages in MediaWiki). (3) "All semantic data should be decoupled from any concrete pages wiki tex= t." : No idea. There are many known pros and cons for this. SMW has made its=20 design decision a long time ago, but maybe some future version will offer=20 full decoupling as an option (given that an extension of (2) is implemented= =20 one can always disable all annotation syntax). (4) "In the text of a single page, it should be possible to describe=20 annotations about any other page." : At least for MediaWiki, this is technical suicide. If annotations in many= =20 pages' source texts would affect the same issue, one would have to change a= ll=20 of those pages' contents when a user edits one. This requires you to find o= ut=20 where in the source code a statement was made and how it can be changed. In= =20 MediaWiki, you can have multi-level transclusion of pages (templates etc.)= =20 combined with conditionals, automated string manipulations, and usage of da= ta=20 from external sources, all of which are not constrained by a well-defined=20 syntax but are mere concatenations of operational preprocessing steps on=20 plain text. In general, it is not possible to automatically manipulate this= =20 syntax to a predictable effect. If you want some semantic data editable on many pages, you better decouple = it=20 first from the wiki texts. Of course this also says: please be careful when= =20 designing the next wiki engine that might become a market leader ... (5) "When viewing an annotation somewhere in the wiki, one should directly = be=20 able to edit it." : This faces the same problems as (4), so it would need complete decoupling= of=20 semantics and wiki text, or a very cleanly designed wiki engine. Anyway, on= e=20 should keep in mind that most users of many wikis are readers. Offering edi= t=20 buttons/widgets for every single fact may be more irritating to them than i= t=20 is helpful to the wiki authors. =3D=3D Capturing auxiliary triples =3D=3D (6) "The wiki should support the annotation of many different items (e.g. f= rom=20 the Long List) that are given in one page." : Probably yes, though some details must be discussed there. This use case= =20 suggests to specify many subjects on one page, but those subjects might wel= l=20 be local to the page. This does not require strong decoupling of annotation= s=20 and pages, since triples still can be accessed only from one page where the= y=20 appear as "sub-subjects". (7) "The wiki should provide special support for common modelling tasks, wh= ere=20 one otherwise would have to create 'auxiliary' pages." : Yes, at least in certain cases. For instance, we have already discussed=20 earlier on semediawiki-devel the possible support for n-ary relations in SM= W.=20 In OWL and RDF, modelling n-ary relations requires the use of auxiliary fac= ts=20 that are often not suitable for explicit representation in a wiki. But=20 instead of allowing users to manually create auxiliary resources on one pag= e=20 manually, the system probably should rather just accept some n-ary annotati= on=20 and internally create a suitable structure. SMW is approaching some of those issues for future releases, but=20 implementation in a real system typically is much more work than designing = a=20 nice principle solution. Cheers, Markus =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: Uschold, M. F <mic...@bo...> - 2007-04-29 23:22:26
|
Thanks for this input. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Michael Uschold M&CT, Phantom Works 425 373-2845 mic...@bo...=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D ---------------------------------------------------- COOL TIP: to skip the phone menu tree and get a human on the phone, go = to: http://gethuman.com/tips.html -----Original Message----- From: Markus Kr=F6tzsch [mailto:ma...@ai...] Sent: Saturday, April 28, 2007 7:18 AM To: sem...@li... Cc: sw...@ai... Subject: Re: [swikig] [Semediawiki-user] Creating Triples Anywhere in = aSemantic Wiki Hi all! Not replying to any contribution to this interesting discussion in = particular, here are some of my views (which are currently very close to = "Semantic MediaWiki's views" ;-). =3D=3D Separating pages and triples/axioms =3D=3D (1) "Relevant semantic content should be (read) accessible in many = contexts, not just where it was created." : I agree. SMW now has a simple data browser that shows all data = relating to some page, not just the data entered on that page. And there = are many other ways to read semantic data in many contexts. (2) "Some semantic data should be decoupled from concrete pages." : Yes, probably. Take the disjointness of two classes as expressed in = OWL. Even if you have pages for both classes, you cannot cleave the axiom to = either of them. Note how this is different from cases like subclass (or subcategory) axioms, where you can just decide to make one of the = involved classes the distinguished page to put such an axiom on. Users = quickly learn this (at least I never heard a proposal to decouple = subcategory statements from pages in MediaWiki). MU: What if I'm on a class, I might want to specify a new superclass. = Are you saying I have to go to the superclass and specify the subclass = there? How can the developer know in advance how a user is thinking? = Sure, you can force users to do things in a certain way that you 'just = decide' but now you make their life difficult. =20 I'm a decent guy and like to do my share, so I'm willing to put in some = suffering for a good cause. What is that good cause? Who benefits from from this design decision?=20 For example, if I'm the only one of millions of users who even cares = about this issue, then clearly there is a benefit both to developers who = have less work to do, and to [all other] users who benefit from = developers spending their time on more important things. -- (3) "All semantic data should be decoupled from any concrete pages wiki = text." : No idea. There are many known pros and cons for this. SMW has made its = design decision a long time ago, but maybe some future version will = offer full decoupling as an option (given that an extension of (2) is = implemented one can always disable all annotation syntax). MU: Ok, the coupling is a result of a prior design decision, perhaps it = is just too deeply embedded to change. =20 -- (4) "In the text of a single page, it should be possible to describe = annotations about any other page." : At least for MediaWiki, this is technical suicide. If annotations in = many pages' source texts... MU: I assume you mean "semantic annotation" i.e. triple. If not, then = ignore this. Here is where we are not on the same page. Current implementation = decisions may require it, but I don't require the semantic annotations = to be IN A SOURCE PAGE. Perhaps they could be in a back end, and = visible when needed. -- ...would affect the same issue, one would have to change all of those = pages' contents when a user edits one. This requires you to find out = where in the source code a statement was made and how it can be changed. = In MediaWiki, you can have multi-level transclusion of pages (templates = etc.) combined with conditionals, automated string manipulations, and = usage of data from external sources, all of which are not constrained by = a well-defined syntax but are mere concatenations of operational = preprocessing steps on plain text. In general, it is not possible to = automatically manipulate this syntax to a predictable effect. MU: this is now out of my technical depth. The punch line seems to be = that with the current code infrastructure, it is not possible or = practical. If so, maybe I'm just out of luck. -- If you want some semantic data editable on many pages, you better = decouple it first from the wiki texts. MU: perhaps this what I'm advocating, and maybe it is impractical. -- Of course this also says: please be careful when designing the next wiki = engine that might become a market leader ... (5) "When viewing an annotation somewhere in the wiki, one should = directly be able to edit it." : This faces the same problems as (4), so it would need complete = decoupling of semantics and wiki text, or a very cleanly designed wiki = engine. Anyway, one should keep in mind that most users of many wikis = are readers. Offering edit buttons/widgets for every single fact may be = more irritating to them than it is helpful to the wiki authors. MU: yes ther are tradeoffs, and different users will have different = preferences. =3D=3D Capturing auxiliary triples =3D=3D (6) "The wiki should support the annotation of many different items = (e.g. from the Long List) that are given in one page." : Probably yes, though some details must be discussed there. This use = case suggests to specify many subjects on one page, but those subjects = might well be local to the page. This does not require strong decoupling = of annotations and pages, since triples still can be accessed only from = one page where they appear as "sub-subjects". (7) "The wiki should provide special support for common modelling tasks, = where one otherwise would have to create 'auxiliary' pages." : Yes, at least in certain cases. For instance, we have already = discussed earlier on semediawiki-devel the possible support for n-ary = relations in SMW. In OWL and RDF, modelling n-ary relations requires the use of auxiliary = facts that are often not suitable for explicit representation in a wiki. = But instead of allowing users to manually create auxiliary resources on = one page manually, the system probably should rather just accept some = n-ary annotation and internally create a suitable structure. SMW is approaching some of those issues for future releases, but = implementation in a real system typically is much more work than = designing a nice principle solution. MU: yes indeed, I'm just a user and I just want you to wave a wand and = have it in the next release. :-)) Cheers, Markus -- Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: David K. <ka...@mi...> - 2007-04-27 16:30:05
|
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. >> >> and...@se... 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) >>>>> |
From: Uschold, M. F <mic...@bo...> - 2007-04-27 16:35:03
|
Well stated and elaborated - this is pretty much what I have in mind. Exactly how the editing takes place, as you note, remains an open question with many possible answers. Michael =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Michael Uschold M&CT, Phantom Works=20 425 373-2845 mic...@bo... =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D ---------------------------------------------------- COOL TIP: to skip the phone menu tree and get a human on the phone, go to: http://gethuman.com/tips.html=20 -----Original Message----- From: David Karger [mailto:ka...@mi...]=20 Sent: Friday, April 27, 2007 9:30 AM To: Jack Park Cc: sem...@li...; sw...@ai... Subject: Re: [swikig] Creating Triples Anywhere in a Semantic Wiki '' 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"=20 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.=20 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.=20 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=20 > mean that the triple *itself* is a singleton and has just been=20 > 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=20 > does not affect other instances of the same statement? > > I've been watching this thread with the "topic maps" context in mind,=20 > 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=20 > pretty limited, given that a "page" would be a=20 > representation/carrier/whatever for a *subject* -- doesn't matter what > that subject is: it could just be a collection of representations of=20 > other subjects, as for example, the "first steps" page at the apache=20 > jackrabbit wiki; the subject of that page is just that: examples, each > of which is, itself, another subject(s). (note to self: gotta watch=20 > 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=20 > sense, a slot or slots in the frame. Said slots could be triples,=20 > text, HREFs, whatever. That's just the view I take of a page. Your=20 > mileage might vary. > > Cheers > Jack > > David Karger wrote: >> I would argue that a given triple can naturally show up in many=20 >> different context---on the page associated with its subject, on the=20 >> page associated with its object, and on a variety of pages=20 >> 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=20 >> all you can do with a triple is create one or delete one. It seems=20 >> 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=20 >> with the subject of the page, but as in the example that started all=20 >> this, they may be prompted to create a bunch of "supporting" triples=20 >> 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=20 >> for a user to delete it---this seems doable, by having the wiki=20 >> compare the original text to the edited text, identify triples that=20 >> are no longer present, and remove them from the triple store. >> >> and...@se... wrote: >>> (sorry for multiple copies - honestly this thread has too many To:=20 >>> 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=20 >>> triples would be convenient. >>> However, these should be, IMHO, confined in pages without subject,=20 >>> or with multiple subject. >>> >>> To attempt a parallel with the 'unplugged' wiki, there are=20 >>> 'encyclopedic' pages on specific subjects like [[Edgar Varese]], and >>> 'flow of thought' pages like [[Influence of Varese music in Frank=20 >>> 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=20 >>> the style suggested by >>> http://www.wikisophia.org/wiki/Wikitex. >>> >>> Andrea >>> >>> >>> Daniel Schwabe ha scritto: >>> =20 >>>> 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=20 >>>> collective production and editing of knowledge, by technically=20 >>>> untrained people. To some, this knowledge as being represented as=20 >>>> triples. Others view it as being represented in the text itself=20 >>>> (hence, not really processable), and still others may see it as a=20 >>>> combination of both. >>>> The first alternative does not really look like a wiki as most=20 >>>> people would think of it; I suspect the third one is the more=20 >>>> common understanding of what a "semantic wiki" would be. >>>> (Btw, I don't see such an advantage to regard a wiki as simply a=20 >>>> "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=20 >>>> alternatives before it is clear which paradigm is being followed,=20 >>>> If you take the first point of view, I'd tend to agree with Mark's=20 >>>> 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=20 >>>> bit more explicit; I'd like to understand better how is the formal=20 >>>> (i.e. triples) knowledge is being created, edited AND USED in the=20 >>>> first and third alternatives above. >>>> So, in summary, what is (more precisely) the problem being=20 >>>> addressed in using the wiki? >>>> >>>> On 26/4/2007 19:39, Mark Greaves wrote: >>>> =20 >>>>> Mike, >>>>> >>>>> =20 >>>>>> Now I have a triple. I don't care where it is stored, it can be=20 >>>>>> 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. =20 >>>>>> =20 >>>>> I disagree with this. In order for triples to enjoy the benefits=20 >>>>> of social editing and the social identification and correction of=20 >>>>> errors, they have to be simple to find, examine, and edit by a=20 >>>>> large number of relatively untrained people. In order to maximize >>>>> the number of people who can access/edit the triples, the process=20 >>>>> of locating and editing the triples needs to be as parallel as=20 >>>>> possible to the already-known process for making corrections to=20 >>>>> ordinary wikitext. So, rather than force triple-editing to go=20 >>>>> through some kind of searchbox interface, it makes more sense to=20 >>>>> me to make the triples embed in the wikitext of the subject page. >>>>> Furthermore, this strategy allows for a natural way of using=20 >>>>> 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=20 >>>>> more cumbersome. Nevertheless, I think it is consistent with the=20 >>>>> 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) >>>>> _______________________________________________ swikig mailing list sw...@ai... http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig |
From: Jack P. <jac...@sr...> - 2007-04-27 17:16:29
|
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. >>> >>> and...@se... 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) >>>>>> |
From: David K. <ka...@mi...> - 2007-04-27 18:06:03
|
Well, I don't see a change from Jack to John as a change to a triple. The closest I can come is to consider the triple http://something-representing-jack-park prefered-name "Jack" being deleted and replaced with http://something-representing-jack-park prefered-name "John" My absolutist principle (which may not survive contact with reality) would be that any page using the first triple (eg, the org chart page, which uses it to decide what name to put in a box of the org chart) should allow the user to make that change (deletion/insertion). I think this matches what you say about transclusion. Jack Park wrote: > 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. >>>> >>>> and...@se... 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) >>>>>>> > |