From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 05:57:58 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id EA8F356FF7; Sat, 8 Mar 2003 05:57:57 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by bi0.bootstrap.org (Postfix) with SMTP id 7E27256FF5 for ; Sat, 8 Mar 2003 05:57:55 -0800 (PST) Received: (qmail 26873 invoked by uid 0); 8 Mar 2003 14:18:42 -0000 Received: from p5082D447.dip.t-dialin.net (HELO gmx.de) (80.130.212.71) by mail.gmx.net (mp019-rz3) with SMTP; 8 Mar 2003 14:18:42 -0000 Message-ID: <3E69FBB7.1010909@gmx.de> Date: Sat, 08 Mar 2003 15:18:31 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: Eugene Eric Kim , ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Dear Eugene, Toni Alatalo pointed me to your paper, `Towards a Standard Graph-Based Data Model for the Open Hyperdocument System`__. You make the point that a standard graph-based model could allow different applications to be integrated into a single whole. You say that RDF is one possible choice for a modeling language, but reject it because of its complicated syntax. __ http://www.eekim.com/ohs/papers/graphmodel/ The Fenfire project (formerly `Gzz`_, formerly GZigZag), which I'm a developer on, has recently `adopted`_ RDF as its model (i.e., all data is stored in RDF). .. _Gzz: http://savannah.nongnu.org/projects/gzz/ .. _adopted: http://mail.nongnu.org/archive/html/gzz-dev/2003-02/msg00058.html Our aim is very close to what you describe; we want information from any application on a computer system (or network) to be available for linking with information from any other application, in any linking structure (for example IBIS discussion). For a person I'm in contact with, there should be a single node on my computer, connected to their address, their birthday, my appointments with them, emails I received from them, photos of them, and so on. (We originally intended to implement this vision based on Ted Nelson's zzstructure, but we had to stop using that due to `patent problems`_. Toni has `noticed`_ that zzstructure was avoided by (some in) the OHS community `because of the patent`_.) .. _patent problems: http://mail.nongnu.org/archive/html/gzz-dev/2003-02/msg00042.html .. _noticed: http://mail.nongnu.org/archive/html/gzz-dev/2003-02/msg00130.html .. _because of the patent: http://www.bootstrap.org/lists/ba-ohs-talk/0204/msg00187.html So, I'm hoping for some discussion about whether RDF is the right choice for these goals. Your concern about RDF is the RDF/XML serialization syntax. However, the RDF model is specified independently (`Concepts and Abstract Syntax`_) from its serialization (`RDF/XML Syntax Specification`_). .. _Concepts and Abstract Syntax: http://www.w3.org/TR/rdf-concepts/ .. _RDF/XML Syntax Specification: http://www.w3.org/TR/rdf-syntax-grammar/ It is entirely possible to specify an alternate syntax for RDF, though RDF/XML is of course prefered as the standard. `N3`_ (Notation 3) is another syntax of RDF in actual use, designed to be practical to read and write for humans. There is ongoing work about XML `Schema annotations`_ allowing any schema-conforming XML to be interpreted as RDF. For Fenfire, we need a canonical format for RDF graphs, so that equal RDF graphs are always serialized to the same byte sequence; we might invent our own serialization language for that. .. _N3: http://www.w3.org/2000/10/swap/Primer .. _Schema annotations: http://www.w3.org/2003/02/schema-annotation.html You `propose`_ `GSIX`_ and `GXL`_ as possible alternatives to RDF. I must admit that I have not surveyed the two as thoroughly as RDF, but from my cursory looks, I've felt that RDF is better suited to our goals (Fenfire's, and maybe also yours) than either of them. .. _propose: http://www.eekim.com/ohs/papers/graphmodel/#nid074 .. _GSIX: http://www.concept67.fsnet.co.uk/gsix/ .. _GXL: http://www.gupro.de/GXL/ Firstly, RDF's stated goal is that "Anybody can say anything about anything." To archieve this goal, it uses URIs to identify both nodes and edge types. This provides-- Orthogonality Two applications can say things about the same node without ever knowing about each other. Since each has its own set of properties (graph edge types), neither 'sees' or inteferes with the other's. This allows different structures to overlap, as you `too describe`__. __ http://www.eekim.com/ohs/papers/graphmodel/#nid066 Location-independent links A node identified by a URI can appear in different graphs-- for example, my personal information manager, your design proposal, and an email to this list. When I view the mail, I see my personal connections to the nodes appearing in it; when you view it, you see yours. Anybody can publish links to it without modifying the original context (e.g. the mail). This seems pretty essential for a hypertext/hypermedia system. From my cursory look, it seems that GXL uses URIs for edges (thus providing orthogonality) but not for nodes (thus not providing location-independent links). GSIX seems to use local identifiers for both edges and nodes. Secondly, RDF has a really simple model. Here's my summary (I'm structuring into 'steps' for easier understandability-- step 3 is the real model): Step 1. A directed labelled graph where each node is a URI (actually, URIref-- it can contain a fragment identifier), and each arc is labelled by a URI. In other words, a set of triples of URIs. Triples are interpreted as [subject, predicate, object]. Step 2. In addition to step 1, the objects of triples can be *literals* instead of URIs. A literal is a Unicode string, with an optional datatype (URIref) and an optional language attribute ('de', 'fi' etc). Step 3. In addition to step 2, the subjects and objects of triples can be *blank nodes*. A blank node is like a URIref, but local to a graph (if you join two graphs, the blank nodes in each one are different). GSIX seems to be reasonably simple, too-- it has 'wildcard placeholders' and 'cspaces' which I haven't taken the time to understand, but I suppose it would still be ok. GXL, on the other hand, tries to express *any* graph-- directed, labelled, attributed, hierarchical, whatnot. For Fenfire, we want a very simple model because we want moderately skilled users to learn it and use it to their own benefits. We don't want users to be locked into expressing those kinds of associations some programmer or designer came up with; rather, when they find they have a need for expressing their own kind of structure/relationships, they should be able to do so. And all structures should be viewable in a single 'structure editor' (even though we'll have all sorts of different views for application-specific data which you can switch forth and back between-- we share the OHS's vision here). I also believe that having e.g. attributes on nodes in addition to connections on nodes (as possible in GXL) is exactly wrong, because it doesn't allow different applications to add other attributes, orthogonally. In RDF, all attributes would be represented as properties (edges in the graph). This way of expressing the same information is orthogonal as defined above. The simplicity is also a reason for me to favor RDF over Nodal: in Nodal, you have predefined types like sequence or map; in RDF, the same information is expressed, but in terms of a very simple underlying structure (which also provides for orthogonality and location-independent links). Finally, RDF has a user community-- not as big as XML, but there are e.g. extensive libraries for Java, Python or C, and there's a lot of research going on based on it. There are parsers and writers, schema languages and tools for checking conformance to a schema, there are defined vocabularies (i.e., sets of relationships and nodes with an assigned meaning), etc. I even hope that we'll profit from the work being done w.r.t. semantics: If tools are developed for translating one web service's RDF vocabulary to another's, these tools should be usable to translate one hypertext application's vocabulary into another's; for example, we could use a view developed for one vocabulary to view data stored in another. If the work on XML Schema annotations takes off, we can access XML data from our system without building additional conversion tools. So these are reasons for us selecting RDF-- *orthogonality*, *location-independent links* and *simple structure* being probably the most important. I'm hoping for and am looking forward to discussion. - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 06:51:52 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 9267956FF7; Sat, 8 Mar 2003 06:51:51 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp3.cp.tin.it (vsmtp3.tin.it [212.216.176.223]) by bi0.bootstrap.org (Postfix) with SMTP id 1D14456FF5 for ; Sat, 8 Mar 2003 06:51:47 -0800 (PST) Received: from trotter (213.45.119.187) by smtp3.cp.tin.it (6.5.033) id 3E48CE9F009E789D; Sat, 8 Mar 2003 16:12:24 +0100 From: "Danny Ayers" To: , "Eugene Eric Kim" Cc: "GZZ developers" Subject: RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Sat, 8 Mar 2003 16:11:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3E69FBB7.1010909@gmx.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Benja, > Toni Alatalo pointed me to your paper, `Towards a Standard Graph-Based > Data Model for the Open Hyperdocument System`__. You make the point that > a standard graph-based model could allow different applications to be > integrated into a single whole. You say that RDF is one possible choice > for a modeling language, but reject it because of its complicated syntax. > > __ http://www.eekim.com/ohs/papers/graphmodel/ I couldn't find the 'rejection' bit on a skim of Eugene's paper...but whatever, I'm getting the impression that an implementation of an OHS is actually well on its way, primarily using the RDF model. Pretty much daily I'm coming across new RDF-based systems that focus on different aspects of the general problem (many blogged at [1]), and these may considered as a whole thanks to the shared language - there are obviously other models in use for this kind of thing (notably TM) but I think RDF is likely to emerge as the common language, largely thanks to its lowest-common-denominator statement representation. In other words, the development itself is distributed - which seems quite natural really. I can't remember seeing anyone taking the zigzag idea specifically and putting it in RDF, so it'll be interesting what happens with Gzz/Fenfire along these lines. I note that Fenfire is described as a hyperstructured UI - this will be good to see, as UI development is lagging behind in RDF developments. > Our aim is very close to what you describe; we want information from any > application on a computer system (or network) to be available for > linking with information from any other application, in any linking > structure (for example IBIS discussion). For a person I'm in contact > with, there should be a single node on my computer, connected to their > address, their birthday, my appointments with them, emails I received > from them, photos of them, and so on. That would be a foaf:Person [2] I take it? > So, I'm hoping for some discussion about whether RDF is the right choice > for these goals. Your concern about RDF is the RDF/XML serialization > syntax. However, the RDF model is specified independently (`Concepts and > Abstract Syntax`_) from its serialization (`RDF/XML Syntax > Specification`_). Quite. An awful lot of the naysaying about RDF on xml-dev and elsewhere has been a direct result of the ugly serialization - the model is relatively simple & (reasonably!) elegant, yet powerful enough to do what's required - I for one think it's the best choice of the current field. For Fenfire, we need a canonical format for RDF graphs, so that > equal RDF graphs are always serialized to the same byte sequence; we > might invent our own serialization language for that. Why do you need the same byte sequence? Anyhow it should be pretty straightforward to achieve - e.g. alphabetically sorted nTriples. > From my cursory look, it seems that GXL uses URIs for edges (thus > providing orthogonality) but not for nodes (thus not providing > location-independent links). GSIX seems to use local identifiers for > both edges and nodes. As well as a way of defining nodes and arcs, a means of unambiguously binding semantics to them is required, and I reckon that if you applied this step to something like GXL you would end up with something along the same lines as RDF. (I'm not familiar with GSIX) ...all structures should be viewable in a > single 'structure editor' (even though we'll have all sorts of different > views for application-specific data which you can switch forth and back > between-- we share the OHS's vision here). Ideagraph [3] is my own take on this, and I agree absolutely with your reasoning behind the use of RDF (though am too lazy to express it myself ;-) Cheers, Danny. [1] Semantic Web blog http://www.citnames.com/blog [2] 'Friend of a friend' vocabulary http://xmlns.com/foaf/0.1/ [3] http://ideagraph.net From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 07:04:23 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 32ADE57007; Sat, 8 Mar 2003 07:04:22 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 0F58B56FF7 for ; Sat, 8 Mar 2003 07:04:19 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h28FP32N025073; Sat, 8 Mar 2003 17:25:04 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h28FP3cs025070; Sat, 8 Mar 2003 17:25:03 +0200 Date: Sat, 8 Mar 2003 17:25:03 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sat, 8 Mar 2003, Danny Ayers wrote: > Hi Benja, > > __ http://www.eekim.com/ohs/papers/graphmodel/ > I couldn't find the 'rejection' bit on a skim of Eugene's paper...but Benja hasn't learned to use purple numbers yet ;) http://www.eekim.com/ohs/papers/graphmodel/#hid5B includes: "the complicated syntax would likely be a barrier to using RDF as a general data modeling language." > whatever, I'm getting the impression that an implementation of an OHS is > actually well on its way, primarily using the RDF model. Pretty much daily interesting point. > along these lines. I note that Fenfire is described as a hyperstructured > UI - this will be good to see, as UI development is lagging behind in RDF I've personally been a mere lurker in that area, and sometimes have wondered the strong focus there (the guys have gone pretty deep in utilising latest OpenGL extensions etc.), but totally agree that we desparately need new UIs. > Ideagraph [3] is my own take on this, and I agree absolutely with your that was probably the first i tried, thanks for sharing it :) > Danny. ~Toni From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 09:20:13 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 0E76B56FF7; Sat, 8 Mar 2003 09:20:12 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by bi0.bootstrap.org (Postfix) with SMTP id E352956FF5 for ; Sat, 8 Mar 2003 09:20:10 -0800 (PST) Received: (qmail 4672 invoked by uid 0); 8 Mar 2003 17:41:01 -0000 Received: from p5082D4B2.dip.t-dialin.net (HELO gmx.de) (80.130.212.178) by mail.gmx.net (mp017-rz3) with SMTP; 8 Mar 2003 17:41:01 -0000 Message-ID: <3E6A2B27.80203@gmx.de> Date: Sat, 08 Mar 2003 18:40:55 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: Danny Ayers Cc: ba-ohs-talk@bootstrap.org, GZZ developers Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Danny, Danny Ayers wrote: >>Toni Alatalo pointed me to your paper, `Towards a Standard Graph-Based >>Data Model for the Open Hyperdocument System`__. You make the point that >>a standard graph-based model could allow different applications to be >>integrated into a single whole. You say that RDF is one possible choice >>for a modeling language, but reject it because of its complicated syntax. >> >>__ http://www.eekim.com/ohs/papers/graphmodel/ > > > I couldn't find the 'rejection' bit on a skim of Eugene's paper... Toni's pointed to it-- http://www.eekim.com/ohs/papers/graphmodel/#hid5B > but whatever, I'm getting the impression that an implementation of an OHS is > actually well on its way, primarily using the RDF model. Pretty much dail > I'm coming across new RDF-based systems that focus on different aspects of > the general problem (many blogged at [1]), Cool. I have had a short look at your blog before, but need to look deeper. What do you think about having a mailing list where these get posted & we can discuss them? I think that would be valuable for me. If there is interest, I can set a publically logged one up under the Fenfire project at savannah.nongnu.org. > and these may considered as a > whole thanks to the shared language - there are obviously other models in > use for this kind of thing (notably TM) Whoops, another thing I didn't know about. TM? > but I think RDF is likely to emerge > as the common language, largely thanks to its lowest-common-denominator > statement representation. In other words, the development itself is > distributed - which seems quite natural really. Agree completely. > I can't remember seeing anyone taking the zigzag idea specifically and > putting it in RDF, so it'll be interesting what happens with Gzz/Fenfire > along these lines. I note that Fenfire is described as a hyperstructured > UI - this will be good to see, as UI development is lagging behind in RDF > developments. To give you a rough overview, there's a short-term and a long-term subproject, called Fenfire Loom and Buoyoing. Loom is our RDF editor, based on lessons learned from zzstructure editor. It uses focus-and-context views: You see a 'focused' node in the middle of a window, and around it, the nodes it's connected to. It will be usable indepent from the rest of Fenfire. I hope to release a 0.1, which only supports browsing and no editing yet, next week. Buoyoing ("Buoy-oriented interface, next generation") is our scheme for integrating data from different applications. This, too, is a focus+context interface. In the middle of a window, you see e.g. an html-like document. In the margins, you see pieces of other documents that are linked to this document, *buoys*, and there are lines connecting the buoys to the piece of the main document they're linked to. When you click on a buoy it becomes the focus (animated), and the formerly focused document moves into the margin, becoming a buoy. Buoyoing will allow anything in any view to be connected to anything in any other view, allowing you to see 'what's related.' We have basically implemented this and demoed it for a specific application-- browsing articles in ps/pdf format, creating connections between them (which are then shown in the margin) and taking notes about them (also connected in the margin). What's missing is the interfaces that allow anybody to write a new view which can be connected to any other view. >>Our aim is very close to what you describe; we want information from any >>application on a computer system (or network) to be available for >>linking with information from any other application, in any linking >>structure (for example IBIS discussion). For a person I'm in contact >>with, there should be a single node on my computer, connected to their >>address, their birthday, my appointments with them, emails I received >>from them, photos of them, and so on. > > That would be a foaf:Person [2] I take it? Sounds like a good possibility. At least it will be a subclass of foaf:Person. >> For Fenfire, we need a canonical format for RDF graphs, so that >>equal RDF graphs are always serialized to the same byte sequence; we >>might invent our own serialization language for that. > > Why do you need the same byte sequence? Um, in short: We identify versions of graphs by cryptographic hashes, and to get the hash of a version, we need to serialize it in a canonical way. > Anyhow it should be pretty straightforward to achieve - e.g. alphabetically > sorted nTriples Yes, I've been thinking that. The thing that bugs me is that I would really like to use a Unicode encoding-- nTriples uses escaping to represent Unicode characters. Maybe a Unicode version of nTriples. >> ...all structures should be viewable in a >>single 'structure editor' (even though we'll have all sorts of different >>views for application-specific data which you can switch forth and back >>between-- we share the OHS's vision here). > > Ideagraph [3] is my own take on this, and I agree absolutely with your > reasoning behind the use of RDF (though am too lazy to express it myself ;-) Very cool to see that you're interested in OHS stuff, btw. Re Ideagraph, btw: You asked me for comments earlier following our urn-5 discussion (I wasn't able to reply due to time constraints). The thing that really stood out was that I'd recommend a layer of indirection in the RDF vocabulary. Instead of this:: node rdf:label "Foo" node graphics:x "17" node graphics:y "44" node graphics:width "50" node graphics:height "20" I would do this:: canvas foo:containsNode ref ref graphics:x "17" ref graphics:y "44" ref graphics:width "50" ref graphics:height "20" ref foo:refersTo node node rdf:label "Foo" This way, the same node (e.g. person, blog item, ...) can be placed in multiple spatial locations on multiple canvases. This is something I learned from Ted Nelson: One thing should always be able to be in multiple contexts. For example, this way you can experiment with different spatial arrangements and store the alternatives. Or you can arrange the same nodes in different ways to make different points. - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 09:25:58 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 906A956FF7; Sat, 8 Mar 2003 09:25:57 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp3.cp.tin.it (vsmtp3.tin.it [212.216.176.223]) by bi0.bootstrap.org (Postfix) with SMTP id 58CE656FF5 for ; Sat, 8 Mar 2003 09:25:55 -0800 (PST) Received: from trotter (212.171.206.184) by smtp3.cp.tin.it (6.5.033) id 3E48CE9F009F2337; Sat, 8 Mar 2003 18:46:35 +0100 From: "Danny Ayers" To: Cc: "GZZ developers" Subject: RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Sat, 8 Mar 2003 18:45:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > http://www.eekim.com/ohs/papers/graphmodel/#hid5B includes: > "the complicated syntax would likely be a barrier to using RDF as a > general data modeling language." Thanks for the ref. On this issue I'd use the analogy of the patient that goes to the doctor and says, "It hurts when I do this*", the doctor replies "then don't do that*". The syntax is primarily there for machine interpretation, so whenever possible leave it to the machine. Tools like Isaviz give a graphic interface, and the APIs (Jena, Redfoot etc) allow you to get at it programmatically - copy & paste helps avoid having to do things from scratch. * strange physical contortion > > Ideagraph [3] Now on version 0.5.3.1 and counting... Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 09:52:16 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 997A656FF7; Sat, 8 Mar 2003 09:52:15 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 5FD1C56FF5 for ; Sat, 8 Mar 2003 09:52:13 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h28ICw2N025998; Sat, 8 Mar 2003 20:12:58 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h28ICvqH025995; Sat, 8 Mar 2003 20:12:58 +0200 Date: Sat, 8 Mar 2003 20:12:57 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sat, 8 Mar 2003, Danny Ayers wrote: > > http://www.eekim.com/ohs/papers/graphmodel/#hid5B includes: > Thanks for the ref. no prob., had to do that ;) > says, "It hurts when I do this*", the doctor replies "then don't do that*". :) > possible leave it to the machine. Tools like Isaviz give a graphic > interface, and the APIs (Jena, Redfoot etc) allow you to get at it right. we are using Jena (Benja started it that way and seems feasible) > programmatically - copy & paste helps avoid having to do things from > scratch. it also leads to trouble.. unless is implemented with transclusions, perhaps ;) here we are using OO of course, but i guess this is just nitpicking about something you know better than me so please excuse me for being pedantic. > > > Ideagraph [3] > Now on version 0.5.3.1 and counting... gzigzag is stable 0.6, gzz in 0.8 alpha and fenfire, hm loom in 0.1? then there is also storm, alph, etc. but that's another story. > Danny. ~Toni From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:10:33 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 8990556FF7; Sat, 8 Mar 2003 10:10:32 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (mail.gmx.de [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id 663BD56FF5 for ; Sat, 8 Mar 2003 10:10:30 -0800 (PST) Received: (qmail 29579 invoked by uid 0); 8 Mar 2003 18:31:19 -0000 Received: from p5082D4B2.dip.t-dialin.net (EHLO gmx.de) (80.130.212.178) by mail.gmx.net (mp001-rz3) with SMTP; 08 Mar 2003 19:31:19 +0100 Message-ID: <3E6A36A7.7090504@gmx.de> Date: Sat, 08 Mar 2003 19:29:59 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: Benja Fallenstein Cc: Danny Ayers , GZZ developers , ba-ohs-talk@bootstrap.org Subject: TM... (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) References: <3E6A2B27.80203@gmx.de> In-Reply-To: <3E6A2B27.80203@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Benja Fallenstein wrote: > Danny Ayers wrote: >> and these may considered as a >> whole thanks to the shared language - there are obviously other models in >> use for this kind of thing (notably TM) > > Whoops, another thing I didn't know about. TM? Oh, topic maps. Duh, sorry. -b. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:11:39 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 17B9856FF7; Sat, 8 Mar 2003 10:11:39 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 10CD756FF5 for ; Sat, 8 Mar 2003 10:11:37 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h28IWM2N026145; Sat, 8 Mar 2003 20:32:22 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h28IWMZQ026142; Sat, 8 Mar 2003 20:32:22 +0200 Date: Sat, 8 Mar 2003 20:32:22 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: <3E6A2B27.80203@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sat, 8 Mar 2003, Benja Fallenstein wrote: > Hi Danny, yet, > > the general problem (many blogged at [1]), > Cool. I have had a short look at your blog before, but need to look deeper. i guess i should too > What do you think about having a mailing list where these get posted & > we can discuss them? I think that would be valuable for me. If there is > interest, I can set a publically logged one up under the Fenfire project > at savannah.nongnu.org. might be a good idea. (to not get these double, do x-postings work with mail btw? prob. not. and anyhow, not to spam these lists with all this) > > use for this kind of thing (notably TM) > Whoops, another thing I didn't know about. TM? Topic Maps? i don't know them too deeply either. but i guess you can do them with RDF..?-o > Loom is our RDF editor, based on lessons learned from zzstructure > editor. It uses focus-and-context views: You see a 'focused' node in the > middle of a window, and around it, the nodes it's connected to. It will > be usable indepent from the rest of Fenfire. I hope to release a 0.1, > which only supports browsing and no editing yet, next week. right. and here we can explore the differences of zz and rdf in a way, too. > Buoyoing ("Buoy-oriented interface, next generation") is our scheme for didn't know/remember the name, actually :) > integrating data from different applications. This, too, is a .. neither the purpose. OTOH you did not use that with the mail client, but the plain client instead? do you know how Augment handles e-mail, btw? me neither.. but heard it does do that. > html-like document. In the margins, you see pieces of other documents > that are linked to this document, *buoys*, and there are lines > connecting the buoys to the piece of the main document they're linked > to. When you click on a buoy it becomes the focus (animated), and the > formerly focused document moves into the margin, becoming a buoy. screenshots of this are available in several places, in several submitted articles i mean and of course in the cvs. there are copies of some of those as e.g. http://an.org/fenfire/xupdf1.png and http://an.org/fenfire/xupdf2.png which i believe demonstrate this (those addresses only for the sake of shorter URLs) > > Why do you need the same byte sequence? > Um, in short: We identify versions of graphs by cryptographic hashes, > and to get the hash of a version, we need to serialize it in a canonical also, the same format (rdf) is used in-memory > represent Unicode characters. Maybe a Unicode version of nTriples. hm, don't know nTriples from before but perhaps that is a way > Re Ideagraph, btw: You asked me for comments earlier following our urn-5 > discussion (I wasn't able to reply due to time constraints). The thing oh, didn't realize you had this connection > that really stood out was that I'd recommend a layer of indirection in > the RDF vocabulary. Instead of this:: dind't you talk about this today with mudyc or someone? seems the right way to me for that purpose. and there are different vocabularies for different purposes, right? > canvas foo:containsNode ref > ref foo:refersTo node > This way, the same node (e.g. person, blog item, ...) can be placed in > multiple spatial locations on multiple canvases. This is something I yep > learned from Ted Nelson: One thing should always be able to be in has he ever commented on graph-based structures, btw? > multiple contexts. For example, this way you can experiment with > different spatial arrangements and store the alternatives. Or you can > arrange the same nodes in different ways to make different points. a requirement for OHS (even the 1st step, HyperScope) is having multiple views, iirc > - Benja ~Toni From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:17:39 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id B285B56FF7; Sat, 8 Mar 2003 10:17:38 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp4.cp.tin.it (vsmtp4.tin.it [212.216.176.224]) by bi0.bootstrap.org (Postfix) with SMTP id 3F3BE56FF5 for ; Sat, 8 Mar 2003 10:17:34 -0800 (PST) Received: from trotter (213.45.118.182) by smtp4.cp.tin.it (6.5.033) id 3E4A68A9009A333F; Sat, 8 Mar 2003 19:38:13 +0100 From: "Danny Ayers" To: "Benja Fallenstein" Cc: , "GZZ developers" Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Sat, 8 Mar 2003 19:37:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3E6A2B27.80203@gmx.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > Cool. I have had a short look at your blog before, but need to > look deeper. Eurgh, can't look very deep at the moment, the archive templates are pretty screwed up. They have been for a while, but I've been planning to transfer over to Movable Type, it's easier to hack. Still googleable using site: http://etc > What do you think about having a mailing list where these get posted & > we can discuss them? I think that would be valuable for me. If there is > interest, I can set a publically logged one up under the Fenfire project > at savannah.nongnu.org. Sure, that'd be good. Also when I get the blog moved over to MT it'll easy to allow other people to blog to it. > Whoops, another thing I didn't know about. TM? Topic Maps (also notice the difference between model & syntax - XTM's the usual, but Jack & others have discussed expressing them in RDF - layer on layer on layer...) > To give you a rough overview, there's a short-term and a long-term > subproject, called Fenfire Loom and Buoyoing. > > Loom is our RDF editor, based on lessons learned from zzstructure > editor. It uses focus-and-context views: You see a 'focused' node in the > middle of a window, and around it, the nodes it's connected to. Sounds cool - kinda like http://www.ideagraph.net/unleashed/#Squirrel ? It will > be usable indepent from the rest of Fenfire. I hope to release a 0.1, > which only supports browsing and no editing yet, next week. What programming language(s) are you using? > Buoyoing ("Buoy-oriented interface, next generation") is our scheme for > integrating data from different applications. This, too, is a > focus+context interface. In the middle of a window, you see e.g. an > html-like document. In the margins, you see pieces of other documents > that are linked to this document, *buoys*, and there are lines > connecting the buoys to the piece of the main document they're linked > to. When you click on a buoy it becomes the focus (animated), and the > formerly focused document moves into the margin, becoming a buoy. That does sound very nice. > > Why do you need the same byte sequence? > > Um, in short: We identify versions of graphs by cryptographic hashes, > and to get the hash of a version, we need to serialize it in a canonical > way. Hmm, I'm sure you have good reason to use something other than URIs for identification... > Re Ideagraph, btw: You asked me for comments earlier following our urn-5 > discussion (I wasn't able to reply due to time constraints). The thing > that really stood out was that I'd recommend a layer of indirection in > the RDF vocabulary. Instead of this:: > > node rdf:label "Foo" > node graphics:x "17" > node graphics:y "44" > node graphics:width "50" > node graphics:height "20" > > I would do this:: > > canvas foo:containsNode ref > ref graphics:x "17" > ref graphics:y "44" > ref graphics:width "50" > ref graphics:height "20" > ref foo:refersTo node > node rdf:label "Foo" > > This way, the same node (e.g. person, blog item, ...) can be placed in > multiple spatial locations on multiple canvases. This is something I > learned from Ted Nelson: One thing should always be able to be in > multiple contexts. For example, this way you can experiment with > different spatial arrangements and store the alternatives. Or you can > arrange the same nodes in different ways to make different points. Very good point (& thanks for the suggestion), though I'm not sure I'd approach it in this way - I don't think the indirection is needed. There's nothing in the RDF model stopping the coexistence of nodeA graphics:x "17" nodeA graphics:x "18" even if nodeA is a URI so some kind of contextualization is needed anyway. So the lines along which I was thinking were more like : canvasX{ nodeA graphics:x "17" } canvasY{ nodeA graphics:x "18" } Though I've not worked much of this out yet - looking at a containership vocab. Anyhow, I'm still tinkering with much cruder stuff at present though, plenty of time to think about this... Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:37:28 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 8382E56FF7; Sat, 8 Mar 2003 10:37:25 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 6644A56FF5 for ; Sat, 8 Mar 2003 10:37:23 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h28Iw82N026282; Sat, 8 Mar 2003 20:58:09 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h28Iw82A026279; Sat, 8 Mar 2003 20:58:08 +0200 Date: Sat, 8 Mar 2003 20:58:08 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: Benja Fallenstein , GZZ developers Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sat, 8 Mar 2003, Danny Ayers wrote: > Hmm, I'm sure you have good reason to use something other than URIs for afaik the cryptographic content hash forms the URI (urn-5) > nodeA graphics:x "17" > nodeA graphics:x "18" > even if nodeA is a URI yes this is new to us after zz .. (zzstructure uses clones for that) > so some kind of contextualization is needed anyway. So the lines along which exactly. > I was thinking were more like : > canvasX{ > nodeA graphics:x "17" > } > > canvasY{ > nodeA graphics:x "18" > } but quite often with rdf one node may be in several places on one canvas, with the views we are using that is. or did i miss the point here? > vocab. Anyhow, I'm still tinkering with much cruder stuff at present though, > plenty of time to think about this... i guess that's good, too :) (and there is much for us as well) > Cheers, > Danny. to you too, ~Toni From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:58:24 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 3D9475700F; Sat, 8 Mar 2003 10:58:23 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 3093156FF7 for ; Sat, 8 Mar 2003 10:58:21 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h28JJ62N026442; Sat, 8 Mar 2003 21:19:06 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h28JJ5oO026439; Sat, 8 Mar 2003 21:19:06 +0200 Date: Sat, 8 Mar 2003 21:19:05 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sat, 8 Mar 2003, Alatalo Toni wrote: > > Hmm, I'm sure you have good reason to use something other than URIs for > afaik the cryptographic content hash forms the URI (urn-5) """"" oh sorry, i meant the block-id -- specifics in http://himalia.it.jyu.fi/gzzdoc/pegboard/simple_storm--benja/peg.gen.html .. i think (am not really working now, just doing this while something else) ~Toni From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 10:59:22 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id AC60F5700F; Sat, 8 Mar 2003 10:59:21 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (mail.gmx.de [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id A780556FF7 for ; Sat, 8 Mar 2003 10:59:19 -0800 (PST) Received: (qmail 27859 invoked by uid 0); 8 Mar 2003 19:20:11 -0000 Received: from p5082D4B2.dip.t-dialin.net (HELO gmx.de) (80.130.212.178) by mail.gmx.net (mp007-rz3) with SMTP; 8 Mar 2003 19:20:11 -0000 Message-ID: <3E6A4265.1020402@gmx.de> Date: Sat, 08 Mar 2003 20:20:05 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: urn-5 vs hashes (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Toni-- Alatalo Toni wrote: > On Sat, 8 Mar 2003, Danny Ayers wrote: >>Hmm, I'm sure you have good reason to use something other than URIs for (replied to Danny by private mail) > afaik the cryptographic content hash forms the URI (urn-5) Nope, urn:urn-5 is for random numbers (when you create a new node and want to assign a random URI to it) and is not related to hashes. There's no URI scheme or URN namespace for hashed data, yet (AFAIK). (Sorry to send this thru the lists, but it would be bad if this misconception stood without refutation...) - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 12:30:07 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 4531356FF7; Sat, 8 Mar 2003 12:30:06 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id 2C09056FF5 for ; Sat, 8 Mar 2003 12:30:04 -0800 (PST) Received: (qmail 17026 invoked by uid 0); 8 Mar 2003 20:50:55 -0000 Received: from pD9588D36.dip.t-dialin.net (HELO gmx.de) (217.88.141.54) by mail.gmx.net (mp007-rz3) with SMTP; 8 Mar 2003 20:50:55 -0000 Message-ID: <3E6A57A9.5060707@gmx.de> Date: Sat, 08 Mar 2003 21:50:49 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Danny Ayers wrote: >>What do you think about having a mailing list where these get posted & >>we can discuss them? I think that would be valuable for me. If there is >>interest, I can set a publically logged one up under the Fenfire project >>at savannah.nongnu.org. > > Sure, that'd be good. Also when I get the blog moved over to MT it'll easy > to allow other people to blog to it. Created one; will appear on the next Savannah update (in two hours or so) at: http://mail.nongnu.org/mailman/listinfo/fenfire-rdf-discuss The purpose is to discuss RDF tools/references from a Hypermedia (Fenfire, Open Hyperdocument System) perspective. >>Whoops, another thing I didn't know about. TM? > > Topic Maps Right. > (also notice the difference between model & syntax - XTM's the > usual, but Jack & others have discussed expressing them in RDF - layer on > layer on layer...) That sounds exactly right to me. Skimming the "TAO of Topic Maps" a second time, it seems like an RDF-like model (topics and associations) with some properties being expressed in a special-cased way (resources aren't topics; the relationship between resources and topics, 'occurence', is not an 'association'). It seems like it should be possible to express topic maps in RDF and allow them to be interconnected with other RDF data in the go. OTOH, I obviously don't know topic maps very deeply, so I may be wrong. But it sounds like the right approach. >>To give you a rough overview, there's a short-term and a long-term >>subproject, called Fenfire Loom and Buoyoing. >> >>Loom is our RDF editor, based on lessons learned from zzstructure >>editor. It uses focus-and-context views: You see a 'focused' node in the >>middle of a window, and around it, the nodes it's connected to. > > Sounds cool - kinda like > http://www.ideagraph.net/unleashed/#Squirrel ? Yup. (Unforch the servlet didn't work for me-- on Konqueror (KDE 3.1); I tried copying the URL from the servlet-generated tag into my browser and got a traceback.) >> It will >>be usable indepent from the rest of Fenfire. I hope to release a 0.1, >>which only supports browsing and no editing yet, next week. > > What programming language(s) are you using? Java. For the graphics effects, C++ through JNI, but so far, Loom uses only Java. If you want to see what's there so far, the code is in the Fenfire CVS: http://savannah.nongnu.org/cvs/?group=fenfire To run, you need to check out the 'fenfire' and 'fenfire-depends' module in the same directory; install Ant; run 'ant fenfire' in the fenfire/ directory; and then run 'ant run -Drdffile=/some/rdf/file' in the same dir. README forthcoming :-) We're still working on refactoring the old Gzz code in several independent projects. Currently, Loom uses a Jar containing .class files built from the old Gzz code (http://gzz.info). It'll be checked out along with the rest. Everything is LGPL so far. >>This way, the same node (e.g. person, blog item, ...) can be placed in >>multiple spatial locations on multiple canvases. This is something I >>learned from Ted Nelson: One thing should always be able to be in >>multiple contexts. For example, this way you can experiment with >>different spatial arrangements and store the alternatives. Or you can >>arrange the same nodes in different ways to make different points. > > Very good point (& thanks for the suggestion), though I'm not sure I'd > approach it in this way - I don't think the indirection is needed. There's > nothing in the RDF model stopping the coexistence of > > nodeA graphics:x "17" > nodeA graphics:x "18" > > even if nodeA is a URI (Except of course that you don't know which of the two graphics:x and which of the two graphics:y belong together.) > so some kind of contextualization is needed anyway. So the lines along which > I was thinking were more like : > > canvasX{ > nodeA graphics:x "17" > } > > canvasY{ > nodeA graphics:x "18" > } So that would amount to having two different RDF graphs, canvasX and canvasY. (Or you'd have to reify the graphics:x statements-- I don't think that's what you're saying...) I wouldn't recommend that path, but I'm having problems expressing *why*... Basically, I believe RDF plays its strengths much better if you don't have to think about different contexts (graphs) most of the time. You only need to maintain a single graph (which can internally be the autogenerated union of several other graphs) for all the views/apps in your system. If I want to add that 'nodeA isReasonFor nodeB', that information is orthogonal to the placement of nodeA on any canvas. Maybe I want to show reasons in green; then both of the canvas contexts would have to contain the isReasonFor triple, otherwise they wouldn't know the node is green. What if I want to say that canvasA isMoreDetailedVersionOf canvasB? Of course, if canvases are RDF graphs, I can use the URIs of either graph to express the connection. But a view that shows this information as a connection between the two canvases would then have to make the connection between each canvas's URI and the in-memory graph object and the view... it all seems very complex. If you wanted to send all this to a mailing list, you would have to send three RDF files-- the two canvas graphs plus the third graph relating the canvases. In my proposal, you'd only have a single graph-- canvasA foo:containsNode refA canvasA foo:containsNode refB1 refA graphics:x "17" refA graphics:y "44" refA graphics:width "50" refA graphics:height "20" refA foo:refersTo nodeA refB1 graphics:x "112" ... refB2 foo:refersTo nodeB canvasB foo:containsNode refB2 refB2 foo:refersTo nodeB ... nodeA rdf:label "Foo" nodeA isReasonFor nodeB canvasA isMoreDetailedVersionOf canvasB which seems to simplify matters considerably. Of course, I'm looking from the Fenfire perspective-- many different applications and many different 'documents' inside a single graph, connected and overlapping (same node in different apps/docs). By 'document' I mean some unit like an Ideagraph canvas (or, more traditionally, a text with headings, paragraphs etc). > Though I've not worked much of this out yet - looking at a containership > vocab. Anyhow, I'm still tinkering with much cruder stuff at present though, > plenty of time to think about this... Ok. (These considerations do seem relevant for the use of RDF in a hyperdocument system, though-- therefore the reply's on-list.) - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 13:27:21 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 75D8756FF7; Sat, 8 Mar 2003 13:27:20 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by bi0.bootstrap.org (Postfix) with SMTP id 06D2F56FF5 for ; Sat, 8 Mar 2003 13:27:18 -0800 (PST) Received: from apt05-nex-01.thinkalong.com (12-234-229-110.client.attbi.com[12.234.229.110]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003030821480500200mfqbhe>; Sat, 8 Mar 2003 21:48:06 +0000 Message-Id: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> X-Sender: jackpark@thinkalong.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Mar 2003 13:47:52 -0800 To: ba-ohs-talk@bootstrap.org From: Jack Park Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: <3E6A57A9.5060707@gmx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org At 12:50 PM 3/8/2003, Benja Fallenstein wrote: >...resources aren't topics; Why not? --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally to reduce the need for smarter bombs. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 13:33:04 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 2377856FF7; Sat, 8 Mar 2003 13:33:04 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by bi0.bootstrap.org (Postfix) with SMTP id BAD7D56FF5 for ; Sat, 8 Mar 2003 13:33:02 -0800 (PST) Received: from [192.168.1.100] (12-234-6-28.client.attbi.com[12.234.6.28]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003030821534800100j9dmce>; Sat, 8 Mar 2003 21:53:48 +0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 08 Mar 2003 13:55:02 -0800 Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") From: Sandy Klausner To: Message-ID: In-Reply-To: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org A resource is context, whereas a topic is content. > At 12:50 PM 3/8/2003, Benja Fallenstein wrote: >> ...resources aren't topics; > > Why not? > > > --------------------------------------------------------------------------- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally to reduce the need for smarter bombs. > > > From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 13:40:02 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 6E4E556FF7; Sat, 8 Mar 2003 13:40:01 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id 6357656FF5 for ; Sat, 8 Mar 2003 13:39:59 -0800 (PST) Received: (qmail 23238 invoked by uid 0); 8 Mar 2003 22:00:49 -0000 Received: from pD9588D36.dip.t-dialin.net (HELO gmx.de) (217.88.141.54) by mail.gmx.net (mp009-rz3) with SMTP; 8 Mar 2003 22:00:49 -0000 Message-ID: <3E6A6809.3090202@gmx.de> Date: Sat, 08 Mar 2003 23:00:41 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") References: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> In-Reply-To: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Jack Park wrote: > At 12:50 PM 3/8/2003, Benja Fallenstein wrote: > >> ...resources aren't topics; > > > Why not? I got that impression from the TAO document. In all the diagrams, topics are shown as objects floating above a tissue of 'occurences,' resources in which the topic occurs. And the document contains language like the following-- An important point to note here is the separation into two layers of the topics and their occurrences. This separation is one of the clues to the power of topic maps and we shall return to it later. http://www.ontopia.net/topicmaps/materials/tao.html#d0e818 I may have misunderstood the doc, of course. - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 14:11:45 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id D5CB456FF7; Sat, 8 Mar 2003 14:11:44 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by bi0.bootstrap.org (Postfix) with SMTP id 3C25156FF5 for ; Sat, 8 Mar 2003 14:11:43 -0800 (PST) Received: from pacbell.net ([63.206.92.55]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HBG00NG7BY24E@mta6.snfc21.pbi.net> for ba-ohs-talk@bootstrap.org; Sat, 08 Mar 2003 14:32:28 -0800 (PST) Date: Sat, 08 Mar 2003 14:34:52 -0800 From: Rod Welch Subject: [ba-ohs-talk] Obituary and Re-birth To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Message-id: <3E6A700C.F86BC48@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3E6A2B27.80203@gmx.de> Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Glad to see OHS/DKR coming to life as spring nears. On 000927 Eric Armstrong wrote asking why things had been so "quiet" for a week or so on communication about OHS/DKR.... http://www.welchco.com/sd/08/00101/02/00/09/27/155656.HTM#0001 This thought occurred recently in recognizing things have been "quiet" the past few months following the holidays. I checked the obituaries and was relieved to see OHS/DKR was not listed, and now today suddenly a whole flurry of letters came in suggesting things are springing back to life. That's what happened in 2000. After Eric's letter, Eugene Kim wrote on 000928 explaining work going on for development of the OHS/DKR..... http://www.welchco.com/sd/08/00101/02/00/09/28/101350.HTM#569N Soon, Doug published guidance for a launch plan that illustrated how to put links in documents on the Internet, and everyone was off and running. In fact, Eric was ahead of schedule. On 001017, even before the launch plan came out on 001025, Eric reported significant progress.... http://www.welchco.com/sd/08/00101/02/00/10/17/144316.HTM#IO6J ...and a little later on 001121 he urged others to contribute because the OHS/DKR work is so critical.... http://www.welchco.com/sd/08/00101/02/00/11/21/084051.HTM#LM7H Following Eric's example, Eugene Kim contributed strong leadership on 001126 by urging folks to implement Doug's launch plan using available tools with greater diligence.... http://www.welchco.com/sd/08/00101/02/00/11/26/214933.HTM#QW8I ...and noting particularly Doug's call for linking in email.... http://www.welchco.com/sd/08/00101/02/00/11/26/214933.HTM#XV8L This showed good progress maintaining alignment because a lot of experience shows that people, organizations and even an entire cultures drift off course due to "meaning drift." Eugene's incite reminding everyone to follow Doug's lead by aligning communication and work on the OHS/DKR code with the Launch Plan was powerful medicine for keeping on track. At that time, Grant Bowman pointed out that putting links in email is not that easy. He asked if people are supposed to change their tools from familiar ways everybody likes.... http://www.welchco.com/sd/08/00101/02/00/11/26/214933.HTM#X8PW At that point, Eugene went to work and on 010131 notified of good news that he developed new tools which Grant and everyone can use..... http://www.welchco.com/sd/08/00101/02/01/01/31/141147.HTM#XZ8G ...to follow advice for implementing Doug's call to link things up. Well, the rest is history. Soon Jack Park had Nexist going to improve education and help people with story telling through narratology. John Maloney related startling breakthroughs with Grove and Groove. Sergie Brin reported on how meta data and other searching tools solve the problem Eric related on 011003 that nobody can find anything. Ray Ozzie offered ideas on using Lotus Notes to avoid the "pain" people experience using email and weblogs, or something like. Dave Snowden reported how Quickplace and Sametime have been a big help at IBM. There were some bumps. Paul Fernhout worried on 020530 that good ideas and technology code was being withheld by big corporations and individuals that delayed progress because of worry about licenses.... http://www.welchco.com/sd/08/00101/02/02/05/30/201330.HTM#O14N Just yesterday, however, John Deneen suggested looking at a Powerpoint presentation by Jim Gemmell on something called "MyLifeBits." Review showed that MyLifeBits is a project sponsored by Gordon Bell, who is a senior researcher at Microsoft's Bay Area Research Center..... http://research.microsoft.com/users/GBell/ MyLifeBits is shown on the Internet at.... http://research.microsoft.com/barc/MediaPresence/MyLifeBits.aspx John said to examine the following Powerpoint file.... "MyLifeBits: Fulfilling the Memex Vision" ...which can be downloaded free of charge at the above address. In our discussion, I explained that Powerpoint presentations are powerful tools for bad management, as explained in POIMS.... http://www.welchco.com/03/00050/01/09/01/02/00030.HTM#YZ4I ...and citing the Enron case, reviewed a year ago on 020204.... http://www.welchco.com/sd/08/00101/02/02/02/04/160634.HTM#KM4F ...because "knowledge" requires connections to context, which are missing from pictures, as further related in POIMS defining the process of intelligence that converts information into knowledge.... http://www.welchco.com/03/00050/01/09/01/02/00030.HTM#0367 John was in a hurray, and urged that reviewing the MyLifeBits powerpoint presentation would be helpful. He said that reviewing the Powerpoint file would help me understand his perspective. I was reminded of Eric Armstrong's perspective on 011003 about investing limited time by directing attention to sources aligned with objectives, requirements and commitments.... http://www.welchco.com/sd/08/00101/02/01/10/03/160603.HTM#EC5N But, realizing how frustrating it is when people ignore my own ideas and requests to read this that-and-the-other, out of courtesy and against Eric's sound advice, I went off and looked at the Powerpoint presentation. Since there are no anchors, links are not available to verify accuracy nor to understand context. Still, Gimmell says in pertinent part.... Gordon Bell, like Doug Engelbart, wants to develop a "repository" of stuff from daily life that includes books, photos, documents, memos, legal papers, home movies, and everything to create a "paperless" environment. This reminds of Doug's explanation of a "Knowledge Workshop" set out in Doug's 1972 paper which he commended to the OHS/DKR group on 000327.... http://www.welchco.com/sd/08/00101/02/00/03/27/094001.HTM#3971 Gordon then poses the question that Eric raised on 010916 that nobody can find anything in email.... http://www.welchco.com/sd/08/00101/02/01/09/16/213549.HTM#KA6H Gordon says Microsoft is going to provide full text search and collection with freedom form strict hierarchy. There will be many visualizations -- he says "Don't metaphor me in." Microsoft plans to make adding annotations that add value fast and easy, and further will enable people to keep the links they author based on a system of "transclusion." Microsoft's technology will help the user tell a "story," because Gordon stories structure information in time and space. Gordon doesn't mention it, but "stories" are a form of mental spreadsheet that position data and information in relation to human values; so, lets agree that support for stories are another good idea. Microsoft is planning to support, Ted Nelson's important work on transclusion is slated for support, and Gordon says the key is "LINKS." That's right, the presentation shows links in all capitals to emphasize this requirement. Ted is quoted at length in the presentation slides arguing for links. Microsoft does not mention Murray Altheim's powerful analysis on 020820 showing that everybody has voted against links..... http://www.welchco.com/sd/08/00101/02/02/08/20/004914.HTM#UV6G ...and going on to emphasize that accuracy and context in communication, provided by links, does not move the conversation forward.... http://www.welchco.com/sd/08/00101/02/02/08/20/005018.HTM#V66I John Maloney joined Murray in a letter on 020823 explaining how correspondence that is supported by the record is invasive and unwelcome.... http://www.welchco.com/sd/08/00101/02/02/08/23/164745.HTM#R87J Then on 020929 Dave Snowden who is leading knowledge management efforts at IBM explained how links are difficult for people to handle.... http://www.welchco.com/sd/08/00101/02/02/09/20/012747.HTM#5Y8I Careful review of Microsoft's planning shows nothing on helping people transition from familiar ways to a new way of working called out by Doug. Microsoft does explain that the repository is a data base with consistent, simple and logical structure, indexing, pivoting, queries, speed scalability. They say backup is important as is replication. They say "blob" and links are inherent. Microsoft also proposes features to visualize document relationships, which sounds like dialog mapping that Eugene Kim is using to great effect for the OHS/DKR to supplement the purple number system, as reported on 010917... http://www.welchco.com/sd/08/00101/02/01/09/17/085151.HTM#S44G Jack Park's primer on Topic Maps published last year reported on 020911..... http://www.welchco.com/sd/08/00101/02/02/09/11/143440.HTM#NJ6H ...also would seem to provide critical guidance for Microsoft to help people find information in the MyLifeBits knowledge repository. In sum, John's suggestion to review the Powerpoint presentation on MyLifeBits showed that Microsoft is working on goals for the OHS/DKR, just like everybody else has been doing since the 60s. Review further showed plans for technology to support links, metadata and analysis, which have been expressly rejected by engineers, executives and everyone in between, reported on 021031.... http://www.welchco.com/sd/08/00101/02/02/09/24/110735.HTM#KT8F Thus, the threshold question is even if lightening strikes, and Microsoft breaks through the barriers that stifle innovation in a big organization, cited on 910418..... http://www.welchco.com/sd/08/00101/02/91/04/18/115602.HTM#MW8N ...who is going to use it? If people aver "intelligence" because links "boggle the mind," as Eric anticipated on 000125, what will motivate Microsoft to produce something nobody will buy? Not only are links and analysis something people have voted against, as related by Murray and John Maloney, but in many cases people fear the light of knowledge more than the darkness of ignorance. The hope that ignorance is an excuse to avoid accountability, which greatly increasing the time and cost of the work, as shown on 010911 and recently on 030304.... http://www.welchco.com/sd/08/00101/02/03/03/04/113851.HTM#KV6K ...the fear of accountability inherent in the power of knowledge dries up demand for better knowledge support. That is a question that pops up from the record, which one hoped the Powerpoint presentation would address constructively. Since top KM experts are reticent about using KM, it seemed unlikely to expect the Powerpoint presentation would show progress on transformation from information to a culture of knowledge. The second issue is performance. People have been making lists of features for software since the 1950s. Doug Engelbart has come the farthest, shown by the telecon on 991222.... http://www.welchco.com/sd/08/00101/02/99/12/22/104523.HTM#3696 Others at Microsoft, IBM, LANL, DARPA, SRI, Oracle and so on have made their lists, as reported at SRI on 000324. None of these lists, while discussing useful features, address the core issue noted by Eric Armstrong on 000503, and discussed by Eugene Kim on 000615. More recently on 010510 Steve Balmer related that Microsoft has a 5 year plan to develop XML software to improve management, which means they are hoping someone will come up with something that Microsoft can buy and sell to others within that time frame.... http://www.welchco.com/sd/08/00101/02/01/05/10/223852.HTM#8Y8H A year or so later on 021108 Bill Gates reported plans for a project to solve Eric's concern about finding stuff on the computer, which, as seen from the Microsoft Powerpoint presentation, is planned for MyLifeBits, per above, and so is useful.... http://www.welchco.com/sd/08/00101/02/02/11/08/084723.HTM#EF5I Naturally, people hope that with Bill on the job, things will start to move faster. Maybe that accounts for increased email traffic for OHS/DKR. It is a welcome sign because progress requires effort which is driven by hope, and talking is one way to keep hope alive. Another way, according to Tom Munnecke at SAIC, is to study what works, reported on 020726.... http://www.welchco.com/sd/08/00101/02/02/07/26/150958.HTM#E63H Re-birth requires faith and faith takes evidence that goals are reachable; not only that something can be done, but, also, that a new way of working makes a difference in the quality of work. What counts is performance. Without evidence of performance, nobody will invest more than 20 minutes required to learn a new way of working. Rod **************** Benja Fallenstein wrote: > > Hi Danny, > > Danny Ayers wrote: > >>Toni Alatalo pointed me to your paper, `Towards a Standard Graph-Based > >>Data Model for the Open Hyperdocument System`__. You make the point that > >>a standard graph-based model could allow different applications to be > >>integrated into a single whole. You say that RDF is one possible choice > >>for a modeling language, but reject it because of its complicated syntax. > >> > >>__ http://www.eekim.com/ohs/papers/graphmodel/ > > > > > > I couldn't find the 'rejection' bit on a skim of Eugene's paper... > > Toni's pointed to it-- http://www.eekim.com/ohs/papers/graphmodel/#hid5B > > > but whatever, I'm getting the impression that an implementation of an OHS is > > actually well on its way, primarily using the RDF model. Pretty much dail > > I'm coming across new RDF-based systems that focus on different aspects of > > the general problem (many blogged at [1]), > > Cool. I have had a short look at your blog before, but need to look deeper. > > What do you think about having a mailing list where these get posted & > we can discuss them? I think that would be valuable for me. If there is > interest, I can set a publically logged one up under the Fenfire project > at savannah.nongnu.org. > > > and these may considered as a > > whole thanks to the shared language - there are obviously other models in > > use for this kind of thing (notably TM) > > Whoops, another thing I didn't know about. TM? > > > but I think RDF is likely to emerge > > as the common language, largely thanks to its lowest-common-denominator > > statement representation. In other words, the development itself is > > distributed - which seems quite natural really. > > Agree completely. > > > I can't remember seeing anyone taking the zigzag idea specifically and > > putting it in RDF, so it'll be interesting what happens with Gzz/Fenfire > > along these lines. I note that Fenfire is described as a hyperstructured > > UI - this will be good to see, as UI development is lagging behind in RDF > > developments. > > To give you a rough overview, there's a short-term and a long-term > subproject, called Fenfire Loom and Buoyoing. > > Loom is our RDF editor, based on lessons learned from zzstructure > editor. It uses focus-and-context views: You see a 'focused' node in the > middle of a window, and around it, the nodes it's connected to. It will > be usable indepent from the rest of Fenfire. I hope to release a 0.1, > which only supports browsing and no editing yet, next week. > > Buoyoing ("Buoy-oriented interface, next generation") is our scheme for > integrating data from different applications. This, too, is a > focus+context interface. In the middle of a window, you see e.g. an > html-like document. In the margins, you see pieces of other documents > that are linked to this document, *buoys*, and there are lines > connecting the buoys to the piece of the main document they're linked > to. When you click on a buoy it becomes the focus (animated), and the > formerly focused document moves into the margin, becoming a buoy. > > Buoyoing will allow anything in any view to be connected to anything in > any other view, allowing you to see 'what's related.' We have basically > implemented this and demoed it for a specific application-- browsing > articles in ps/pdf format, creating connections between them (which are > then shown in the margin) and taking notes about them (also connected in > the margin). What's missing is the interfaces that allow anybody to > write a new view which can be connected to any other view. > > >>Our aim is very close to what you describe; we want information from any > >>application on a computer system (or network) to be available for > >>linking with information from any other application, in any linking > >>structure (for example IBIS discussion). For a person I'm in contact > >>with, there should be a single node on my computer, connected to their > >>address, their birthday, my appointments with them, emails I received > >>from them, photos of them, and so on. > > > > That would be a foaf:Person [2] I take it? > > Sounds like a good possibility. At least it will be a subclass of > foaf:Person. > > >> For Fenfire, we need a canonical format for RDF graphs, so that > >>equal RDF graphs are always serialized to the same byte sequence; we > >>might invent our own serialization language for that. > > > > Why do you need the same byte sequence? > > Um, in short: We identify versions of graphs by cryptographic hashes, > and to get the hash of a version, we need to serialize it in a canonical > way. > > > Anyhow it should be pretty straightforward to achieve - e.g. alphabetically > > sorted nTriples > > Yes, I've been thinking that. The thing that bugs me is that I would > really like to use a Unicode encoding-- nTriples uses escaping to > represent Unicode characters. Maybe a Unicode version of nTriples. > > >> ...all structures should be viewable in a > >>single 'structure editor' (even though we'll have all sorts of different > >>views for application-specific data which you can switch forth and back > >>between-- we share the OHS's vision here). > > > > Ideagraph [3] is my own take on this, and I agree absolutely with your > > reasoning behind the use of RDF (though am too lazy to express it myself ;-) > > Very cool to see that you're interested in OHS stuff, btw. > > Re Ideagraph, btw: You asked me for comments earlier following our urn-5 > discussion (I wasn't able to reply due to time constraints). The thing > that really stood out was that I'd recommend a layer of indirection in > the RDF vocabulary. Instead of this:: > > node rdf:label "Foo" > node graphics:x "17" > node graphics:y "44" > node graphics:width "50" > node graphics:height "20" > > I would do this:: > > canvas foo:containsNode ref > ref graphics:x "17" > ref graphics:y "44" > ref graphics:width "50" > ref graphics:height "20" > ref foo:refersTo node > node rdf:label "Foo" > > This way, the same node (e.g. person, blog item, ...) can be placed in > multiple spatial locations on multiple canvases. This is something I > learned from Ted Nelson: One thing should always be able to be in > multiple contexts. For example, this way you can experiment with > different spatial arrangements and store the alternatives. Or you can > arrange the same nodes in different ways to make different points. > > - Benja From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 15:55:25 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 2A22D56FF7; Sat, 8 Mar 2003 15:55:25 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by bi0.bootstrap.org (Postfix) with SMTP id B34D356FF5 for ; Sat, 8 Mar 2003 15:55:23 -0800 (PST) Received: from apt05-nex-01.thinkalong.com (12-234-229-110.client.attbi.com[12.234.229.110]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003030900160900100d7pi1e>; Sun, 9 Mar 2003 00:16:09 +0000 Message-Id: <5.1.1.6.0.20030308160322.028ded30@thinkalong.com> X-Sender: jackpark@thinkalong.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Mar 2003 16:15:56 -0800 To: ba-ohs-talk@bootstrap.org From: Jack Park Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: <3E6A6809.3090202@gmx.de> References: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org At 02:00 PM 3/8/2003, Benja Fallenstein wrote: > >I got that impression from the TAO document. In all the diagrams, topics >are shown as objects floating above a tissue of 'occurences,' resources in >which the topic occurs. And the document contains language like the following-- > > An important point to note here is the separation into two layers of > the topics and their occurrences. This separation is one of the > clues to the power of topic maps and we shall return to it later. > > http://www.ontopia.net/topicmaps/materials/tao.html#d0e818 > >I may have misunderstood the doc, of course. > >- Benja I doubt that you misunderstood the doc; it is a well-written document and what was written might not lead you to realize that it is also possible to "reify" occurrences in topics, thus making topics out of individual resources, with which you can form associations, decorate with properties, and so forth. Reified occurrences are discussed in the _XML Topic Maps_ book, and, I suspect, in various places on the Web. Occurrences can do this by way of the tag. At http://www.topicmaps.org/xtm/index.html we see: occurrence type 1. One of the classes of topic occurrence. 2. The class of topic occurrence specified by an element's child element. An occurrence may belong to only one class. 3. A topic whose subject is a class of topic occurrence. The topic, the subject of which is the occurrence itself, leaves plenty of room for further annotation. Consider a topic, say, "Topic Map" which has an associated topic, say, "Literature", which itself, contains several occurrences, some of which are type "Book" (another topic), some of which are of type "Conference Paper", and so forth. Within that ontology, it is possible to subclass, say, "Book" to a particular book and decorate that topic with all sorts of associations. HyTM (the older hytime version of topic maps) used to have something called which served the same purpose as "facets" do as restrictions on "slots" in "frames". Facets got dropped during development of XTM. Hope that helps. Jack --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally to reduce the need for smarter bombs. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 16:03:08 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id E7E0757017; Sat, 8 Mar 2003 16:03:07 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by bi0.bootstrap.org (Postfix) with SMTP id 9D5FD56FF5 for ; Sat, 8 Mar 2003 16:03:06 -0800 (PST) Received: from apt05-nex-01.thinkalong.com (12-234-229-110.client.attbi.com[12.234.229.110]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <20030309002352002005hf8ve>; Sun, 9 Mar 2003 00:23:52 +0000 Message-Id: <5.1.1.6.0.20030308162127.0385e718@thinkalong.com> X-Sender: jackpark@thinkalong.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Mar 2003 16:23:39 -0800 To: ba-ohs-talk@bootstrap.org From: Jack Park Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: References: <5.1.1.6.0.20030308134651.03835ea8@thinkalong.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org At 01:55 PM 3/8/2003, Sandy Klausner wrote: >A resource is context, whereas a topic is content. I would think that, technically speaking, resources are not topics, but they can be the subjects of topics, and, thus, treated as if they are topics. Now, a resource as context? And a topic as content? Please explain. --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally to reduce the need for smarter bombs. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 16:11:52 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 2E4CC57017; Sat, 8 Mar 2003 16:11:52 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by bi0.bootstrap.org (Postfix) with SMTP id CBC3756FF5 for ; Sat, 8 Mar 2003 16:11:50 -0800 (PST) Received: from apt05-nex-01.thinkalong.com (12-234-229-110.client.attbi.com[12.234.229.110]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003030900323600100j85r5e>; Sun, 9 Mar 2003 00:32:37 +0000 Message-Id: <5.1.1.6.0.20030308162845.03861ec0@thinkalong.com> X-Sender: jackpark@thinkalong.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Mar 2003 16:32:24 -0800 To: ba-ohs-talk@bootstrap.org From: Jack Park Subject: Re: [ba-ohs-talk] Obituary and Re-birth In-Reply-To: <3E6A700C.F86BC48@pacbell.net> References: <3E6A2B27.80203@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org At 02:34 PM 3/8/2003, Rod Welch wrote: >Glad to see OHS/DKR coming to life as spring nears. Rod, At the moment, ohs-talk is being used for precisely what it was intended: hammering out underlying principles, use cases, and so forth. Everyone here, myself included, is busy learning. The RDF topic, itself, is an important one and really needs lots of demonstrations in order to tease out the relative merits it brings to the implementation table. There are some really smart people playing with both RDF and topic maps. I think we are going to see some really powerful implementations spring to life pretty soon now. Cheers Jack --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally to reduce the need for smarter bombs. From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 19:20:32 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id E227B56FF7; Sat, 8 Mar 2003 19:20:31 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by bi0.bootstrap.org (Postfix) with SMTP id 8755656FF5 for ; Sat, 8 Mar 2003 19:20:30 -0800 (PST) Received: from [192.168.1.100] (12-234-6-28.client.attbi.com[12.234.6.28]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003030903411600100o2mnme>; Sun, 9 Mar 2003 03:41:16 +0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 08 Mar 2003 19:42:31 -0800 Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") From: Sandy Klausner To: Message-ID: In-Reply-To: <5.1.1.6.0.20030308162127.0385e718@thinkalong.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3129997351_21988388" Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3129997351_21988388 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Jack, First, from our perspective, we believe that a converged structural and behavioral model is required to bring context and coherence to the systems world. A context incorporates conventional software object-oriented semantics, however its model deals more precisely with knowledge through higher order cognitive constructs. These semantics are layered on top of a software object, one that employs inheritance, encapsulation and polymorphic language mechanisms. Approaching system development from a context information modeling perspective is particularly valuable for aligning complex and variable requirements, even across a multitude of organizations with different processes. Topic maps is just one corner for such a converged world. At this time, let me introduce you to CoreSystem. Please download a comprehensive CoreSystem animated illustration from the following FTP site: http://www.cyberseek.com/Coretalk/CoreSystem.PC.zip Or for the Mac: http://www.cyberseek.com/Coretalk/CoreSystem.MAC.zip You will probably be most interested in reviewing the Knowledge Space element of CoreSystem for a discussion of Topic Maps (frame 13). Cheers, Sandy > At 01:55 PM 3/8/2003, Sandy Klausner wrote: >> A resource is context, whereas a topic is content. > > I would think that, technically speaking, resources are not topics, but > they can be the subjects of topics, and, thus, treated as if they are topics. > > Now, a resource as context? And a topic as content? > > Please explain. > > > --------------------------------------------------------------------------- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally to reduce the need for smarter bombs. > > > --B_3129997351_21988388 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Gzz]  RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a S= tandard Graph-Based...") Jack,

First, from our perspective, we believe that a converged structural and beh= avioral model is required to bring context and coherence to the systems worl= d. A context incorporates conventional software object-oriented semantics, h= owever its model deals more precisely with knowledge through higher order co= gnitive constructs. These semantics are layered on top of a software object,= one that employs inheritance, encapsulation and polymorphic language mechan= isms. Approaching system development from a context information modeling per= spective is particularly valuable for aligning complex and variable requirem= ents, even across a multitude of organizations with different processes.

Topic maps is just one corner for such a converged world. At this time, let= me introduce you to CoreSystem. Please download a comprehensive CoreSystem = animated illustration from the following FTP site:

http://www.cyberseek.com/Coretalk/CoreSystem.PC.zi= p
Or for the Mac:
http://www.cyberseek.com/Coretalk/CoreSystem.MAC.z= ip

You will probably be most interested in reviewing the Knowledge Space eleme= nt of CoreSystem for a discussion of Topic Maps (frame 13).

Cheers,

Sandy


> At 01:55 PM 3/8/2003, Sandy Klausner wrote:
>> A resource is context, whereas a topi= c is content.
>
> I would think that, technically speaking, resources are not topics, bu= t
> they can be the subjects of topics, and, thus, treated as if they are = topics.
>
> Now, a resource as context? And a topic as content?
>
> Please explain.
>
>
> ----------------------------------------------------------------------= -----
> XML Topic Maps: Creating and Using Topic Maps for the Web.
> Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor
>
> Build smarter kids globally to reduce the need for smarter bombs.
>
>
>
--B_3129997351_21988388-- From owner-ba-ohs-talk@bootstrap.org Sat Mar 8 21:38:13 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 0FE6D56FF7; Sat, 8 Mar 2003 21:38:12 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by bi0.bootstrap.org (Postfix) with SMTP id B373C56FF5 for ; Sat, 8 Mar 2003 21:38:11 -0800 (PST) Received: from pacbell.net ([63.206.93.73]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HBG00F1XWMBG3@mta6.snfc21.pbi.net> for ba-ohs-talk@bootstrap.org; Sat, 08 Mar 2003 21:58:59 -0800 (PST) Date: Sat, 08 Mar 2003 22:01:23 -0800 From: Rod Welch Subject: [ba-ohs-talk] Re-birth of Principles and Learning To: ba-ohs-talk@bootstrap.org Message-id: <3E6AD8B3.425E2F77@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3E6A2B27.80203@gmx.de> <5.1.1.6.0.20030308162845.03861ec0@thinkalong.com> Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Jack, Good to hear people are learning principles and developing use cases. Who is teaching the class? Are there crib notes available? Progress on RDF and topic maps is good news, spurred by your book and the bright minds engaging the problem who are now seasoned by experience the past few years. Rod ******************* Jack Park wrote: > > At 02:34 PM 3/8/2003, Rod Welch wrote: > >Glad to see OHS/DKR coming to life as spring nears. > > Rod, > > At the moment, ohs-talk is being used for precisely what it was intended: > hammering out underlying principles, use cases, and so forth. Everyone > here, myself included, is busy learning. > > The RDF topic, itself, is an important one and really needs lots of > demonstrations in order to tease out the relative merits it brings to the > implementation table. There are some really smart people playing with both > RDF and topic maps. I think we are going to see some really powerful > implementations spring to life pretty soon now. > > Cheers > Jack > > --------------------------------------------------------------------------- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally to reduce the need for smarter bombs. From owner-ba-ohs-talk@bootstrap.org Sun Mar 9 16:51:42 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 6C5B256FF7; Sun, 9 Mar 2003 16:51:41 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp01.wlv.untd.com (smtp01.wlv.untd.com [209.247.163.57]) by bi0.bootstrap.org (Postfix) with SMTP id BAAD056FF5 for ; Sun, 9 Mar 2003 16:51:39 -0800 (PST) Received: (qmail 18740 invoked from network); 10 Mar 2003 01:12:30 -0000 Received: from dsc01-oav-ca-1-97.rasserver.net (HELO netzero.net) (204.30.193.97) by smtp01.wlv.untd.com with SMTP; 10 Mar 2003 01:12:30 -0000 Message-ID: <3E6BE743.3090901@netzero.net> Date: Sun, 09 Mar 2003 17:15:47 -0800 From: "John J. Deneen" User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Subject: Re: [ba-ohs-talk] Re-birth of Principles and Learning References: <3E6A2B27.80203@gmx.de> <5.1.1.6.0.20030308162845.03861ec0@thinkalong.com> <3E6AD8B3.425E2F77@pacbell.net> Content-Type: multipart/alternative; boundary="------------090709090204020800000409" Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org --------------090709090204020800000409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Rod, Prof. Robert Wilensky , at UC Berkeley teachs a class in Digital Library Resources as a Basis for Collaborative Work Here is an overview of the current project and a Clustering demo relative to the important history of "The Fine Arts" Kobus's official demo (in PowerPoint), including more details about the capabilities of the Multivalent Doument Browser: RESIDU Multivalent Robust Hyperlinks Robust Locations CQF clustering shape Afer your review and analysis of the above links, may be there is an interest to audit and/or register for the class for "sharing the bootstrap" after analyzing, evaluating and comparing with SDS technology? Rod Welch wrote: >Jack, > >Good to hear people are learning principles and developing use >cases. Who is teaching the class? Are there crib notes >available? > >Progress on RDF and topic maps is good news, spurred by your book >and the bright minds engaging the problem who are now seasoned by >experience the past few years. > >Rod > >******************* > >Jack Park wrote: > > >>At 02:34 PM 3/8/2003, Rod Welch wrote: >> >> >>>Glad to see OHS/DKR coming to life as spring nears. >>> >>> >>Rod, >> >>At the moment, ohs-talk is being used for precisely what it was intended: >>hammering out underlying principles, use cases, and so forth. Everyone >>here, myself included, is busy learning. >> >>The RDF topic, itself, is an important one and really needs lots of >>demonstrations in order to tease out the relative merits it brings to the >>implementation table. There are some really smart people playing with both >>RDF and topic maps. I think we are going to see some really powerful >>implementations spring to life pretty soon now. >> >>Cheers >>Jack >> >>--------------------------------------------------------------------------- >>XML Topic Maps: Creating and Using Topic Maps for the Web. >>Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor >> >>Build smarter kids globally to reduce the need for smarter bombs. >> >> > > > > --------------090709090204020800000409 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rod,

Prof. Robert Wilensky, at UC Berkeley teachs a class in  Digital Library Resources as a Basis for Collaborative Work Here is an overview of the current project and a Clustering demo relative to the important history of "The Fine Arts"  Kobus's official demo (in PowerPoint), including more details about the capabilities of the Multivalent Doument Browser:

RESIDU
Multivalent
Robust Hyperlinks
Robust Locations
CQF
clustering
shape

Afer your review and analysis of the above links, may be there is an interest to audit and/or register for the class for "sharing the bootstrap" after analyzing, evaluating and comparing with SDS technology?

Rod Welch wrote:
Jack,

Good to hear people are learning principles and developing use
cases.  Who is teaching the class?  Are there crib notes
available?

Progress on RDF and topic maps is good news, spurred by your book
and the bright minds engaging the problem who are now seasoned by
experience the past few years.

Rod

*******************

Jack Park wrote:
  
At 02:34 PM 3/8/2003, Rod Welch wrote:
    
Glad to see OHS/DKR coming to life as spring nears.
      
Rod,

At the moment, ohs-talk is being used for precisely what it was intended:
hammering out underlying principles, use cases, and so forth. Everyone
here, myself included, is busy learning.

The RDF topic, itself, is an important one and really needs lots of
demonstrations in order to tease out the relative merits it brings to the
implementation table. There are some really smart people playing with both
RDF and topic maps. I think we are going to see some really powerful
implementations spring to life pretty soon now.

Cheers
Jack

---------------------------------------------------------------------------
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor

Build smarter kids globally to reduce the need for smarter bombs.
    


  

--------------090709090204020800000409-- From owner-ba-ohs-talk@bootstrap.org Sun Mar 9 19:30:48 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id DB67856FF7; Sun, 9 Mar 2003 19:30:47 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by bi0.bootstrap.org (Postfix) with SMTP id 5E2C456FF5 for ; Sun, 9 Mar 2003 19:30:46 -0800 (PST) Received: from pacbell.net ([63.206.92.202]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HBI00EIWLDXHX@mta5.snfc21.pbi.net> for ba-ohs-talk@bootstrap.org; Sun, 09 Mar 2003 19:51:34 -0800 (PST) Date: Sun, 09 Mar 2003 19:53:59 -0800 From: Rod Welch Subject: [ba-ohs-talk] Principles and Learning KM To: ba-ohs-talk@bootstrap.org Message-id: <3E6C0C57.10696F85@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3E6A2B27.80203@gmx.de> <5.1.1.6.0.20030308162845.03861ec0@thinkalong.com> <3E6AD8B3.425E2F77@pacbell.net> <3E6BE743.3090901@netzero.net> Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org John, Thanks for the pointer to Bob Wilensky's important work at UCB, shown in your letter today. I have done a fair amount of review and analysis already, which lead to SDS. For example, on 890523 issues on flexible structure were reviewed.... http://www.welchco.com/sd/08/00101/02/89/05/23/065052.HTM#P13O On 900303 connectionist theory in cognitive science was reviewed in relation to building knowledge through "stories".... http://www.welchco.com/sd/08/00101/02/90/03/03/221844.HTM#3016 On 900319 reviewed cognitive science in relation to the role of time in understanding human memory and the process of constructing causation.... http://www.welchco.com/sd/08/00101/02/90/03/19/213447.HTM#1323 Won't list it all, but there is a considerable body of research that underlies the design of SDS, which is summarized in POIMS, NWO, etc. SDS enables pulling this research into a coherent report in about 10 seconds covering some 15 years. SDS enables assembling several hundred primary views and thousands of subsidiary views that place research in useful contexts. From what I can see of the main headings in your letter, Bob's class on library management addresses this objective. On 001130 Jack Park wrote a letter to the group saying roughly that SDS has the right structure for knowledge and the interface that makes the structure useful for people.... http://www.welchco.com/sd/08/00101/02/00/11/30/193621.HTM#H17O So far as I know, there is nothing else available that does this. Jack has done a lot of research, and he has not mentioned anything else. Apart from Jack's generous comments, there is a body of SDS records demonstrating that SDS enables a routine intelligence process for converting information into knowledge, explained in POIMS. Under Drucker's criteria in his article on 991025, "routinizing" the application of cognitive science through technology, like SDS does, is a useful solution. As you and Eric Armstrong point out, SDS takes more than 20 minutes to learn, which is understandably discouraging, as reported on 890809.... http://www.welchco.com/sd/08/00101/02/89/08/09/210337.HTM#5U6K People have difficulty moving from IT to a new way of working with SDS that integrates a whole range of tasks, because, in the beginning, transformation seems overwhelming.... http://www.welchco.com/sd/08/00101/02/89/08/09/214314.HTM#6162 ...but is none-the-less essential to augment intelligence for saving time and money and lives. Bill Gates seems to agree, pointing out on 011108 that he is working at Microsoft on integration so that people can use more than 5% of the commands he has come up with over the past 20 years, which studies indicate is about what most people are using now.... http://www.welchco.com/sd/08/00101/02/02/11/08/084723.HTM#EFBE In any case, this is a side issue relative to your suggestion for me to look at some links. Since I am a proponent of links and crashed on opening links in your letter today, there is a burden to attempt an explanation that reconciles the disparity between offering links and not opening other folks links. First, I clicked on a couple of links in your letter, maybe all of them. These turned out to be more Powerpoint presentations. Limitations of Powerpoint for doing knowledge work were explained in a letter several days ago. At that time, despite limitations, I bit the bullet and spent a couple of three hours or so analyzing the material you cited on MyLiftBits. The only reason I did that was to demonstrate what "analysis" means. Some months ago Jack suggested using "constructivist" methods, rather than hammer away trying to be instructivist.... http://www.welchco.com/sd/08/00101/02/02/09/24/110735.HTM#RN8L I thought possibly demonstrating how to do "analysis" by taking specific language in source material and placing it the context of objectives, requirements and commitments, and then listing out relevant experience and commenting on correlations, implications and nuance, as shown by the few examples listed above, that this effort would be less instructivist and get closer to Jack's suggestion. The question of whether to invest time for anything always entails a cost benefit consideration. Where people are just learning because nothing that has been tried so far has worked, Bob's class might be useful. However, there is a different calculus where there is a system in place. In this latter case, the core issue with respect to investing time for reviewing Bob's work at Cal is whether there is available work product demonstrating that anything he may present can advance the work already performed. This places a threshold burden on people recommending new material to show relevance and potential for improvement. As an example, USACE reported that SDS implements Com Metrics that saves time and money at the rate of 10:1, which lines up pretty well with the general concept that knowledge is more powerful than information. Your letter today would excite interest, if it said that something in Bob's class can reasonably be expected to increase the return to 12:1 or 15:1, etc. Another issue that would be attractive is that Bob's class will help people grasp the power of deferred rewards, or overcome fear of accountability, or laziness, which Jack cited on 010908 as restraining transition to a new way of working. If there is evidence that Bob knows anything about these big ticket issues, then that should be presented to support investing time for me to make the review you are proposing This is nothing new. Recall that Eric Armstrong raised this issue on 011003. At that time, Eric requested guidance on when to go off and invest time clicking on a link to something or other. One criteria proposed is demonstrating some preliminary alignment with objectives, requirements and commitments. Another criteria is analysis showing that people can save time and money and lives by implementation to replace or supplement whatever is being done currently.... http://www.welchco.com/sd/08/00101/02/01/10/03/160603.HTM#M16F These criteria suggest focusing research on things that have a demonstrated track record, under the general rule to: study what works. Recall Jack raised this idea on 000504, and worried that for some reason there is reluctance to make that study. This leads to the proposition that transformation from information to a culture of knowledge begins with study and ultimately requires opportunity to gain experience using a new way of working that integrates the gift of time with the power of knowledge. Rod **************** > "John J. Deneen" wrote: > > Rod, > > Prof. Robert Wilensky, at UC Berkeley teachs a class in > Digital Library Resources as a Basis for Collaborative Work > Here is an overview of the current project and a Clustering > demo relative to the important history of "The Fine Arts" > Kobus's official demo (in PowerPoint), including more details > about the capabilities of the Multivalent Doument Browser: > > RESIDU > Multivalent > Robust Hyperlinks > Robust Locations > CQF > clustering > shape > > Afer your review and analysis of the above links, may be there > is an interest to audit and/or register for the class for > "sharing the bootstrap" after analyzing, evaluating and > comparing with SDS technology? > > Rod Welch wrote: > > > Jack, > > > > Good to hear people are learning principles and developing > > use > > cases. Who is teaching the class? Are there crib notes > > available? > > > > Progress on RDF and topic maps is good news, spurred by your > > book > > and the bright minds engaging the problem who are now > > seasoned by > > experience the past few years. > > > > Rod > > > > ******************* > > > > Jack Park wrote: > > > > > >> At 02:34 PM 3/8/2003, Rod Welch wrote: > >> > >> > >> > Glad to see OHS/DKR coming to life as spring nears. > >> > > >> > > >> Rod, > >> > >> At the moment, ohs-talk is being used for precisely what it > >> was intended: > >> hammering out underlying principles, use cases, and so > >> forth. Everyone > >> here, myself included, is busy learning. > >> > >> The RDF topic, itself, is an important one and really needs > >> lots of > >> demonstrations in order to tease out the relative merits it > >> brings to the > >> implementation table. There are some really smart people > >> playing with both > >> RDF and topic maps. I think we are going to see some really > >> powerful > >> implementations spring to life pretty soon now. > >> > >> Cheers > >> Jack > >> > >> > >> --------------------------------------------------------------------------- > >> XML Topic Maps: Creating and Using Topic Maps for the Web. > >> Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical > >> Editor > >> > >> Build smarter kids globally to reduce the need for smarter > >> bombs. > >> > >> > > > > > > From owner-ba-ohs-talk@bootstrap.org Sun Mar 9 19:55:11 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 1CD0C56FF7; Sun, 9 Mar 2003 19:55:11 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from hot.burningchrome.com (cust-216-9-146-10.bton.kiva.net [216.9.146.10]) by bi0.bootstrap.org (Postfix) with SMTP id 50BEE56FF5 for ; Sun, 9 Mar 2003 19:55:09 -0800 (PST) Received: from cust-216-9-146-10.bton.kiva.net (cust-216-9-146-10.bton.kiva.net [216.9.146.10]) by hot.burningchrome.com (8.11.2/8.11.2) with ESMTP id h2A4Ful29784 for ; Sun, 9 Mar 2003 23:15:56 -0500 Date: Sun, 9 Mar 2003 23:15:56 -0500 (EST) From: Chris Dent To: Subject: Re: [ba-ohs-talk] Principles and Learning KM In-Reply-To: <3E6C0C57.10696F85@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Sun, 9 Mar 2003, Rod Welch wrote: > I have done a fair amount of review and analysis already, which > lead to SDS. For example, on 890523 issues on flexible structure > were reviewed.... Rod, I can't recall; is SDS freely available for experimentation and use by others? Thanks. -- Chris Dent http://www.burningchrome.com/~cdent/ "The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary." --H. L. Mencken From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 01:32:09 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 9E29356FF7; Mon, 10 Mar 2003 01:32:08 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by bi0.bootstrap.org (Postfix) with SMTP id 436F956FF5 for ; Mon, 10 Mar 2003 01:32:07 -0800 (PST) Received: from h-68-165-69-207.snvacaid.covad.net ([68.165.69.207] helo=[192.168.1.222]) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sJxj-0000LE-00; Mon, 10 Mar 2003 01:52:51 -0800 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Mar 2003 01:52:51 -0800 Subject: Re: urn-5 vs hashes (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) From: Kevin Keck To: Cc: GZZ developers Message-ID: In-Reply-To: <3E6A4265.1020402@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org on 2003/03/08 11:20 AM, Benja Fallenstein at b.fallenstein@gmx.de wrote: > > Hi Toni-- > > Alatalo Toni wrote: >> On Sat, 8 Mar 2003, Danny Ayers wrote: >>> Hmm, I'm sure you have good reason to use something other than URIs for > > (replied to Danny by private mail) > >> afaik the cryptographic content hash forms the URI (urn-5) > > Nope, urn:urn-5 is for random numbers (when you create a new node and > want to assign a random URI to it) and is not related to hashes. There's > no URI scheme or URN namespace for hashed data, yet (AFAIK). > > (Sorry to send this thru the lists, but it would be bad if this > misconception stood without refutation...) > > - Benja Actually, there's at least three used with the various file sharing apps: MAGNET, apparently supported by some Gnutella programs. Uses sha1. Example: eDonkey ed2k URIs, which use MD4. Example: sig2dat URIs, used with Kazaa, Grokster, etc. Not sure what hash. Example: -- Kevin Keck keck@kecklabs.com From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 01:44:13 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 112FB56FF7; Mon, 10 Mar 2003 01:44:13 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp3.cp.tin.it (vsmtp3.tin.it [212.216.176.223]) by bi0.bootstrap.org (Postfix) with SMTP id 4DCE956FF5 for ; Mon, 10 Mar 2003 01:44:10 -0800 (PST) Received: from trotter (212.171.206.99) by smtp3.cp.tin.it (6.5.033) id 3E48CE9F00A4D174; Mon, 10 Mar 2003 11:04:54 +0100 From: "Danny Ayers" To: Cc: "Benja Fallenstein" , "GZZ developers" Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Mon, 10 Mar 2003 11:03:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org (heh - I take Sunday off and by Monday morning the inbox is full, what a 24/7 world this is!) > but quite often with rdf one node may be in several places on one canvas, > with the views we are using that is. or did i miss the point here? Do you have an example of this? I'm having trouble thinking where this might be needed.. Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 01:57:50 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 02A2B56FF7; Mon, 10 Mar 2003 01:57:49 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp2.cp.tin.it (vsmtp2.tin.it [212.216.176.222]) by bi0.bootstrap.org (Postfix) with SMTP id DC2A956FF5 for ; Mon, 10 Mar 2003 01:57:46 -0800 (PST) Received: from trotter (212.171.206.99) by smtp2.cp.tin.it (6.5.033) id 3E660875001AFF22 for ba-ohs-talk@bootstrap.org; Mon, 10 Mar 2003 11:18:31 +0100 From: "Danny Ayers" To: Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a StandardGraph-Based...") Date: Mon, 10 Mar 2003 11:17:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C2E6F6.9CE17600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C2E6F6.9CE17600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")Hi Sandy et al, I'm just waiting for the download, it is rather large... Sandy said: First, from our perspective, we believe that a converged structural and behavioral model is required to bring context and coherence to the systems world. A context incorporates conventional software object-oriented semantics, however its model deals more precisely with knowledge through higher order cognitive constructs. These semantics are layered on top of a software object, one that employs inheritance, encapsulation and polymorphic language mechanisms. Approaching system development from a context information modeling perspective is particularly valuable for aligning complex and variable requirements, even across a multitude of organizations with different processes. Danny: Couldn't most of this be said about *any* knowledge representation system written in an OO language? If I write a Java class called 'Concept', it incorporates OO semantics, (inheritance, encapsulation and polymorphic language mechanisms). If I give it an attribute 'name' with accessor methods, I've added a higher order cognitive construct... So I'm not really getting an idea of what a 'context' (in this context ;-) actually is. Would I be right in thinking the aims are something like those of Network Inference: http://www.networkinference.com/ Now at 36%... Cheers, Danny. Topic maps is just one corner for such a converged world. At this time, let me introduce you to CoreSystem. Please download a comprehensive CoreSystem animated illustration from the following FTP site: http://www.cyberseek.com/Coretalk/CoreSystem.PC.zip Or for the Mac: http://www.cyberseek.com/Coretalk/CoreSystem.MAC.zip You will probably be most interested in reviewing the Knowledge Space element of CoreSystem for a discussion of Topic Maps (frame 13). Cheers, Sandy > At 01:55 PM 3/8/2003, Sandy Klausner wrote: >> A resource is context, whereas a topic is content. > > I would think that, technically speaking, resources are not topics, but > they can be the subjects of topics, and, thus, treated as if they are topics. > > Now, a resource as context? And a topic as content? > > Please explain. > > > -------------------------------------------------------------------------- - > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally to reduce the need for smarter bombs. > > > ------=_NextPart_000_000C_01C2E6F6.9CE17600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Gzz]  RE: [ba-ohs-talk] Fenfire, RDF (re = "Towards a Standard Graph-Based...")
Hi Sandy et=20 al,
 
I'm just = waiting for the=20 download, it is rather large...
 Sandy said: 
First, from=20 our perspective, we believe that a converged structural and behavioral = model=20 is required to bring context and coherence to the systems world. A = context=20 incorporates conventional software object-oriented semantics, however = its=20 model deals more precisely with knowledge through higher order = cognitive=20 constructs. These semantics are layered on top of a software object, = one that=20 employs inheritance, encapsulation and polymorphic language = mechanisms.=20 Approaching system development from a context information modeling = perspective=20 is particularly valuable for aligning complex and variable = requirements, even=20 across a multitude of organizations with different processes.
 
 
Danny:
Couldn't most = of this be=20 said about *any* knowledge representation system written in an OO = language? If=20 I write a Java class called 'Concept', it incorporates OO semantics,=20 (inheritance, encapsulation and polymorphic language mechanisms). If I = give it=20 an attribute 'name' with accessor methods, I've added a higher = order=20 cognitive construct...
 
So I'm not = really getting=20 an idea of what a 'context' (in this context ;-) actually is.=20
 
Would I be = right in=20 thinking the aims are something like those of Network=20 Inference:
http://www.networkinference.com= /
 
Now at=20 36%...
 
Cheers,
Danny.
 
Topic=20 maps is just one corner for such a converged world. At this time, let = me=20 introduce you to CoreSystem. Please download a comprehensive = CoreSystem=20 animated illustration from the following FTP site:

http://www.cyberseek.com/Coretalk/CoreSystem.PC.zipOr=20 for the Mac:
http://www.cyberseek.com/Coretalk/CoreSystem.MAC.zip
You=20 will probably be most interested in reviewing the Knowledge Space = element of=20 CoreSystem for a discussion of Topic Maps (frame=20 13).

Cheers,

Sandy


> At 01:55 PM 3/8/2003, Sandy Klausner = wrote:
>> A resource is context, whereas a = topic is=20 content.
> =
> I would=20 think that, technically speaking, resources are not topics, but =
> they=20 can be the subjects of topics, and, thus, treated as if they are=20 topics.
>
> Now, a resource as context? And a topic as=20 content?
>
> Please explain.
>
>
>=20 = -------------------------------------------------------------------------= --
>=20 XML Topic Maps: Creating and Using Topic Maps for the Web.
>=20 Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical = Editor
>=20
> Build smarter kids globally to reduce the need for smarter=20 bombs.
>
>
>=20
------=_NextPart_000_000C_01C2E6F6.9CE17600-- From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 07:11:39 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 2CC9356FF7; Mon, 10 Mar 2003 07:11:38 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 0979256FF5 for ; Mon, 10 Mar 2003 07:11:35 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h2AFWM2N019786; Mon, 10 Mar 2003 17:32:22 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h2AFWMFG019779; Mon, 10 Mar 2003 17:32:22 +0200 Date: Mon, 10 Mar 2003 17:32:22 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: Benja Fallenstein , GZZ developers Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Mon, 10 Mar 2003, Danny Ayers wrote: > (heh - I take Sunday off and by Monday morning the inbox is full, what a > 24/7 world this is!) uh, scary too.. > > but quite often with rdf one node may be in several places on one canvas, > Do you have an example of this? I'm having trouble thinking where this might A | B-A > Danny. ~Toni From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 07:15:12 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 94E0556FF7; Mon, 10 Mar 2003 07:15:11 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by bi0.bootstrap.org (Postfix) with SMTP id 6CE4E56FF5 for ; Mon, 10 Mar 2003 07:15:10 -0800 (PST) Received: from [192.168.1.100] (12-234-6-28.client.attbi.com[12.234.6.28]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003031015355805100iqsf1e>; Mon, 10 Mar 2003 15:35:58 +0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Mon, 10 Mar 2003 07:37:11 -0800 Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a StandardGraph-Based...") From: Sandy Klausner To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3130126631_54967" Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3130126631_54967 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >> Danny: >> Couldn't most of this be said about *any* knowledge representation syste= m >> written in an OO language? If I write a Java class called 'Concept', it >> incorporates OO semantics, (inheritance, encapsulation and polymorphic >> language mechanisms). If I give it an attribute 'name' with accessor met= hods, >> I've added a higher order cognitive construct... Danny, Adding =B3meat=B2 to an object like a =8Cname=B9 with accessor methods is going vertical with domain specific details. =B3Context=B2 extends horizontal concept= s that comprise general systems theory. The animated illustration provides explanation. Cheers, Sandy --B_3130126631_54967 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Gzz]  RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a S= tandardGraph-Based...")
Danny:
Couldn't most of this be said about *any* knowledge representation system w= ritten in an OO language? If I write a Java class called 'Concept', it incor= porates OO semantics, (inheritance, encapsulation and polymorphic language m= echanisms). If I give it an attribute 'name' with accessor methods, I've add= ed a higher order cognitive construct...

Danny,

Adding “meat” to an object like a ‘name’ with acces= sor methods is going vertical with domain specific details. “Co= ntext” extends horizontal concepts that comprise general system= s theory. The animated illustration provides explanation.

Cheers,

Sandy
--B_3130126631_54967-- From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 07:20:05 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 9FA4857023; Mon, 10 Mar 2003 07:20:04 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id 98BCD56FF5 for ; Mon, 10 Mar 2003 07:20:02 -0800 (PST) Received: (qmail 16353 invoked by uid 0); 10 Mar 2003 15:40:54 -0000 Received: from pD958800F.dip.t-dialin.net (HELO gmx.de) (217.88.128.15) by mail.gmx.net (mp002-rz3) with SMTP; 10 Mar 2003 15:40:54 -0000 Message-ID: <3E6CB1FD.7020604@gmx.de> Date: Mon, 10 Mar 2003 16:40:45 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: Re: urn-5 vs hashes (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Kevin-- Kevin Keck wrote: >> There's >>no URI scheme or URN namespace for hashed data, yet (AFAIK). > > Actually, there's at least three used with the various file sharing apps: > > MAGNET, apparently supported by some Gnutella programs. Uses sha1. Example: > > > eDonkey ed2k URIs, which use MD4. Example: > > > sig2dat URIs, used with Kazaa, Grokster, etc. Not sure what hash. Example: > ash/kHiGJMFBOMT2rdMU=|> Sorry, I should have been clearer, but by URI scheme I meant registered URI scheme. (I believe in the power of standards :-) ) If I'm not mistaken, none of the above is registered. - Benja From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 09:16:25 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 71C9D56FF7; Mon, 10 Mar 2003 09:16:24 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by bi0.bootstrap.org (Postfix) with SMTP id 0EF2356FF5 for ; Mon, 10 Mar 2003 09:16:22 -0800 (PST) Received: from [192.168.1.100] (12-234-6-28.client.attbi.com[12.234.6.28]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003031017371100100j9e8te>; Mon, 10 Mar 2003 17:37:11 +0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Mon, 10 Mar 2003 09:38:24 -0800 Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") From: Sandy Klausner To: Jack Park , Message-ID: In-Reply-To: <5.1.1.6.0.20030310080455.03436430@thinkalong.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Jack, File problem has been fixed. Go ahead and take a fresh download. Sandy > >> >> http://www.cyberseek.com/Coretalk/CoreSystem.PC.zip > > Zip will not open that file: crc error. > Jack > > > --------------------------------------------------------------------------- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally to reduce the need for smarter bombs. > > > From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 09:45:12 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 3620E56FF7; Mon, 10 Mar 2003 09:45:11 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp1.cp.tin.it (vsmtp1.tin.it [212.216.176.221]) by bi0.bootstrap.org (Postfix) with SMTP id 1CF6456FF5 for ; Mon, 10 Mar 2003 09:45:09 -0800 (PST) Received: from trotter (213.45.118.98) by smtp1.cp.tin.it (6.5.033) id 3E3AA8B600EA1D92; Mon, 10 Mar 2003 19:05:53 +0100 From: "Danny Ayers" To: Cc: "Benja Fallenstein" , "GZZ developers" Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Mon, 10 Mar 2003 19:04:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > > > but quite often with rdf one node may be in several places on > one canvas, > > Do you have an example of this? I'm having trouble thinking > where this might > > A > | > B-A Still having trouble :-( What does this offer that A-B doesn't? When might it be useful in practice? Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 11:06:16 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 8325456FF7; Mon, 10 Mar 2003 11:06:15 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 4163456FF5 for ; Mon, 10 Mar 2003 11:06:13 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h2AJR02N022147; Mon, 10 Mar 2003 21:27:00 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h2AJQx8X022144; Mon, 10 Mar 2003 21:26:59 +0200 Date: Mon, 10 Mar 2003 21:26:59 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: Danny Ayers Cc: ba-ohs-talk@bootstrap.org, GZZ developers , Benja Fallenstein Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Mon, 10 Mar 2003, Danny Ayers wrote: > > > Do you have an example of this? I'm having trouble thinking > > where this might > > A > > | > > B-A > Still having trouble :-( i'm sorry, that was a bad example -- i should have tried to explain. i did try to construct a more meaningful one, which i try to repeat below. otherwise there's a screenshot how a situation like this occurred to me when i was working today, but it's not a very good one (yet). bu do feel free to see http://an.org/fenfire/gzigzag.png and the difference to gzigzag2.png (which is not there yet but i try to make it when have time :) fortunately, your question is helpful to answer: > What does this offer that > A-B > doesn't? When might it be useful in practice? if y and x axis are (sematically) different. you could reconstruct it in rdf by saying: A y B B x A (which is the order i do them in hierarchical trees in zzstructure, when y and x are simply d.1 and d2. (using d.clone in the z-axis) so in a rdf graph it might appear as: A | |-x | B---A | y where A is the same node in differenct places on one canvas. (m.o.t.?) > Cheers, > Danny. wishfully, ~Toni From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 13:46:12 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 448A656FF7; Mon, 10 Mar 2003 13:46:11 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sarge.grantbow.com (12-233-20-180.client.attbi.com [12.233.20.180]) by bi0.bootstrap.org (Postfix) with SMTP id E817E56FF5 for ; Mon, 10 Mar 2003 13:46:09 -0800 (PST) Received: from grantbow by sarge.grantbow.com with local (Exim 3.36 #1 (Debian)) id 18sVQ7-0002ko-00 for ; Mon, 10 Mar 2003 14:06:55 -0800 Date: Mon, 10 Mar 2003 14:06:54 -0800 From: Grant Bowman To: ba-ohs-talk@bootstrap.org Subject: Re: urn-5 vs hashes (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) Message-ID: <20030310220653.GD9020@grantbow.com> Mail-Followup-To: ba-ohs-talk@bootstrap.org References: <3E6CB1FD.7020604@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6CB1FD.7020604@gmx.de> User-Agent: Mutt/1.4i Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org * Benja Fallenstein [030310 07:47]: > Kevin Keck wrote: > >Actually, there's at least three used with the various file sharing apps: > > > >MAGNET, apparently supported by some Gnutella programs. Uses sha1. Example: > > > > > >eDonkey ed2k URIs, which use MD4. Example: > > > > > >sig2dat URIs, used with Kazaa, Grokster, etc. Not sure what hash. Example: > > >ash/kHiGJMFBOMT2rdMU=|> > > Sorry, I should have been clearer, but by URI scheme I meant registered > URI scheme. (I believe in the power of standards :-) ) If I'm not > mistaken, none of the above is registered. Hi Benja, Standard is a debatable word. What good is a standard that's architected perfectly but NEVER implemented and used? I would rather have a de-facto standard that is useful and helps people accomplish things on a daily basis over an academic standard any day. Cheers, -- -- Grant Bowman From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 14:56:29 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id C6F0256FF7; Mon, 10 Mar 2003 14:56:28 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bi0.bootstrap.org (Postfix) with SMTP id BBF3F56FF5 for ; Mon, 10 Mar 2003 14:56:26 -0800 (PST) Received: (qmail 7930 invoked by uid 0); 10 Mar 2003 23:17:17 -0000 Received: from pD9E12FD0.dip.t-dialin.net (HELO gmx.de) (217.225.47.208) by mail.gmx.net (mp023-rz3) with SMTP; 10 Mar 2003 23:17:17 -0000 Message-ID: <3E6D1CF4.10400@gmx.de> Date: Tue, 11 Mar 2003 00:17:08 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Subject: Re: urn-5 vs hashes (was: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")) References: <3E6CB1FD.7020604@gmx.de> <20030310220653.GD9020@grantbow.com> In-Reply-To: <20030310220653.GD9020@grantbow.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Grant-- Grant Bowman wrote: > * Benja Fallenstein [030310 07:47]: >>Kevin Keck wrote: >> >>>Actually, there's at least three used with the various file sharing apps: >>> >>>MAGNET, apparently supported by some Gnutella programs. Uses sha1. Example: >>> >>> >>>eDonkey ed2k URIs, which use MD4. Example: >>> >>> >>>sig2dat URIs, used with Kazaa, Grokster, etc. Not sure what hash. Example: >>>>>ash/kHiGJMFBOMT2rdMU=|> >> >>Sorry, I should have been clearer, but by URI scheme I meant registered >>URI scheme. (I believe in the power of standards :-) ) If I'm not >>mistaken, none of the above is registered. > > Standard is a debatable word. What good is a standard that's > architected perfectly but NEVER implemented and used? I would rather > have a de-facto standard that is useful and helps people accomplish > things on a daily basis over an academic standard any day. I need a bit of context here. Are you talking about a specific design decision, or are you just making a general statement? I originally said there's no URI scheme for hashed data as far as I know. As an end in itself, the issue of 'is there an URI scheme that...' is a rather academic question :-) But for us there's a practical background: As a supporting technology for Fenfire, we're developing a system called Storm in which all information is stored in 'blocks' (immutable byte sequences) identified by cryptographic hashes. One of the stated design goals is that, as long as the hash function isn't broken, blocks stored in our system can still be used in, say, thirty years-- provided there is still an implementation of the then-current version of the spec around. Now, we need a way to map these blocks into URI space. If we talk about how to identify resources for today or the next year, there wouldn't be a problem with using an ad-hoc URI scheme. If we talk about how to identify resources in 30 or 40 years, burdening future developers with non-standard schemes (and possibly handling collisions, should someone in the meantime decide to use e.g. sig2dat in a-- possibly only slightly-- different way). If I use only standard URIs, I know that there is an official definition of its workings from the IETF, and that the change control for it is at the IETF. (To draw an analogy that's as wrong as any, look at how difficult HTML has become to parse because of the many nonstandard extensions; I'm quite confident that there will be *some* implementation of conformant XHTML 1.0 in thirty years, but would you guarantee me that I will still be able to view my Netscape 4-specific DHTML?) If there were any registered URI scheme meeting my needs, I could implement it even if it were a purely academic standard so far. But I would not want to commit to an ed2k or sig2dat URI for my data now. So the question of whether there is a *registered* URI scheme or URN namespace for this has very real consequences, for me. - Benja From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 15:10:16 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id ACED056FF7; Mon, 10 Mar 2003 15:10:15 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bi0.bootstrap.org (Postfix) with SMTP id 8587F56FF5 for ; Mon, 10 Mar 2003 15:10:13 -0800 (PST) Received: (qmail 30020 invoked by uid 0); 10 Mar 2003 23:31:05 -0000 Received: from pD9E12FD0.dip.t-dialin.net (HELO gmx.de) (217.225.47.208) by mail.gmx.net (mp016-rz3) with SMTP; 10 Mar 2003 23:31:05 -0000 Message-ID: <3E6D2033.9090405@gmx.de> Date: Tue, 11 Mar 2003 00:30:59 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Cc: Danny Ayers , GZZ developers Subject: Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Alatalo Toni wrote: > On Mon, 10 Mar 2003, Danny Ayers wrote: >>>A >>>| >>>B-A > >>What does this offer that >>A-B >>doesn't? When might it be useful in practice? > > if y and x axis are (sematically) different. > > you could reconstruct it in rdf by saying: > A y B > B x A > > A > | > |-x > | > B---A > | > y > > where A is the same node in differenct places on one canvas. (m.o.t.?) Hi Danny, Toni-- I think you're talking about different things. Danny is talking about users placing nodes explicitly on the screen, arranging them into spatial structures (as in Ideagraph). Toni is talking about automatic views as in Fenfire Loom (or Gzz/GZigZag), where the program automatically arranges nodes on the screen to convey the underlying RDF structure (or zzstructure). Indeed, in our Loom views, we regularly show the same node multiple times: say that "noteA seeAlso noteB" and "noteB isReasonFor noteA" for example; then, when we focus noteA, noteB is related to it in two ways, and we show it twice because of that. (Sorry, I don't have a screenshot program ready :-/ ) After reflection, I do think that placing the same node at two different locations can make sense, though. In Spatial Hypertext, the arrangement of nodes is used to convey structure as we would on e.g. a conventional blackboard or scratchpad etc. Let's say a user is making groups of people by placing person nodes together in different locations of the screen (spatial canvas). What if a person is in more than one group? (Maybe these kinds of spatial structuring isn't what you're after in Ideagraph; but on the other hand, why allow the user to hand-structure the arrangement of the graph if not to have them make use of that spatial arrangement? In any case, it would be nice if the same vocabulary could be used by other tools that let users arrange things spatially...) - Benja From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 16:54:16 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 7904156FF7; Mon, 10 Mar 2003 16:54:15 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by bi0.bootstrap.org (Postfix) with SMTP id D790856FF5 for ; Mon, 10 Mar 2003 16:54:13 -0800 (PST) Received: from xanadu.net (12-236-185-183.client.attbi.com[12.236.185.183]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2003031101145800300icnqje>; Tue, 11 Mar 2003 01:14:59 +0000 Date: Mon, 10 Mar 2003 17:13:17 -0800 Subject: [ba-ohs-talk] :xu: Serious deep addressing (was Re: ![Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Theodor Nelson , Marlene Mallicoat , andrew , ed , steve , Alatalo Toni , gzz-dev@mail.freesoftware.fsf.org, ba-ohs-talk@bootstrap.org, roger@xanadu.com, jeremyalansmith@freeola.com, eisenman , frank fisher , kleban , mark miller To: Marlene Mallicoat From: Theodor Nelson In-Reply-To: <200302251110_MC3-1-2C56-D5E3@compuserve.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Dear Eric Armstrong: The only thing wrong with your suggestion is that it doesn't go quite far enough. Not just every paragraph, but every character, must be tracked. When you're almost there, why stop? I would recommend another look at the tumbler mathematics by Roger Gregory and Mark Miller, described in *Literary Machines* (you can find an illegal copy on the Web someplace, scanned as muiltipage fax=TIF=jfax). This has the particular mathematical advantage of referring compactly to spans which can encompass both strings and groups of servers, and allowing permutation matrices of such spans. This was the secret inner mechanism of the xu88 software described in *Literary Machines*. This partially-working software (it worked on small scale, supposedly could be debugged to work on super scale) is available open source as "Udanax Green", at udanax.com and sunless-sea.net. All my own current designs are intended to work either standalone or in conjunction with xu88/Udanax Green, if it ever works fully. Best, Ted Nelson > From: Eric Armstrong, INTERNET:eric.armstrong@sun.com > TO: Alatalo Toni, INTERNET:antont@tols16.oulu.fi > CC: GZZ developers, INTERNET:gzz-dev@mail.freesoftware.fsf.org > me, INTERNET:eric.armstrong@sun.com > DATE: 2/24/03 3:38 PM > > RE: [Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool > > > All in all, this is really good news. I understand that refactoring > puts things in a bit of flux at the moment, but the result of it all > will be an excellent segmentation that lets Storm get used in a > variety of projects. It's really rather thrilling. > > On the mathematical side, I woke up the other day and realized > that if I want to track who ever wrote anything, I'll need an > identifier > big enough to identify anyone who has ever lived (for example, > Shakespeare), and to identfiy who makes changes, I'll need one > big enough to identify anyone who ever *will* live. Now, that > identifier is starting to get pretty huge. > > Then, I'll need an identifier for every paragraph in every document > on every computer that ever was or will be constructed. These > are really big numbers now. And when someone corrects a typo > on some page somewhere, that paragraph will need to be versioned, > and the huge-long-identifier of the perpetrator will need to be stored, > along with a date, just to track that one-character change. > > I began to think that, mathematically, perhaps true collaboration in > the form of "global knowledge sharing" was impossible, and that > the best we could do would be some sort of "local cluster", within > which true sharing could go on. > > I look forward to the results of any thinking you guys have done on > this subject, or any research you've managed to find that deals with > it. > > Alatalo Toni wrote: > >> On Fri, 21 Feb 2003, Eric Armstrong wrote: >> >>> Your article has me really intrigued. I've only mangaged to >>> leaf through it so far, but I've seen enough to know that >>> targets the major, critical impediment. >> >> good to hear that it managed to communicate - i hope you don't mind > cc'ing >> this reply to the actual developers .. this way you'll get better >> answers >> to the questions. >> >>> The next step is to evaluate how well it does so. Have you >>> given any thought the mathematical difficulties of the process? >>> (Identifiers have to get simply huge!) >> >> one thing about the evaluation: feel free to get a copy from >> http://savannah.nongnu.org/cvs/?group=gzz and see it work! >> there are some bleeding edge dependencies especially on the GUI side, >> but much less for the storage module. >> >> the project has been using Storm for about 1,5years now, as mentioned >> in >> the article. the p2p networking is under development, but the basics, > like >> creating the block identifiers (and verifying them) are there and >> work. >> >> i personally don't know much about it on the mathematical level, so >> the >> other authors should correct me here, but my understanding is that >> SHA-1 >> hashes are not awfully difficult to deal with. i need to look more >> into >> it, though, also to analyse the applicability in small devices. >> related > to >> p2p networking there are of course several issues, that some of the >> authors are researching. >> >> evaluation is definitely one aspect to develope in the article, too, >> so i >> think it's good to have these comments. >> >>> I know Eugene and some others have given this matter some >>> thought. Have you sent a copy to Eugene, or to the Yak group? >> >> no, not yet - i guess it would be good to hear reviewer's comments >> first. >> >> also, this is bad timing for the reason that the project is in quite a >> flux right now: we agreed on a set of new names on Friday, the whole >> is >> now split to several modules and there are rewrites going on due to >> the >> change of the structure (from zz to rdf, but that's not related to > Storm). >> >> a definite good thing in that reorg is that it will be clearer to use >> the >> modules from outside of the project. so e.g. Storm is a whole of it's >> own >> and can be used independently of the other products of the ex-Gzz >> project >> (Fenfire is the new name, hence it's the Fenfire Storm now). so in a >> week >> or two we should be on firmer ground -- just wanted to reply to you >> immediately as a comment to the promising post on the unrev-list. >> >> looking forward to what becomes of this, >> ~Toni > > > > > > > _______________________________________________ > Gzz-dev mailing list > Gzz-dev@nongnu.org > http://mail.nongnu.org/mailman/listinfo/gzz-dev > > > > > ----------------------- Internet Header > -------------------------------- > Sender: gzz-dev-bounces+marlene=xanadu.net@nongnu.org > Received: from tektih.glasswings.com.au (tektih.glasswings.com.au > [203.8.21.2]) > by siaag2aa.compuserve.com (8.12.7/8.12.7/SUN-2.4) with SMTP id > h1ON5UFH024369 > for <75231.762@compuserve.com>; Mon, 24 Feb 2003 18:05:36 -0500 > (EST) > Received: (qmail 394 invoked by alias); 24 Feb 2003 23:00:29 -0000 > Delivered-To: alias-xanadu-net-marlene@xanadu.net > Received: (qmail 392 invoked by uid 117); 24 Feb 2003 23:00:29 -0000 > Received: from monty-python.gnu.org (HELO monty-python.gnu.org) > (199.232.76.173) by tektih.glasswings.com.au (qpsmtpd/0.20-dev) with > SMTP; > 2003-02-24 23:00:29Z > Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) > by > monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nRVs-0004sb-01 > for > marlene@xanadu.net; Mon, 24 Feb 2003 17:55:56 -0500 > Received: from list by monty-python.gnu.org with tmda-scanned (Exim > 4.10.13) id 18nRVf-0004hr-00 for > gzz-dev@mail.freesoftware.fsf.org; Mon, 24 Feb 2003 17:55:43 -0500 > Received: from mail by monty-python.gnu.org with spam-scanned (Exim > 4.10.13) id 18nRV7-0003rI-00 for > gzz-dev@mail.freesoftware.fsf.org; Mon, 24 Feb 2003 17:55:41 -0500 > Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by > monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nRV0-0003ax-00 > for > gzz-dev@mail.freesoftware.fsf.org; Mon, 24 Feb 2003 17:55:02 -0500 > Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by > nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14487; Mon, > 24 Feb > 2003 14:54:26 -0800 (PST) > Received: from sun.com (d-usca14-129-126 [129.145.129.126]) ESMTP > id > h1OMsPh23037; Mon, 24 Feb 2003 14:54:25 -0800 (PST) > Message-ID: <3E5AA2A0.AFCF1217@sun.com> > Date: Mon, 24 Feb 2003 14:54:24 -0800 > From: Eric Armstrong > X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) > X-Accept-Language: en > MIME-Version: 1.0 > To: Alatalo Toni > References: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > cc: gzz-dev@mail.freesoftware.fsf.org > cc: me > Subject: [Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool > X-BeenThere: gzz-dev@nongnu.org > X-Mailman-Version: 2.1b5 > Precedence: list > List-Id: Gzz developers > List-Help: > List-Post: > List-Subscribe: , > > List-Archive: > List-Unsubscribe: , > > Sender: gzz-dev-bounces+marlene=xanadu.net@nongnu.org > Errors-To: gzz-dev-bounces+marlene=xanadu.net@nongnu.org > X-SMTPD: qpsmtpd/0.20-dev, http://develooper.com/code/qpsmtpd/ > > From owner-ba-ohs-talk@bootstrap.org Mon Mar 10 17:04:12 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 28C1356FF7; Mon, 10 Mar 2003 17:04:12 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp1.cp.tin.it (vsmtp1.tin.it [212.216.176.221]) by bi0.bootstrap.org (Postfix) with SMTP id 25E5F56FF5 for ; Mon, 10 Mar 2003 17:04:10 -0800 (PST) Received: from trotter (213.45.119.179) by smtp1.cp.tin.it (6.5.033) id 3E3AA8B600EC1021; Tue, 11 Mar 2003 02:24:53 +0100 From: "Danny Ayers" To: "Benja Fallenstein" , Cc: "GZZ developers" Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") Date: Tue, 11 Mar 2003 02:23:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3E6D2033.9090405@gmx.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > > A > > | > > |-x > > | > > B---A > > | > > y Ok, I'm convinced!!! I've also realized that I had something along these lines happening already. One of the views I've been working on is a tree (based on JTree's rendering), which when showing a graph soon gets into multiple occurences of each node. If A -> B and B -> A you'd probably have a loop in a graph view, but the tree goes A -> B -> A -> B ... I was rather surprised, but after playing around with it a bit, it does look like it should be useful. > I think you're talking about different things. Danny is talking about > users placing nodes explicitly on the screen, arranging them into > spatial structures (as in Ideagraph). Toni is talking about automatic > views as in Fenfire Loom (or Gzz/GZigZag), where the program > automatically arranges nodes on the screen to convey the underlying RDF > structure (or zzstructure). There is automatic layout in Ideagraph as well... (currently only embedded-spring on the graph view, though I played with a few other ideas in the prototype) > Indeed, in our Loom views, we regularly show the same node multiple > times: say that "noteA seeAlso noteB" and "noteB isReasonFor noteA" for > example; then, when we focus noteA, noteB is related to it in two ways, > and we show it twice because of that. (Sorry, I don't have a screenshot > program ready :-/ ) An interesting angle. I've been avoiding the issue of representing multiple arcs between nodes, mostly because it'll be hard to manage on screen. Showing nodes more than once would certainly make the layout easier, although I suppose care would have to be taken to make it clear that node A(1) is the same individual as node A(2). > After reflection, I do think that placing the same node at two different > locations can make sense, though. In Spatial Hypertext, the arrangement > of nodes is used to convey structure as we would on e.g. a conventional > blackboard or scratchpad etc. > > Let's say a user is making groups of people by placing person nodes > together in different locations of the screen (spatial canvas). What if > a person is in more than one group? Well yes, but you could use a Venn diagram style, or just have a separate canvas for each group... > (Maybe these kinds of spatial structuring isn't what you're after in > Ideagraph; but on the other hand, why allow the user to hand-structure > the arrangement of the graph if not to have them make use of that > spatial arrangement? In any case, it would be nice if the same > vocabulary could be used by other tools that let users arrange things > spatially...) Oh, I agree entirely, the spatial stuff definitely has a lot of potential. I'm quite looking forward to when I can move off the wiring side of Ideagraph and play around with layout (inc. grouping). Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Tue Mar 11 00:03:06 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 326505702D; Tue, 11 Mar 2003 00:03:05 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by bi0.bootstrap.org (Postfix) with SMTP id E220F56FF5 for ; Tue, 11 Mar 2003 00:03:03 -0800 (PST) Received: from dialup-64.154.70.183.dial1.sanantonio1.level3.net ([64.154.70.183] helo=ibmaa0051d) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18sf33-0004Sb-00; Tue, 11 Mar 2003 00:23:45 -0800 Message-ID: <001701c2e7a7$8d9c9880$b7469a40@ibmaa0051d> From: "Matthew A. Schneider" To: Cc: "Theodor Nelson" , References: <3E52C0EF.6AF618B9@sun.com> <20030311063434.GB1072@douge.blueoxen.net> Subject: [ba-ohs-talk] Purple numbered document authoring or How one can assemble quoted portions taken from different documents (Re: Starting Point for Collab Tool) Date: Tue, 11 Mar 2003 02:23:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Although not quite complete, I have a short description (with = screenshots :) of using PurpleSlurple to author "PSdocs" (i.e., = documents containing granular links to *external* source documents): = http://radio.weblogs.com/0105726/categories/purpleslurple/psDocumentCreat= ion.html PurpleSlurple addresses a number of issues (as I understand them) near = and dear to Ted Nelson: * Affords deep quotability (at the paragraph level currently but = *quotation in any part* coming soon!): = http://www.sasites.com/suse/apache/files/pstxt.php?theurl=3Dhttp://ted.hy= perland.com/quotableformat.txt#purp6 * Avoids embedded markup (in the sense that the source document need not = have any -- plain text works): = http://www.sasites.com/suse/apache/files/pstxt.php?theurl=3Dhttp://ted.hy= perland.com/buyin.txt#purp36 * One can assemble quoted portions taken from different documents (see = my PSdoc creation article): = http://www.sasites.com/suse/apache/files/pstxt.php?theurl=3Dhttp://ted.hy= perland.com/quotableformat.txt#purp18 While PurpleSlurple may be a "duct tape and baling wire solution"[1], = and one that may not be around forever, it *is* available today FOR = MILLIONS OF DOCUMENTS THAT DON'T HAVE PURPLE NUMBERS. PurpleSlurple affords me quite a lot of utility in my own work in the = fashion described. Some other ways to utilize PurpleSlurple * Drag and drop PSsnippets into your IM client * Drag and drop PSsnippets into your email client * Print out your documents with PSnumbers for easy reference and = discussion at meetings * Use PSnumbers to facilitate reading (and bookmarking) long online = articles or ebooks=20 * Use the granular links in Ideagraph, PurpleWiki and for all your = newsgroups postings * and many, many others Please indulge me, view my short overview of creating a PSdoc, and see = if you don't agree. Best regards, Matthew A. Schneider [1] This is my description. As an aerospace engineer from Tri-State U., = I can attest to the utility of duct tape and baling wire. From owner-ba-ohs-talk@bootstrap.org Tue Mar 11 00:10:51 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 7233857031; Tue, 11 Mar 2003 00:10:50 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from tols16.oulu.fi (tols16.oulu.fi [130.231.24.16]) by bi0.bootstrap.org (Postfix) with SMTP id 42ADB56FF5 for ; Tue, 11 Mar 2003 00:10:48 -0800 (PST) Received: from tols16.oulu.fi (localhost [127.0.0.1]) by tols16.oulu.fi (8.12.4/8.12.4) with ESMTP id h2B8Va2N029684; Tue, 11 Mar 2003 10:31:36 +0200 Received: from localhost (antont@localhost) by tols16.oulu.fi (8.12.4/8.12.4/Submit) with ESMTP id h2B8VaOg029681; Tue, 11 Mar 2003 10:31:36 +0200 Date: Tue, 11 Mar 2003 10:31:36 +0200 (EET) From: Alatalo Toni X-X-Sender: antont@tols16.oulu.fi To: ba-ohs-talk@bootstrap.org Cc: GZZ developers Subject: RE: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org On Tue, 11 Mar 2003, Danny Ayers wrote: (should we move to the new list btw? i mean the one Benja created, http://mail.nongnu.org/mailman/listinfo/fenfire-rdf-discuss . i'm there so omit ohs-talk and gzz-dev from replys at will)) > > > A > > > |-x > > > B-A > > > | > > > y > Ok, I'm convinced!!! wow -- that was yet a far from perfect example but glad to hear you are, thanks to Benja for clarifying the issue. one comment about visualization: > Showing nodes more than once would certainly make the layout easier, > although I suppose care would have to be taken to make it clear that node > A(1) is the same individual as node A(2). yes. this was discussed in the Fenfire context a few weeks ago, .. in a way it's a transclusion and we have seen visualisations of that, right? though it's not obvious what would be a clear notation in complex graphs etc. perhaps some lumineous beam would do :) and of course animation (interpolation) when the scene changes (due to either context (focus) or view change) (btw if someone knows of a decent cell divison algorithm i'd be interested, akin to the style of e.g. http://biog-101-104.bio.cornell.edu/BioG101_104/tutorials/cell_division/CDCK/cdck.html ) > Danny. ~Toni From owner-ba-ohs-talk@bootstrap.org Wed Mar 12 11:41:29 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id F32DC56FF7; Wed, 12 Mar 2003 11:41:28 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from smtp2.cp.tin.it (vsmtp2.tin.it [212.216.176.222]) by bi0.bootstrap.org (Postfix) with SMTP id 0C6DD56FF5 for ; Wed, 12 Mar 2003 11:41:26 -0800 (PST) Received: from trotter (212.171.206.104) by smtp2.cp.tin.it (6.5.033) id 3E660875002F694E for ba-ohs-talk@bootstrap.org; Wed, 12 Mar 2003 21:02:14 +0100 From: "Danny Ayers" To: Subject: RE: [ba-ohs-talk] :xu: Serious deep addressing (was Re: ![Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool Date: Wed, 12 Mar 2003 21:01:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org > Not just every paragraph, but every character, must be tracked. > When you're almost there, why stop? > > I would recommend another look at the tumbler mathematics by > Roger Gregory and Mark Miller, described in *Literary Machines* > (you can find an illegal copy on the Web someplace, scanned as > muiltipage fax=TIF=jfax). I've not yet located the scan, but there is a page about this here : http://udanax.com/green/febe/tumblers.html The W3C specs have gone down a similar path with XPath and XPointer as ways of addressing parts (down to individual characters) of an XML doc e.g. #xpointer(id('boy-blue')/horn[1])element(boy-blue/3) The biggest difference to my eyes would be that the W3C system is 'lumpy', particularly as the documents will be addressed through reference to a server - I don't think it is possible to do a 'smooth' relative reference from one arbitrary point in a doc on one server to another point on another. (I'm not entirely sure how you'd sequence the servers either - aardvark.au first?) I'm curious, has any work on this kind of system been done in the compression/crypto worlds? I'm sure this is ground well trodden, but if you had a doc starting with "abcdef..." then you can make words up as (start letter, number of letters) pairs. Cheers, Danny. From owner-ba-ohs-talk@bootstrap.org Wed Mar 12 12:13:26 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id B533056FF7; Wed, 12 Mar 2003 12:13:25 -0800 (PST) Delivered-To: ba-ohs-talk@bootstrap.org Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by bi0.bootstrap.org (Postfix) with SMTP id 87B5556FF5 for ; Wed, 12 Mar 2003 12:13:23 -0800 (PST) Received: (qmail 1045 invoked by uid 0); 12 Mar 2003 20:34:16 -0000 Received: from pD95889AA.dip.t-dialin.net (EHLO gmx.de) (217.88.137.170) by mail.gmx.net (mp001-rz3) with SMTP; 12 Mar 2003 21:34:16 +0100 Message-ID: <3E6F99BB.5030603@gmx.de> Date: Wed, 12 Mar 2003 21:34:03 +0100 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: ba-ohs-talk@bootstrap.org Cc: Marlene Mallicoat , Theodor Nelson , andrew , ed , steve , Alatalo Toni , gzz-dev@mail.freesoftware.fsf.org, roger@xanadu.com, jeremyalansmith@freeola.com, eisenman , frank fisher , kleban , mark miller Subject: Re: [ba-ohs-talk] :xu: Serious deep addressing (was Re: ![Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ba-ohs-talk@bootstrap.org Precedence: bulk Reply-To: ba-ohs-talk@bootstrap.org Hi Ted-- Theodor Nelson wrote: > I would recommend another look at the tumbler mathematics by > Roger Gregory and Mark Miller, described in *Literary Machines* > (you can find an illegal copy on the Web someplace, scanned as > muiltipage fax=TIF=jfax). I've downloaded a set of jfax files linked from your web page ages ago, including the INFUT book and the first few chapters of Literary Machines. The tumbler arithmetic comes in the later chapters which weren't online (where you linked to) at the time. We will be repackaging our own implementation of Xanalogical storage as an own project and download (language: Java) soon, by the way. (Currently works & has been used for 1 1/2 years on a single computer; P2P lookup coming, as always, Real Soon Now ;-) ) - Benja From mrscecimak@caramail.com Thu Mar 13 21:59:25 2003 Return-Path: Delivered-To: ba-ohs-talk-list@bi0.bootstrap.org Received: from mail1.caramail.com (mail1.caramail.com [213.193.13.92]) by bi0.bootstrap.org (Postfix) with SMTP id B771057005 for ; Thu, 13 Mar 2003 21:59:23 -0800 (PST) Received: from caramail.com (www2.caramail.com [213.193.13.12]) by mail1.caramail.com (Postfix) with SMTP id BBE67B41C; Fri, 14 Mar 2003 07:20:19 +0100 (MET) From: mrscecimak Mrs.Cecelia To: bernard.vatant@mondeca.com Message-ID: <1047622819016618@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [81.23.193.84] Mime-Version: 1.0 Subject: REQUEST FOR ASSISTANCE Date: Fri, 14 Mar 2003 07:20:19 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0166181047622819_ID" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0166181047622819_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: MRS CECILIA MARK AKU DEAR SIR, REQUEST FOR ASSISTANCE. I AM MRS CECILIA MARK AKU WIDOW OF LATE MARK ISHAYA AKU, MINISTER OF SPORTS AND YOUTH IN NIGERIA WHO DIED ON 4TH APIRL 2002 ON A PLANE CRASH. I HAVE BEEN INFORMED BY MY FAMILY ATTORNEY BARRISTER JUBRIL HASSAN THAT MY LATE HUSBAND DEPOSITED TWO TRUNK BOXES OF MONEY IN A SAFE KEEPING COMPANY AMOUNTING THIRTY-FIVE MILLION FIVE HUNDRED THOUSAND UNITED STATES DOLLARS US$35,500,000) IN HIS FAVOUR. THE ATTORNEY NOW ADVISE I TO SEEK IN CONFIDENCE A FOREIGN PARTNER WHO CAN STAND AND RETRIEVE THESE BOXES AND BE TRANSFERRED FOR DISBURSEMENT AS DIRECTED BY MY LATE HUSBAND IN HIS WILL. IT HAS BEEN RESOLVED THAT 20%(US$7,100,000) WILL BE YOUR SHARE FOR YOUR ASSISTANCE FOR THIS PURPOSE AND ANY OTHER ASSISTANCE YOU WILL GIVE IN THAT REGARD, 10 %( US$3,550,000) HAS BEEN SLATED FOR REIMBURSEMENT FOR ALL LOCAL AND INTERNATIONAL EXPENSES WHICH MAY BE INCURED IN THE TRANSFER PROCESS AND 5 %( US$1,775,000) HAS BEEN CONCEDED TO THE LOCAL BANK MANAGER THAT WILL BE ASSSISTING AND FACILITATING THE TRANSFER. FINALLY 65 %( US$23,075,000)WILL COME TO MYSELF AND CHILDREN AND A GOOD PART OF THIS SHALL BE DIRECTED TOWARDS EXECUTING HIS WILL WHICH IS TO BUY SHARES AND STOCKS IN FOREIGN COUNTRIES TO SECURE HIS CHILDRENS FUTURE. TO FACILITATE THE CONCLUSION OF THIS RANSACTION, IF ACCEPTED, DO SEND TO ME PROMPTLY BY E-MAIL. THE FOLLOWING: FAX AND TELEPHONE NUMBERS THROUGH WHICH YOU WILL BE CONTACTED PROMPTLY WHENEVER YOUR ATTENTION AND ASSISTANCE MAY BE REQUIRED, SO THAT MY ATTORNEY CAN REACH YOU. PLEASE NOTE THAT I HAVE BEEN ASSURED THAT THE TRANSACTION WILL BE CONDUCTED WITHIN TWO (2) WEEKS UPON MY RECEIVING OR HEARING FROM YOU THE ABOVE LISTED INFORMATION. I SHALL COMMENCE THE PROCESS OF RETRIEVING THE WILL IMMEDIATELY I HERE FROM YOU.MAY I AT THIS POINT EMPHASIZE THE HIGH LEVEL OF CONFIDENTIALITY WHICH THIS BUSINESS DEMANDS AND HOPE YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE WHICH I REPOSE IN YOU. HOWEVER, YOU MAY NEED TO GIVE ME SUFFICENT ASSURANCE THAT YOU WILL NOT SIT ON THIS FUND WHEN IT IS FINALLY REMITTED INTO YOUR ACCOUNT. PLEASE GIVE THIS MATTER A PROMPT AND QUICK REPLY. PLEASE YOU WILL NEED TO DISCUS WITH MY FAMILY ATTORNEY BARRISTER JUBRIL HASSAN TOWARDS THE EFFECTIVE COMPLETION OF THIS TRANSACTION.PLEASE YOU CAN CONTACT ME WITH THIS E-MAIL ADDRESS BEST WISHES. MRS CECILIA MARK AKU. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0166181047622819_ID--