> What you suggest is a very limited approach to navigation for triples.
> I can imagine a wide variety of different ways to locate and edit a > triple, e.g.: > - at the object > - at a page describing the property > - at a page describing the class of the subject > - at a page describing the class of the subject > - at domain specific editors that allow to perform more complex > metadata operations (RDF is just like assembler - why should I need to > work directly with triples?) Exactly. Of course you don't want three independent copies of the same triple three different places. It could be in one place, (e.g. a triple store of some sort). If you are on a page describing the property, or the subject or object of the triple, then the wiki can go find the triples when it shows a page, and present them, so they are virtually in three different places. ========================== Michael Uschold M&CT, Phantom Works 425 373-2845 [EMAIL PROTECTED] ========================== ---------------------------------------------------- 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: Jochen Schmidt [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 4:15 AM To: Sebastian Schaffert Cc: Jones, David H; semediawiki-user@lists.sourceforge.net; Blanchard, Duane L; Mark Greaves; Murray, William R; [EMAIL PROTECTED] Subject: Re: [swikig] Creating Triples Anywhere in a Semantic Wiki '' Am 27.04.2007 um 09:29 schrieb Sebastian Schaffert: > Mark Greaves schrieb: >> 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. > > Why the subject and not e.g. the object? > > What you suggest is a very limited approach to navigation for triples. > I can imagine a wide variety of different ways to locate and edit a > triple, e.g.: > - at the object > - at a page describing the property > - at a page describing the class of the subject > - at a page describing the class of the subject > - at domain specific editors that allow to perform more complex > metadata operations (RDF is just like assembler - why should I need to > work directly with triples?) > (Sorry for quoting the whole thing again.) I can (partially) agree to both arguments. It is IMHO a good idea to make the process of finding and editing triples (better "statements"?) to be as parallel as possible. This is why I prefer to annotate directly in the wiki-text and not for example have the wiki text and the metadata separated. Separating metadata from the wiki- content makes the whole thing look like a sticky tape prototype and can easily lead to the semantic wiki equivalent of a "split brain syndrome". As I said some time ago; this doesn't mean that one has to use markup-syntax, which is a completely orthogonal issue. It's works quite well to have a WYSIWYG editor with special commands to handle the annotation. I agree, that restricting the annotation by attaching triples only to their subject-pages is a quite limited way. There is a very interesting use case in being able to add triples to a wiki-page (a resource) from other sources. Think about describing resources to which you do not have the rights or possibility to edit. This way you can e. g. also describe external resources in the wiki without relying on crude owl:sameAs mappings. -- Jochen Schmidt [EMAIL PROTECTED] http://www.codeartist.org _______________________________________________ swikig mailing list [EMAIL PROTECTED] http://www.aifb.uni-karlsruhe.de/mailman/listinfo/swikig ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Semediawiki-user mailing list Semediawiki-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user
