Re: [Semediawiki-user] [swikig] Creating Triples Anywhere in a Semantic Wiki ''

[David K. <ka...@mi...>]

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)
>>>>>>>
>