From jonas@paranormal.se Sat, 10 Jun 2000 09:57:20 +0200 Date: Sat, 10 Jun 2000 09:57:20 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Test TEST -- / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Sat, 10 Jun 2000 09:58:31 +0200 Date: Sat, 10 Jun 2000 09:58:31 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Test Jonas Liljegren wrote: > > TEST > -- > / Jonas - http://paranormal.se/myself/index.html > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf -- / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Sat, 10 Jun 2000 09:59:01 +0200 Date: Sat, 10 Jun 2000 09:59:01 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Test Jonas Liljegren wrote: > > Jonas Liljegren wrote: > > > > TEST > > -- > > / Jonas - http://paranormal.se/myself/index.html > > > > _______________________________________________ > > RDF mailing list > > RDF@uxn.nu > > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf > > -- > / Jonas - http://paranormal.se/myself/index.html > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf -- / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Sat, 10 Jun 2000 11:11:07 +0200 Date: Sat, 10 Jun 2000 11:11:07 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] t3 t3 -- / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Tue, 20 Jun 2000 13:35:31 +0200 Date: Tue, 20 Jun 2000 13:35:31 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: graphical RDF tools] This is a multi-part message in MIME format. --------------8AE0D80E2775D9E229E41609 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- / Jonas - http://paranormal.se/myself/index.html --------------8AE0D80E2775D9E229E41609 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.o.se Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 134MFR-0000wC-00 for ; Tue, 20 Jun 2000 13:31:17 +0200 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12713; Tue, 20 Jun 2000 07:19:09 -0400 (EDT) Resent-Date: Tue, 20 Jun 2000 07:19:09 -0400 (EDT) Resent-Message-Id: <200006201119.HAA12713@www19.w3.org> Message-ID: <394F5322.A5BF2AF8@uni-essen.de> Date: Tue, 20 Jun 2000 13:18:58 +0200 From: Reinhold Klapsing X-Mailer: Mozilla 4.06 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: www-rdf-interest@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: graphical RDF tools Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1068 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 Hi Tom, Tom Van Eetvelde wrote: > > Hello RDF comunity, > > Does anyone know of a tool to draw directed labeled graphs and to store them as RDF? I think it > would be soemthing nice to have. That way, one can graphically produce RDF files! > > This concept is already available for programming languages (see Rational Rose), so why not for RDF? > > Regards, > > Tom. > GraMToR is a graphical editor for the interactive constructing of an RDF data model. The graphical representation can be serialized to XML-RDF syntax. Additionally the data model can be serialized in the triple notation. GraMToR is developed with the scripting language XOTcl [1] and the prototype environment Wafe [2] which includes support for several libraries like the widget set OSFMotif. GraMToR is available [3] under the GPL license. Documentation of the implemented class system (german language) and a short user guide (german language) is available. The GraMToR is a first prototype with which we gained experience in graphical processing of RDF data models. It is the outcome of the diploma thesis (german language) of Alexander Block which is also available [4]. Regards, Reinhold [1] http://www.xotcl.org [2] http://nestroy.wi-inf.uni-essen.de/wafe/ [3] http://nestroy.wi-inf.uni-essen.de/xwmf/ [4] http://nestroy.wi-inf.uni-essen.de/Lv/diplomarbeiten/da2-ablock.ps.gz --------------8AE0D80E2775D9E229E41609-- From jonas@paranormal.se Wed, 28 Jun 2000 22:28:49 +0200 Date: Wed, 28 Jun 2000 22:28:49 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] www-rdf-interest@w3.org from November 1999: sharing MIME types http://lists.w3.org/Archives/Public/www-rdf-interest/1999Nov/0013.html From jonas@paranormal.se Thu, 29 Jun 2000 22:18:44 +0200 Date: Thu, 29 Jun 2000 22:18:44 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: librdf - application framework for RDF pre-announcement] This is a multi-part message in MIME format. --------------A01371550C9EB484F5239BFA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Låter intressant. Open Directorys RDF kan vara av intresse. -- / Jonas - http://paranormal.se/myself/index.html --------------A01371550C9EB484F5239BFA Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.o.se Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 137fyZ-0001Pk-00 for ; Thu, 29 Jun 2000 17:11:35 +0200 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26286; Thu, 29 Jun 2000 10:54:09 -0400 (EDT) Resent-Date: Thu, 29 Jun 2000 10:54:09 -0400 (EDT) Resent-Message-Id: <200006291454.KAA26286@www19.w3.org> To: www-rdf-interest@w3.org X-URI: http://www.ilrt.bristol.ac.uk/people/cmdjb/ Date: Thu, 29 Jun 2000 15:54:00 +0100 Message-ID: <13926.962290440@jarjar.ilrt.bris.ac.uk> From: Dave Beckett Subject: librdf - application framework for RDF pre-announcement Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1102 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 RDFers, I have been lurking here for a while, but not posted before although tracking things that appear here in my RDF resource guide: http://www.ilrt.bristol.ac.uk/discovery/rdf/resources/ and the Open Directory RDF areas which I co-edit. Here's some hints on what's coming up. I've just moved jobs to ILRT at the University of Bristol and have now got the time to develop a sort-of application framework for RDF. I've started designing and coding in C(*) a pluggable architecture for manipulating RDF and experimenting with bits and pieces. [(*)if you are thinking, why C - it is because it might be more 'portable' and easier to plug into other languages, systems and applications. However, it's written in an OO style. Please take any comments to email.] The parts that I currently want to be pluggable include: * XML parsers - external via pipe/filter, expat, xerces-c?, ... * RDF parsers - external e.g. sirpac, libwww rdf, mozilla, ... * Storage models - in memory hashes, bdb/gdbm files, triples-in-SQL, ... * Query languages [as people propose and play with them] * (Utility classes for Hashes, Digests, WWW resolving) The architecture is tricky to write in text but I'll have a go. These are the concepts/classes: Node - a node/arc in an RDF graph Contains either a URI OR String + XML language Statement - or triple Contains a Node resource, Node property and Node object Model Contains: A bag/set of Statements OR a list of sub-Models A reference to a 'Storage' The list of sub models is there to allow layering Models for such things as adding transactions, filtering, ... (more thought needed) 'Storage' (name may change) Implements a Statement storage API and at least one Statement query API(s) 'RDF Parser' ('RDF DataSource'? 'RDF Reader'?) Asserts Statements to a given model OR uses a given XML Parser and model. 'XML Parser' Provides a standard XML API (DOM?, SAX?) 'RDF Syntax generator' ('RDF DataSink', 'RDF Consumer?) Emits formatted RDF in XML, other syntaxes, encodings - SOAP? Missing concepts/ stuff I know about but will do after V1.0: Namespaces - I've no support for these Unicode - I've assumed C char*=UTF-8 string [BAD] Typing and Classes - to support: RDF Schemas - need help here The current really imaginative name for this is 'librdf' and it is getting to the stage of nearly being useful. Implemented so far: Hash - GDBM, in memory Digest - MD5, SHA, RIPEMD160 Node Statement Model (just API) +lots of boring supporting stuff Once this reaches a slightly fuller level, I will release it and then actually use it myself for applications. License: The system will be a free software one, or open source if you prefer, and should be flexible. I've not yet decided what type, most likely Apache/BSD-ish. Release Date: Within two weeks Please feel free to comment, ask questions or even better, offer to help! Dave --------------A01371550C9EB484F5239BFA-- From jonas@paranormal.se Wed, 05 Jul 2000 20:25:53 +0200 Date: Wed, 05 Jul 2000 20:25:53 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: RDF tools: FramerD http://www.framerd.org/] This is a multi-part message in MIME format. --------------8E2C9FA5F50DD8F61B6D4020 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- / Jonas - http://paranormal.se/myself/index.html --------------8E2C9FA5F50DD8F61B6D4020 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.o.se Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 139tg1-0005gk-00 for ; Wed, 05 Jul 2000 20:13:37 +0200 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01134; Wed, 5 Jul 2000 13:54:54 -0400 (EDT) Resent-Date: Wed, 5 Jul 2000 13:54:54 -0400 (EDT) Resent-Message-Id: <200007051754.NAA01134@www19.w3.org> Date: Wed, 5 Jul 2000 13:54:48 -0400 (EDT) From: Dan Brickley To: www-rdf-interest@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RDF tools: FramerD http://www.framerd.org/ Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1108 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 Hi all, Latest find in my never-ending trawl for database/query tools that might be useful with RDF is something called 'FramerD'. I stumbled across this on the MIT site but it seems now to have an independent (and GPL licensed) existence. I've only skimmed the online docs but it looks promising, if complex. Note that there's an RPM bundle for Linux (http://www.framerd.org/docs/users-guide.html#installation) and the tarball installation also looks pretty straightforward. The online demos, include a datatbase called the 'BRICO Ontology' which combines WordNet, Roget's thesaurus and the public CYC upper ontology; some of you might find this of interest in addition to the database system itself. Could anyone be persuaded to take a look at this with RDF in mind and report back to www-rdf-interest? Blurb from homepage and why-use pages copied below... cheers, --danbri >From http://www.framerd.org/ What? Why? FramerD is a portable distributed object-oriented database designed to support the maintenance and sharing of knowledge bases. Unlike other object-oriented databases, FramerD is optimized for the sort of pointer-intensive data structures used by semantic networks, frame systems, and many intelligent agent applications. FramerD databases readily include millions of searchable frames and may be distributed over multiple networked machines. FramerD includes an extensive scripting language based on Scheme with special support for web-based interfaces. FramerD is designed for incremental and collaborative data and knowledge base development. One primary cause of brittleness, incompatability, and obsolesence in advanced applications is the premature codification of structures, protocols, and semantics. FramerD was designed to provide robust and efficient data management without extensive up-front specification of data and operations. Developed at MIT's Media Laboratory, FramerD has been used for four years in developing information access and machine understanding applications. FramerD is implemented in ANSI C and has been compiled for a wide range of platforms, including many varieties of Unix and WIn32. In addition, experimental Java and Lisp libraries exist for accessing FramerD databases and services. FramerD sources and platform releases are available free of charge under the GNU GPL. Inquiries about less restrictive commercial licenses should be directed to MIT's Technology Licensing Office. >From http://www.framerd.org/docs/why.html Why Should I Use FramerD? FramerD manages descriptions and systems of description FramerD allows the computer to create, access, and manipulate descriptions and systems of description. Most computer applications work by manipulating descriptions in some systematic way. A system of description is the set of conventions, expectations, and procedures used to manipulate descriptions in a particular application area. For example, in a scheduling application, the system of description might specify: classes of entities, like events, individuals, locations, resources, and times; relationships between these entities, like attendance at events or reservation of resources constraints and inferences about these relationships Descriptive systems can be programmed by people or generated by machines. In either event, when users or programs add new descriptions or extend existing systems, FramerD automatically generates consequences from the additions or extensions. FramerD is a database for intelligent systems FramerD was developed to support research in artificial intelligence (AI) involving the construction of artifacts which demonstrate something like human understanding and intelligence. For example, in our current research we use FramerD to encode a text database where relations and meanings are used in retrieval and matching. Each natural language phrase in the original text database is described by a different frame in FramerD; relations between these frames descibe both the structure of sentences (e.g. "Bush" is the subject of "flew") and possible meanings ("flew" might mean "drove the plane" or "rode in the plane"). Taking ideas from past work in artificial intelligence, FramerD is built to describe conceptual objects and their relationships to one another. Unlike this past work, however, FramerD is designed to scale to millions or tens of millions of objects. FramerD simplifies development and sharing FramerD was designed to simplify: incremental development of systems of description, sharing descriptions and systems of description, distributing data and computation over a network of clients and servers, access to descriptions and databases through World Wide Web If you need to describe complicated and interconnected structures and want to be able to store and share these structures, it's worthwhile looking at FramerD. In particular, if your work is currently (or constitutionally) in "development mode" and incremental changes to your database are common, FramerD may be what you are looking for. FramerD descriptions can be richly interconnected FramerD is optimized for descriptions consisting primarily of relations to other descriptions. Relations between descriptions can be either structural relations or semantic relations. Structural relations connect elements within a particular context, for example 'this lintel is above that support' or 'the name "Clinton" (in some context) is the subject of the verb "nominated" (in the same context)'. Semantic relations, on the other hand, connect a description to some "meaning" description elsewhere in the database, for example `the lintel is a vertical rectangular blob' or 'the verb "nominated" may denote a kind of selection'. Descriptions can also include simple attributes whose values are numbers or strings, but FramerD is optimized for the kinds of complicated relational structures common in artificial intelligence systems. In particular, FramerD has special operations for delayed loading and caching of objects which make it inexpensive to load objects which refer to other objects. [....snip] --------------8E2C9FA5F50DD8F61B6D4020-- From jonas@paranormal.se Thu, 06 Jul 2000 20:21:33 +0200 Date: Thu, 06 Jul 2000 20:21:33 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: librdf architecture] This is a multi-part message in MIME format. --------------1FF9359E2B7CAFDFA5FDB021 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- / Jonas - http://paranormal.se/myself/index.html --------------1FF9359E2B7CAFDFA5FDB021 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.o.se Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 13ADpQ-0002vf-00 for ; Thu, 06 Jul 2000 17:44:41 +0200 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09660; Thu, 6 Jul 2000 11:27:52 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 11:27:52 -0400 (EDT) Resent-Message-Id: <200007061527.LAA09660@www19.w3.org> To: www-rdf-interest@w3.org X-URI: http://www.ilrt.bristol.ac.uk/people/cmdjb/ Date: Thu, 06 Jul 2000 16:27:46 +0100 Message-ID: <32380.962897266@jarjar.ilrt.bris.ac.uk> From: Dave Beckett Subject: librdf architecture Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1111 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 I'm working out more of my librdf Application Framework design as previously mentioned: http://lists.w3.org/Archives/Public/www-rdf-interest/2000Jun/0082.html The current part of the architecture I'm working on is the model / storage / parsing / streaming part which goes something like this: (remember written in C with objects done by hand) Base Classes: class Statement - triples (resource, property, object) class Model - a set of Statements with a link to a Storage ... many methods, most passed on to Storage class Storage - knows how to store/retrieve Statements using identifiers lots of methods such as: method add_statement (in Statement, out identifier, ...) - returns a storage specific identifier (URI) that can be used to get the statement later method remove_statement (in identifier, ...) method get_statements (out stream of Statements) method find (in Node subject, in Node predicate, in Node object, out stream of Statements) method find (in Node subject, in Node predicate, in Node object, in/out Model) ... Then we add: class XML DOM Parser - builds an in-memory DOM representation constructor (...) method init(in XML content) method get_dom (out in-memory DOM representation) class XML SAX Parser - generates SAX-like events constructor (...) method init(in stream of XML content) method register_sax_event_1 (in function) ... method register_sax_event_ (in function) class RDF Parser constructor (...) method parse_xml_events(in/out model, in XML SAX Parser) method parse_xml_tree(in/out model, in XML DOM Parser) so you can do things like this: storage = new Storage (use Berkeley DB V2 please, ...) model = new Model (storage) rdf = new RDF Parser(...) www = new URI Resolver (XML content URI) if (using DOM model) { /* everything constructed in memory - better be small */ xml_dom = new XML DOM Parser(...) xml_dom->init(www->get_as_string) rdf->parse_xml_tree(model, xml_dom) delete xml_dom } else if (using SAX-like event model) { xml_sax = new XML SAX Parser(...) xml_sax->init(www->get_as_stream) rdf->parse_xml_events(model, xml_sax) delete xml_sax } else if (using standalone RDF parser) { ... more thought needed here ... rdf_stream = new Stream ("command for standalone parser to emit triples") rdfutil.add_statements_to_model_from_stream_of_triples(model, rdf_stream) } delete www ... do stuff with model ... Comments and questions are welcome. Here are some of the things I'm curious about. * Should the Storage method find always generate a new model or is returning a set of statements as a stream OK? Both seem useful to me. * Should the Storage method find allow the passing in of any model in which to store the matching statements or allocate a new one model which is appropriate for the Storage? (This might be a useful optimisation e.g. creating SQL views over SQL queries and returning a new model representing that view of the storage) * Are people really going to need both DOM and SAX XML interfaces? * Is there really just one RDF parser class or should the class for RDF parsers that read DOMs be separate from the one that handles SAX events? Dave --------------1FF9359E2B7CAFDFA5FDB021-- From jonas@paranormal.se Sun, 9 Jul 2000 19:29:44 +0200 (CEST) Date: Sun, 9 Jul 2000 19:29:44 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Changed URL (fwd) / Jonas - http://paranormal.se/myself/index.html ---------- Forwarded message ---------- Date: Sun, 9 Jul 2000 19:17:26 +0200 (CEST) From: Jonas Liljegren To: www-rdf-interest@w3.org Cc: Daniel.Brickley@bristol.ac.uk, wraf@uxn.nu Subject: Changed URL Hi. The address to the (old) perl "RDF Schema editor" has changed from http://paranormal.o.se/perl/proj/rdf/schema_editor/ to http://paranormal.se/perl/proj/rdf/schema_editor/ Could someone please change the link on http://www.w3.org/RDF/ ? A more recent version of the program (v0.17) and database has been published. A new perl RDF engine (the WRAF project) is under development. Nothing ready to be shown yet. But I could mention some design goals: * Work with many interfaces to several databases, online services, and other sources. * Generalize every API function and interface, so that the system is described in RDF itself. (You doesn't have to manualy download software updates anymore) * Optimized caching on many levels * Uses "models", namespaces, aboutEachPrefix, etc as the domain for queries. * A presentation schema will present the requested information, formatted depending on the context. * Implemented as a service deamon with a small cgi/mod_perl client. Any support from intrested perl programmers are welcomed. / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Mon, 10 Jul 2000 20:47:15 +0200 (CEST) Date: Mon, 10 Jul 2000 20:47:15 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: Perl RDF APIs (was Re: Changed URL) On Sun, 9 Jul 2000, Dan Brickley wrote: > I've updated our reference, though I would encourage you to try to > continue to service the original URL too if possible (see [1]) if this is > within your control, since others' bookmarks, hyperlinks etc will get > broken. Now I fell ashamed. :-I I have a new excuse... =2E.. We have very strict top domain rules in Sweden. Only one domain for each organization. The old name was based on patent office rules for company name protections. It saved me more than =A3 5000 to choose the old name. The rules changed recently. This made it possibly to change to the new name. If I remember correctly, the nyw name would only be accepted if the old was terminated. But maby I got that wrong. In any case. The rule about only one domain per comapny still holds. I feel strongly about permanent URIs. But I don't think that the time for that has come yet. We must first come to the stage in the evolution of the Internet, there we can forget all about URLs in the daily life. They will have to be encapsulated in a couple of layers of protocols... From jonas@paranormal.se Mon, 10 Jul 2000 22:10:59 +0200 (CEST) Date: Mon, 10 Jul 2000 22:10:59 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: Perl RDF APIs (was Re: Changed URL) On Sun, 9 Jul 2000, Dan Brickley wrote: > Anyhow, looks like your Perl stuff is coming along nicely. I'm wondering > how it might eventually plug together with some of the other Perl stuff > out there, especially opensource code like Eric P's RDF parser, storage, > query system [2]. The plan is to use an existing parser and serializer. But the main focus is on the DB interface. I will probably adapt Eric's parser as a plugin or just make a plugin wrapper for the parser. My idea is that the same could be done for LDAP, SQL and anyting else. The server is the mapper and dispatcher that binds the parts together. > Your API [3] looks pretty close to most other RDF > systems I've seen (Sergey's Java API, Mozilla, EricP's stuff, recent > discussions with Dave Beckett about librdf etc etc). That is intentional. The model was based on the first (RADIX) proposal. I have read and participated in the API discussion and looked at the Java API. But the WRAF api is diffrent in many ways. It's a almost complete bootstrap of the system. Every function and object is in itself a Resource. This simple fact results in a very strange "broken" OO. > Related topic: cross-language APIs. The Mozilla stuff for example can be > called from C++ or Javascript, since they've used XP-IDL to define the > API. I'm wondering how feasible it would be to make an IDL version of say > Sergey's proposed API and project that into Perl... Plausible? Perl is the glue language. :-) It's mostly easy to construct new interfaces. The things that differ is the intended usage. WRAF is developed for online usage with a changing database. Every session is in itself a resource, with all the atributes from the client. You work in RDF rather than import/export RDF. This is diffrent from programs there you get a data stream and are supposed to do something with the incomming data and produce a outging stream. ... Well. I should continue programming rather than writing about it. > [2] http://www.w3.org/1999/02/26-modules/ > [3] http://paranormal.se/perl/proj/rdf/schema_editor/demo/doc/api.html > On Sun, 9 Jul 2000, Jonas Liljegren wrote: > > > A new perl RDF engine (the WRAF project) is under development. Nothing > > ready to be shown yet. But I could mention some design goals: > > > > * Work with many interfaces to several databases, online services, and > > other sources. > > > > * Generalize every API function and interface, so that the system is > > described in RDF itself. (You doesn't have to manualy download software > > updates anymore) > > > > * Optimized caching on many levels > > > > * Uses "models", namespaces, aboutEachPrefix, etc as the domain for > > queries. > > > > * A presentation schema will present the requested information, formatted > > depending on the context. > > > > * Implemented as a service deamon with a small cgi/mod_perl client. > > > > > > > > Any support from intrested perl programmers are welcomed. From jonas@paranormal.se Sat, 15 Jul 2000 16:12:48 +0200 Date: Sat, 15 Jul 2000 16:12:48 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] FramerD http://www.framerd.org/ This is a multi-part message in MIME format. --------------86F86D873323EDB52ADAD292 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Kanske värt att använda istället för vanlig databas. Stefan: har du lust att titta på denna? Skrivet i Ansi C. Borde gå att skapa ett enkelt perl-API. (Finns verktyg för det.) -- / Jonas - http://paranormal.se/myself/index.html --------------86F86D873323EDB52ADAD292 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.se Received: from localhost ([127.0.0.1] helo=paranormal.se) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 139trw-0005hN-00; Wed, 05 Jul 2000 20:25:56 +0200 Received: from localhost ([127.0.0.1] helo=paranormal.se) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 139trt-0005hH-00 for ; Wed, 05 Jul 2000 20:25:53 +0200 Message-ID: <39637DB1.71A7F9A0@paranormal.se> Date: Wed, 05 Jul 2000 20:25:53 +0200 From: Jonas Liljegren X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: sv, en-US, en-GB, en, English MIME-Version: 1.0 To: WRAF Content-Type: multipart/mixed; boundary="------------8E2C9FA5F50DD8F61B6D4020" Subject: [RDF] [Fwd: RDF tools: FramerD http://www.framerd.org/] Sender: rdf-admin@uxn.nu Errors-To: rdf-admin@uxn.nu X-BeenThere: rdf@uxn.nu X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: WRAF working group X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------8E2C9FA5F50DD8F61B6D4020 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- / Jonas - http://paranormal.se/myself/index.html --------------8E2C9FA5F50DD8F61B6D4020 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.o.se Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 139tg1-0005gk-00 for ; Wed, 05 Jul 2000 20:13:37 +0200 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01134; Wed, 5 Jul 2000 13:54:54 -0400 (EDT) Resent-Date: Wed, 5 Jul 2000 13:54:54 -0400 (EDT) Resent-Message-Id: <200007051754.NAA01134@www19.w3.org> Date: Wed, 5 Jul 2000 13:54:48 -0400 (EDT) From: Dan Brickley To: www-rdf-interest@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RDF tools: FramerD http://www.framerd.org/ Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1108 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 Hi all, Latest find in my never-ending trawl for database/query tools that might be useful with RDF is something called 'FramerD'. I stumbled across this on the MIT site but it seems now to have an independent (and GPL licensed) existence. I've only skimmed the online docs but it looks promising, if complex. Note that there's an RPM bundle for Linux (http://www.framerd.org/docs/users-guide.html#installation) and the tarball installation also looks pretty straightforward. The online demos, include a datatbase called the 'BRICO Ontology' which combines WordNet, Roget's thesaurus and the public CYC upper ontology; some of you might find this of interest in addition to the database system itself. Could anyone be persuaded to take a look at this with RDF in mind and report back to www-rdf-interest? Blurb from homepage and why-use pages copied below... cheers, --danbri >From http://www.framerd.org/ What? Why? FramerD is a portable distributed object-oriented database designed to support the maintenance and sharing of knowledge bases. Unlike other object-oriented databases, FramerD is optimized for the sort of pointer-intensive data structures used by semantic networks, frame systems, and many intelligent agent applications. FramerD databases readily include millions of searchable frames and may be distributed over multiple networked machines. FramerD includes an extensive scripting language based on Scheme with special support for web-based interfaces. FramerD is designed for incremental and collaborative data and knowledge base development. One primary cause of brittleness, incompatability, and obsolesence in advanced applications is the premature codification of structures, protocols, and semantics. FramerD was designed to provide robust and efficient data management without extensive up-front specification of data and operations. Developed at MIT's Media Laboratory, FramerD has been used for four years in developing information access and machine understanding applications. FramerD is implemented in ANSI C and has been compiled for a wide range of platforms, including many varieties of Unix and WIn32. In addition, experimental Java and Lisp libraries exist for accessing FramerD databases and services. FramerD sources and platform releases are available free of charge under the GNU GPL. Inquiries about less restrictive commercial licenses should be directed to MIT's Technology Licensing Office. >From http://www.framerd.org/docs/why.html Why Should I Use FramerD? FramerD manages descriptions and systems of description FramerD allows the computer to create, access, and manipulate descriptions and systems of description. Most computer applications work by manipulating descriptions in some systematic way. A system of description is the set of conventions, expectations, and procedures used to manipulate descriptions in a particular application area. For example, in a scheduling application, the system of description might specify: classes of entities, like events, individuals, locations, resources, and times; relationships between these entities, like attendance at events or reservation of resources constraints and inferences about these relationships Descriptive systems can be programmed by people or generated by machines. In either event, when users or programs add new descriptions or extend existing systems, FramerD automatically generates consequences from the additions or extensions. FramerD is a database for intelligent systems FramerD was developed to support research in artificial intelligence (AI) involving the construction of artifacts which demonstrate something like human understanding and intelligence. For example, in our current research we use FramerD to encode a text database where relations and meanings are used in retrieval and matching. Each natural language phrase in the original text database is described by a different frame in FramerD; relations between these frames descibe both the structure of sentences (e.g. "Bush" is the subject of "flew") and possible meanings ("flew" might mean "drove the plane" or "rode in the plane"). Taking ideas from past work in artificial intelligence, FramerD is built to describe conceptual objects and their relationships to one another. Unlike this past work, however, FramerD is designed to scale to millions or tens of millions of objects. FramerD simplifies development and sharing FramerD was designed to simplify: incremental development of systems of description, sharing descriptions and systems of description, distributing data and computation over a network of clients and servers, access to descriptions and databases through World Wide Web If you need to describe complicated and interconnected structures and want to be able to store and share these structures, it's worthwhile looking at FramerD. In particular, if your work is currently (or constitutionally) in "development mode" and incremental changes to your database are common, FramerD may be what you are looking for. FramerD descriptions can be richly interconnected FramerD is optimized for descriptions consisting primarily of relations to other descriptions. Relations between descriptions can be either structural relations or semantic relations. Structural relations connect elements within a particular context, for example 'this lintel is above that support' or 'the name "Clinton" (in some context) is the subject of the verb "nominated" (in the same context)'. Semantic relations, on the other hand, connect a description to some "meaning" description elsewhere in the database, for example `the lintel is a vertical rectangular blob' or 'the verb "nominated" may denote a kind of selection'. Descriptions can also include simple attributes whose values are numbers or strings, but FramerD is optimized for the kinds of complicated relational structures common in artificial intelligence systems. In particular, FramerD has special operations for delayed loading and caching of objects which make it inexpensive to load objects which refer to other objects. [....snip] --------------8E2C9FA5F50DD8F61B6D4020-- _______________________________________________ RDF mailing list RDF@uxn.nu http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf --------------86F86D873323EDB52ADAD292-- From jonas@paranormal.se Sat, 15 Jul 2000 19:04:27 +0200 Date: Sat, 15 Jul 2000 19:04:27 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] New front page I have put in a new welcome page. Changed the language to english. Pushed the existing welcome page to the development area. -- / Jonas - http://paranormal.se/myself/index.html From jonas@paranormal.se Tue Aug 1 12:22:44 2000 Date: Tue, 01 Aug 2000 13:22:44 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: Warum WRAF] This is a multi-part message in MIME format. --------------B48B56D7D6BB8AF541EF3EB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- / Jonas - http://jonas.liljegren.org/myself/en/index.html --------------B48B56D7D6BB8AF541EF3EB9 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@paranormal.se Received: from d1o963.telia.com ([195.67.214.241] ident=root) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 13JYpn-0004oF-00 for ; Tue, 01 Aug 2000 11:59:39 +0200 Received: from c64.org (t3o963p74.telia.com [195.67.215.74]) by d1o963.telia.com (8.8.8/8.8.8) with ESMTP id LAA27629 for ; Tue, 1 Aug 2000 11:57:21 +0200 (CEST) Message-ID: <39869FB2.52757B45@c64.org> Date: Tue, 01 Aug 2000 12:00:18 +0200 From: Stefan Andersson X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Jonas Liljegren (E-mail)" Subject: Warum WRAF Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by d1o963.telia.com id LAA27629 X-Mozilla-Status2: 00000000 Hall=E5, snygging! Helt ur det bl=E5, t=E4nkte jag g=F6ra en seri=F6s anstr=E4ngning att f=F6= rklara vad 'WRAF' g=E5r ut p=E5, i termer av nytta. Care to comment? Problemet med att beskriva vad WRAF =E4r och varf=F6r det =E4r bra, grund= as i att WRAF har evolverat ur m=E5nga sinsemellan olika ambitioner. WRAF skal= l vara allt och inget. H=E4r =E4r en =F6versikt =F6ver n=E5gra av de saker = WRAF =E4r t=E4nkt att ber=F6ra och l=F6sa: Semantisk webb: Webben (Internetdistribuerade HTML-dokument) var ursprungligen t=E4nkt so= m en rymd d=E4r inte bara m=E4nniskor skulle kunna bearbeta information, ut= an d=E4r ocks=E5 maskiner (agenter) skulle kunna verka. Webben =E4r idag hel= t anpassad f=F6r m=E4nniska-m=E4nniska kommunikation. Detta d=E5 inneh=E5ll= et =E4r helt orienterat mot form och naturligt spr=E5k. Webben =E4r fattig p=E5 strukturerad metadata, d.v.s. data om hur inneh=E5llet skall tolkas. XML =E4r en reaktion p=E5 detta. XML inneb=E4r ett steg tillbaka mot ursprunget, SGML. 'Problemen' med XML =E4r dock flera: * Uppdelningen i DTD och XML g=F6r att det blir on=F6digt komplicerat att bygga schemamedvetna applikationer, d.v.s. applikationer som kan 'f=F6rst=E5' vad som =E4r vad i ett dokument. * DTD:er talar dessutom bara om vad som =E4r ett v=E4lformat dokument, de= n ger ingen ledtr=E5d om vad de olika f=E4lten =E4r f=F6r n=E5got eller hur= man skall hantera dem. * XML =E4r i sig inte en standard f=F6r hur data skall markeras upp. Det = var t=E4nkt att applikationsutvecklare skulle utveckla egna 'scheman' (DTD:er= ) och utv=E4xla dessa sinsemellan. Brokers, som t.ex. BizTalk och andra repositories var t=E4nkta att fungera som schema-resolvers. Detta verkar inte ha slagit igenom, och det finns nu en m=E4ngd propriet=E4ra, sins emellan inkomplatibla scheman och DTD:er. En del av problemet =E4r att XM= L och DTD inte har mekanismer f=F6r partiell substituering och =F6verlagrin= g - 'arv'. * XML klarar inte av att beskriva n=E4tverksstrukturer, utan =E4r i botte= n orienterad =E5t hierarkiska strukturer. Detta =E4r en allvarlig nackdel, = d=E5 de flesta objektkluster till sin natur =E4r n=E4tverk. L=F6sning: Tanken =E4r allts=E5 att maskiner skall kunna kommunicera med varandra oc= h n=E5 en l=F6sning p=E5 en given uppgift utan att m=E4nniskor skall beh=F6= va =F6vervaka processen. Man skall allts=E5 kunna fr=E5ga en generisk s=F6kmotor (inferensmaskin) = om den billigaste flygbiljetten mellan G=F6teborg och Tokyo tidigast datum x= , senast datum y, och den skall svara p=E5 ett f=F6r m=E4nniskor naturligt = s=E4tt. Likas=E5 att kunna se vad en viss f=F6rfattare har skrivit, och vad andra har kommenterat om det f=F6rfattaren har skrivit. Eller en lista =F6ver a= lla fakturor en viss kund har utest=E5ende, komplett med produktinformation tagen ifr=E5n leverant=F6rernas webbsajter. Eller sitta i Sverige och konfigurera en bil enligt vad som finns tillg=E4ngligt i Belgien, och f=E5 priserna i dollar. * RDF =E4r en =F6ppen standard f=F6r att beskriva distribuerade generella n=E4tverksorganiserade resurser, med en standardiserad XML-serialisering som universiellt utbytesprotokoll. Detta betyder inte att man m=E5ste satsa p=E5 RDF. En liknande anstr=E4ngning =E4r t.ex. XML-Schema. * RDF =E4r INTE ett s=E4tt att modellera eller g=F6ra inferensen. Detta m= =E5ste sk=F6tas av en applikation som f=F6rser Internet med 'intelligens'. Detta= =E4r en av komponenterna i WRAF. Ett fr=E5gespr=E5k (modellerat i RDF) och en inferensmaskin kapabel att s=F6ka svar p=E5 fr=E5gan, och om den misslyck= as, f=F6rklara varf=F6r och be m=E4nniskan om kompletterande information. Se http://www.w3.org/DesignIssues/Semantic Knowledge management/Content Management * Dynamisk, flexibel renderering (serialisering) av objekt givet kontext. Ur arbetet med Lotus Notes, Skolverket och andra CM-uppdrag, har jag dragit slutsatsen att man kan se p=E5 content ur tv=E5 synvinklar: 1. Som en avs=E4ndares presentation av ett objekt. 2. Som ett objekts presentation av sig sj=E4lv. Den f=F6rsta approachen symboliseras av den klassiska brochyren. Avs=E4ndaren best=E4mmer helt och h=E5llet formen, och n=E4r objektinform= ationen v=E4l konstruerats, finns det inte utrymme f=F6r att l=E4gga till eller d= ra ifr=E5n - push. D=E4remot har avs=E4ndaren full kontroll =F6ver form och budskap, och v=E4ljer helt information och kontext. Den andra approachen symboliseras av den klassiska databasen. H=E4r =E4r avs=E4ndaren ett relativt neutralt datalager, som f=F6rv=E4ntar sig en fr= =E5ga innan ett svar kan konstrueras - pull. F=F6rdelen =E4r flexibilitet f=F6r mottagaren, men i geng=E4ld en minskad kontroll hos avs=E4ndaren. M=F6jligheten att f=F6rpacka budskapet vad g=E4ller l=E4slighet och upplevelsem=E4ssigt och att styra kontexten =E4r begr=E4nsad. Vad man egentligen vill ha =E4r en tredje metafor som fungerar som en syntes av dessa tv=E5 - en metafor som l=E5ter avs=E4ndaren och mottagare= n konstruera upplevelsen tillsammans. Detta l=E5ter sig inte g=F6ras genom simpla variabler och boolska villkorliga hopp. Vad man beh=F6ver =E4r en standard f=F6r att modellera content och SERIALISERING (rendering) av content. Vad detta skulle ge, =E4r att alla tj=E4nster, inte bara de som implementerat support f=F6r det, kunde f=F6rse kunden med den information= en kunden vill ha, p=E5 det s=E4ttet kunden vill ha den. En syntes av avs=E4ndarens och mottagarens behov. Om detta gjordes i t.ex. RDF som =E4r en distribuerad l=F6sning, skulle m= an kunna t=E4nka sig att anv=E4ndaren skickar med en URL till sin definitionsfil. (Denna kan i sin tur best=E5 av en dynamisk servertj=E4ns= t, villig att lyssna p=E5 mottagaren - servertj=E4nsten kan vara en del av anv=E4ndarens browser...) I definitionsfilen definieras anv=E4ndarens preferenser, men inte bara i termer av variabler, utan i semantiskt rika termer, d=E4r termerna i sin tur kan definieras av en tredje part. Termerna KAN handla om preferenser, integritet och f=F6ruts=E4ttningar (bandbredd, sk=E4rmstorlek, et.c.) men ocks=E5 om vilken information som efterfr=E5gas, hur den skall prioriteras och presenteras. (Presentera alltid personer med fullst=E4ndigt namn och bild om det finns n=E5gon tillg=E4nglig. Placera alltid bilden till v=E4nster om fullst=E4ndigt nam= n.) D=E5 RDF underst=F6djer arv, skulle anv=E4ndare kunna =E4rva fr=E5n en gr= undprofil och f=F6r=E4ndra den efter hand. En tj=E4nst som 'metacrawler', t.ex. skulle helt enkelt bli obsolet, d=E4rf=F6r att alla s=F6kmaskiner skulle kunna s=F6ka i alla andra s=F6km= askiner och presentera resultatet p=E5 ett enhetligt, personifierat s=E4tt. De skulle ocks=E5 kunna vara relativt simpla. Allts=E5 skulle man kunna ha e= n lokal s=F6kmaskin - agent - i klienten. Eller p=E5 den n=E4rmsta servern = om vi pratar tunna klienter. En annan aspekt =E4r den rena administrationen av content. D=E4r finns mycket att g=F6ra. M=E5let =E4r ju att content skall vara lika enkelt att administrera som det =E4r att anv=E4nda en ordbehandlare. Detta kan realiseras antingen genom ett intelligent, klientbaserat, gr=E4nssnitt - en plugin till browsern - eller genom ett intelligent, serverbaserat gr=E4nssnitt. I vilket fall beh=F6vs strukturer f=F6r metadata och arv - = och ett beskrivningsspr=E5k. Detta f=F6r att p=E5 ett enhetligt s=E4tt kunna beskriva vilka operationer som =E4r till=E5tna var (p=E5 vilka objekt) - = och f=F6r vem. N=E4sta generations CM. N=E4r jag n=E4mner 'rekursion' sist i dokumentet, menar jag t.ex. att definitionen av formul=E4ren skall ske genom anv=E4ndande av formul=E4r. (som i sin tur definierats med formul=E4= r et.c.) Dynamisk och snabb applikationsbyggnad: Det finns ett antal irritationsmoment man r=E5kar ut f=F6r n=E4r man programmerar webbapplikationer: * Det =E4r ofta mycket struligt att l=E4gga till och ers=E4tta objekt und= er drift. Referenser blir ogiltliga och operativsystemet eller spr=E5kmotorn blir konfys. * Man implementerar samma funktionalitet g=E5ng p=E5 g=E5ng f=F6r olika komponenter. * Det blir allt mer uppenbart att den r=E5dande paradigmen med programmering f=F6re anv=E4ndande i allt snabbare takt blir obekv=E4m. Va= d man vill kunna g=F6ra =E4r att l=E5ta slutanv=E4ndare bygga ut systemet. =C4v= en med komponenter som ingen systemutvecklare ens tittat p=E5. Exempelvis vill man kunna l=E5ta ekonomiavdelningen l=E4gga till ett f=E4lt f=F6r 'andra mobiltelefon' ist=E4llet f=F6r att beh=F6va skriva det i ett '=F6vrigt'-f= =E4lt. Det skall ocks=E5 kunna ske utan att beh=F6va v=E4nta p=E5 en systemutvec= klare. Det skall kunna ske genom att =E4rva fr=E5n redan etablerade applikatione= r. Se Lotus Notes, men t=E4nk l=E4ngre, mer extremt. * N=E4r Operativsystem, plattform, applikation och data alla har olika API, r=E5kar man dels ut f=F6r att det man vill g=F6ra ibland inte g=E5r = eller =E5tminstone =E4r l=F6jligt komplicerat - detta f=F6r att utvecklarna av komponenterna valt att exponera olika funktionaliteter i olika niv=E5er och med olika filosofier. * Inom ASP och elektronisk distribution av applikationer, finns en hel m=E4ngd problem vad g=E4ller licensiering. Om man s=E5g objektrymden som best=E5ende av URI:er och cachade kopior av dessa URI:er, f=E5r man en struktur som l=E4mpar sig mycket v=E4l f=F6r administration av denna type= n av distribuerade tj=E4nster. Ambitionen =E4r att WRAF skall ha ett mycket moget cache-system d=E4r cac= he =E4r del av definitionen, inte bara f=F6r uppsnabbning, utan ocks=E5 just= f=F6r att sp=E5ra utnyttjande, f=F6r=E4ndringar och uppdateringar. * Inom e-business har begreppet 'Trust' kommit att spela en nyckelroll. Inte bara 'trust' mellan m=E4nniskor och tj=E4nster, utan mellan tj=E4nst= er. F=F6r att kunna g=F6ra det beh=F6vs ocks=E5 ett s=E4tt att kunna modeller= a 'trust' - vem som litar p=E5 vad i vilka avseenden och varf=F6r. Alla dessa sv=E5righeter ser jag hur man skulle kunna l=F6sa smidigt geno= m en distribuerad applikationsarkitektur d=E4r objekten definieras i RDF oc= h accessas genom HTTP och serialiserad RDF. Det finns visserligen t.ex. SOAP, men SOAP =E4r _en_ XML-baserad implementation, som man m=E5ste g=F6= ra en implementation f=F6r. SOAPs data och metadata =E4r inte utbyggbar, vilket= =E4r hela po=E4ngen med RDF. MS sitter p=E5 SOAP och dikterar riktningen. Med = RDF =E4r alla fria att expandera. I viss m=E5n p=E5 bekostnad av interoperabilitet. Men genom RDF har man =E5tminstone M=D6JLIGHETEN att avvika, och det =E4r relativt enkelt att bygga bryggor, om b=E5da partern= a pratar RDF. Speciellt d=E5 RDF som sagt =E4r rikt p=E5 metadata, och bygg= t f=F6r inferens... Distribuerade objektanrop: Visionen =E4r att en given webbapplikation skall kunna utnyttja hundratal= s andra webbapplikationer p=E5 olika servrar runt om i v=E4rlden f=F6r att = g=F6ra det den =E4r satt att g=F6ra. H=E4mta data s=E5v=E4l som utf=F6ra uppgift= er. T=E4nk t.ex. om en s=F6ktj=E4nst kunde sl=E5 i yahoo och dmoz f=F6r att f=E5 fra= m andra m=E4nniskors ranking och kombinera den med en maskinell ranking... Det finns COM+, SOAP, CORBA och HTTP som protokoll, men inga av dessa protokoll =E4r t=E4nkta att kunna g=F6ra n=E5got annat =E4n att vara bryg= gor, och =E4r d=E4rf=F6r slutna. COM/Corba =E4r ocks=E5 sv=E5ra att skriva f=F6r u= tan kostsamma utvecklingsmilj=F6er och utbildning. De har ocks=E5 begr=E4nsade m=F6jlig= heter till metadata, d=E4rf=F6r =E4r det sv=E5rt att g=F6ra l=F6sningar av type= n 'leta upp ett objekt som vet n=E5got om hundar och be den tala om allt om golden retrievers'. Att kunna beskriva hundar och vad hundar inbegriper =E4r int= e en del av Corba, och kommer aldrig att vara det. Det finns ocks=E5 en m=E4ngd katalogtj=E4nster med uppslagsspr=E5k, men de =E4r f=F6r inflexib= la, f=F6r dom=E4ncentrerade. En annan aspekt av distribuerade objektanrop =E4r att man vill kunna antingen skicka objektets svar (serversidefunktionalitet) eller sj=E4lva objektet (klientsidefunktionalitet) beroende p=E5 uppgiftens resurstyngd, resultatets storlek och tillg=E4nglig bandbredd. H=E4r kommer det jag skr= ev om ASP in... en ordbehandlare kan skickas objekt f=F6r objekt, anrop f=F6= r anrop, beroende p=E5 om servern eller klienten utf=F6r det snabbast givet n=E4tets kapacitet. Och samtidigt kan licensieringen f=F6lja anv=E4ndning= en... Uniformitet + Rekursion =3D Exponentiell synergi Och s=E5 slutkl=E4mmen d=E5. Det mesta som st=E5r d=E4r ovanf=F6r l=E5ter= sig g=F6ras med dagens plattformar och lite jobb. En del har gjorts m=E5nga g=E5nger,= en del finns inbyggt, andra saker finns inte =E4n. Oavsett vilket, s=E5 upps= t=E5r n=E5got spektakul=E4rt n=E4r alla dessa saker samlas under ett paraply. O= m detta paraplyet dessutom =E4r rekursivt, d.v.s. kan beskrivas genom sig sj=E4lv, h=E4nder ytterligare n=E5got extraordin=E4rt. D=E5 kan man anv=E4= nda systemet f=F6r att manipulera systemet. RDF =E4r definierat i RDF. WRAF =E4= r skrivet i WRAF. Lite samma som om man skulle ha en C++ - kompilator kapabel att skriva om sig sj=E4lv n=E4r ny funktionalitet beh=F6vs l=E4gg= as till spr=E5ket C++. I realtid. L=E5ng rambling. Kan du hj=E4lpa mig extrahera huvudpunkterna, s=E5 jag k= an f=F6rklara detta p=E5 ett kortare s=E4tt n=E4sta g=E5ng? ;-D /Stefan --------------B48B56D7D6BB8AF541EF3EB9-- From jonas@paranormal.se Tue Aug 1 12:24:37 2000 Date: Tue, 01 Aug 2000 13:24:37 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: Warum WRAF] Stefan Andersson wrote: > > Problemet med att beskriva vad WRAF är och varför det är bra, grundas i > att WRAF har evolverat ur många sinsemellan olika ambitioner. WRAF skall > vara allt och inget. Här är en översikt över några av de saker WRAF är > tänkt att beröra och lösa: > > Semantisk webb: > Webben (Internetdistribuerade HTML-dokument) var ursprungligen tänkt som > en rymd där inte bara människor skulle kunna bearbeta information, utan > där också maskiner (agenter) skulle kunna verka. Webben är idag helt > anpassad för människa-människa kommunikation. Detta då innehållet är > helt orienterat mot form och naturligt språk. Webben är fattig på > strukturerad metadata, d.v.s. data om hur innehållet skall tolkas. > XML är en reaktion på detta. XML innebär ett steg tillbaka mot > ursprunget, SGML. > 'Problemen' med XML är dock flera: > * Uppdelningen i DTD och XML gör att det blir onödigt komplicerat att > bygga schemamedvetna applikationer, d.v.s. applikationer som kan > 'förstå' vad som är vad i ett dokument. > * DTD:er talar dessutom bara om vad som är ett välformat dokument, den > ger ingen ledtråd om vad de olika fälten är för något eller hur man > skall hantera dem. > * XML är i sig inte en standard för hur data skall markeras upp. Det var > tänkt att applikationsutvecklare skulle utveckla egna 'scheman' (DTD:er) > och utväxla dessa sinsemellan. Brokers, som t.ex. BizTalk och andra > repositories var tänkta att fungera som schema-resolvers. Detta verkar > inte ha slagit igenom, och det finns nu en mängd proprietära, sins > emellan inkomplatibla scheman och DTD:er. En del av problemet är att XML > och DTD inte har mekanismer för partiell substituering och överlagring - > 'arv'. > * XML klarar inte av att beskriva nätverksstrukturer, utan är i botten > orienterad åt hierarkiska strukturer. Detta är en allvarlig nackdel, då > de flesta objektkluster till sin natur är nätverk. Hittills låter det som XML eller RDF. Många på RDF-listan (speciellt i början) uttalade sådana tankar, som att XML räcker. Men det är två olika saker. XML är ett sätt att lagra data. RDF beskriver kopplingen mellan data. RDF kan använda XML för själva datalagringen. RDF är så snarare en påbyggnad på RDF. Ytterligare ett lager för att standardisera tolkningen och möjliggöra kommunikation mellan data skapade för olika områden. RDF har utformats för att lösa en rad problem: 1. Utvecklingsbarhet: Scheman kan utökas på ett sätt att tidigare applikationer fortfarande kan använda dem. 2. Återanvändning: Nya Scheman kan bygga på flera gamla. Generella applikationer kan hantera och förstå det som är gemensamt även om de inte anpassats speciellt för det nya schemat. 3. Sammankoppling: Det finns ingen heiarki som avgöra vem som får säga vad. Alla kan utfärda metadata om en viss resurs. Inte bara resursens ägare. > Lösning: > Tanken är alltså att maskiner skall kunna kommunicera med varandra och > nå en lösning på en given uppgift utan att människor skall behöva > övervaka processen. > Man skall alltså kunna fråga en generisk sökmotor (inferensmaskin) om > den billigaste flygbiljetten mellan Göteborg och Tokyo tidigast datum x, > senast datum y, och den skall svara på ett för människor naturligt sätt. > Likaså att kunna se vad en viss författare har skrivit, och vad andra > har kommenterat om det författaren har skrivit. Eller en lista över alla > fakturor en viss kund har utestående, komplett med produktinformation > tagen ifrån leverantörernas webbsajter. Eller sitta i Sverige och > konfigurera en bil enligt vad som finns tillgängligt i Belgien, och få > priserna i dollar. > > * RDF är en öppen standard för att beskriva distribuerade generella > nätverksorganiserade resurser, med en standardiserad XML-serialisering > som universiellt utbytesprotokoll. Detta betyder inte att man måste > satsa på RDF. En liknande ansträngning är t.ex. XML-Schema. > * RDF är INTE ett sätt att modellera eller göra inferensen. Detta måste > skötas av en applikation som förser Internet med 'intelligens'. Detta är > en av komponenterna i WRAF. Ett frågespråk (modellerat i RDF) och en > inferensmaskin kapabel att söka svar på frågan, och om den misslyckas, > förklara varför och be människan om kompletterande information. > > Se > http://www.w3.org/DesignIssues/Semantic > > Knowledge management/Content Management > * Dynamisk, flexibel renderering (serialisering) av objekt givet > kontext. > Ur arbetet med Lotus Notes, Skolverket och andra CM-uppdrag, har jag > dragit slutsatsen att man kan se på content ur två synvinklar: > > 1. Som en avsändares presentation av ett objekt. > 2. Som ett objekts presentation av sig själv. > > Den första approachen symboliseras av den klassiska brochyren. > Avsändaren bestämmer helt och hållet formen, och när objektinformationen > väl konstruerats, finns det inte utrymme för att lägga till eller dra > ifrån - push. Däremot har avsändaren full kontroll över form och > budskap, och väljer helt information och kontext. > > Den andra approachen symboliseras av den klassiska databasen. Här är > avsändaren ett relativt neutralt datalager, som förväntar sig en fråga > innan ett svar kan konstrueras - pull. Fördelen är flexibilitet för > mottagaren, men i gengäld en minskad kontroll hos avsändaren. > Möjligheten att förpacka budskapet vad gäller läslighet och > upplevelsemässigt och att styra kontexten är begränsad. > > Vad man egentligen vill ha är en tredje metafor som fungerar som en > syntes av dessa två - en metafor som låter avsändaren och mottagaren > konstruera upplevelsen tillsammans. Detta låter sig inte göras genom > simpla variabler och boolska villkorliga hopp. Vad man behöver är en > standard för att modellera content och SERIALISERING (rendering) av > content. > > Vad detta skulle ge, är att alla tjänster, inte bara de som > implementerat support för det, kunde förse kunden med den informationen > kunden vill ha, på det sättet kunden vill ha den. En syntes av > avsändarens och mottagarens behov. > > Om detta gjordes i t.ex. RDF som är en distribuerad lösning, skulle man > kunna tänka sig att användaren skickar med en URL till sin > definitionsfil. (Denna kan i sin tur bestå av en dynamisk servertjänst, > villig att lyssna på mottagaren - servertjänsten kan vara en del av > användarens browser...) I definitionsfilen definieras användarens > preferenser, men inte bara i termer av variabler, utan i semantiskt rika > termer, där termerna i sin tur kan definieras av en tredje part. > Termerna KAN handla om preferenser, integritet och förutsättningar > (bandbredd, skärmstorlek, et.c.) men också om vilken information som > efterfrågas, hur den skall prioriteras och presenteras. (Presentera > alltid personer med fullständigt namn och bild om det finns någon > tillgänglig. Placera alltid bilden till vänster om fullständigt namn.) > Då RDF understödjer arv, skulle användare kunna ärva från en grundprofil > och förändra den efter hand. > > En tjänst som 'metacrawler', t.ex. skulle helt enkelt bli obsolet, > därför att alla sökmaskiner skulle kunna söka i alla andra sökmaskiner > och presentera resultatet på ett enhetligt, personifierat sätt. De > skulle också kunna vara relativt simpla. Alltså skulle man kunna ha en > lokal sökmaskin - agent - i klienten. Eller på den närmsta servern om vi > pratar tunna klienter. > > En annan aspekt är den rena administrationen av content. Där finns > mycket att göra. Målet är ju att content skall vara lika enkelt att > administrera som det är att använda en ordbehandlare. Detta kan > realiseras antingen genom ett intelligent, klientbaserat, gränssnitt - > en plugin till browsern - eller genom ett intelligent, serverbaserat > gränssnitt. I vilket fall behövs strukturer för metadata och arv - och > ett beskrivningsspråk. Detta för att på ett enhetligt sätt kunna > beskriva vilka operationer som är tillåtna var (på vilka objekt) - och > för vem. Nästa generations CM. När jag nämner 'rekursion' sist i > dokumentet, menar jag t.ex. att definitionen av formulären skall ske > genom användande av formulär. (som i sin tur definierats med formulär > et.c.) > > Dynamisk och snabb applikationsbyggnad: > Det finns ett antal irritationsmoment man råkar ut för när man > programmerar webbapplikationer: > * Det är ofta mycket struligt att lägga till och ersätta objekt under > drift. Referenser blir ogiltliga och operativsystemet eller språkmotorn > blir konfys. > * Man implementerar samma funktionalitet gång på gång för olika > komponenter. > * Det blir allt mer uppenbart att den rådande paradigmen med > programmering före användande i allt snabbare takt blir obekväm. Vad man > vill kunna göra är att låta slutanvändare bygga ut systemet. Även med > komponenter som ingen systemutvecklare ens tittat på. Exempelvis vill > man kunna låta ekonomiavdelningen lägga till ett fält för 'andra > mobiltelefon' istället för att behöva skriva det i ett 'övrigt'-fält. > Det skall också kunna ske utan att behöva vänta på en systemutvecklare. > Det skall kunna ske genom att ärva från redan etablerade applikationer. > Se Lotus Notes, men tänk längre, mer extremt. > * När Operativsystem, plattform, applikation och data alla har olika > API, råkar man dels ut för att det man vill göra ibland inte går eller > åtminstone är löjligt komplicerat - detta för att utvecklarna av > komponenterna valt att exponera olika funktionaliteter i olika nivåer > och med olika filosofier. > * Inom ASP och elektronisk distribution av applikationer, finns en hel Active Server Pages eller Application Service Providers? > mängd problem vad gäller licensiering. Om man såg objektrymden som > bestående av URI:er och cachade kopior av dessa URI:er, får man en > struktur som lämpar sig mycket väl för administration av denna typen av > distribuerade tjänster. > Ambitionen är att WRAF skall ha ett mycket moget cache-system där cache > är del av definitionen, inte bara för uppsnabbning, utan också just för > att spåra utnyttjande, förändringar och uppdateringar. Skulle du kunna utveckla det här? > * Inom e-business har begreppet 'Trust' kommit att spela en nyckelroll. > Inte bara 'trust' mellan människor och tjänster, utan mellan tjänster. > För att kunna göra det behövs också ett sätt att kunna modellera 'trust' > - vem som litar på vad i vilka avseenden och varför. > > Alla dessa svårigheter ser jag hur man skulle kunna lösa smidigt genom > en distribuerad applikationsarkitektur där objekten definieras i RDF och > accessas genom HTTP och serialiserad RDF. Det finns visserligen t.ex. > SOAP, men SOAP är _en_ XML-baserad implementation, som man måste göra en > implementation för. SOAPs data och metadata är inte utbyggbar, vilket är > hela poängen med RDF. MS sitter på SOAP och dikterar riktningen. Med RDF > är alla fria att expandera. I viss mån på bekostnad av > interoperabilitet. Men genom RDF har man åtminstone MÖJLIGHETEN att > avvika, och det är relativt enkelt att bygga bryggor, om båda parterna > pratar RDF. Speciellt då RDF som sagt är rikt på metadata, och byggt för > inferens... > > Distribuerade objektanrop: > Visionen är att en given webbapplikation skall kunna utnyttja hundratals > andra webbapplikationer på olika servrar runt om i världen för att göra > det den är satt att göra. Hämta data såväl som utföra uppgifter. Tänk > t.ex. om en söktjänst kunde slå i yahoo och dmoz för att få fram andra > människors ranking och kombinera den med en maskinell ranking... Det > finns COM+, SOAP, CORBA och HTTP som protokoll, men inga av dessa > protokoll är tänkta att kunna göra något annat än att vara bryggor, och > är därför slutna. COM/Corba är också svåra att skriva för utan kostsamma > utvecklingsmiljöer och utbildning. De har också begränsade möjligheter > till metadata, därför är det svårt att göra lösningar av typen 'leta upp > ett objekt som vet något om hundar och be den tala om allt om golden > retrievers'. Att kunna beskriva hundar och vad hundar inbegriper är inte > en del av Corba, och kommer aldrig att vara det. Det finns också en > mängd katalogtjänster med uppslagsspråk, men de är för inflexibla, för > domäncentrerade. > En annan aspekt av distribuerade objektanrop är att man vill kunna > antingen skicka objektets svar (serversidefunktionalitet) eller själva > objektet (klientsidefunktionalitet) beroende på uppgiftens resurstyngd, > resultatets storlek och tillgänglig bandbredd. Här kommer det jag skrev > om ASP in... en ordbehandlare kan skickas objekt för objekt, anrop för > anrop, beroende på om servern eller klienten utför det snabbast givet > nätets kapacitet. Och samtidigt kan licensieringen följa användningen... > > Uniformitet + Rekursion = Exponentiell synergi > Och så slutklämmen då. Det mesta som står där ovanför låter sig göras > med dagens plattformar och lite jobb. En del har gjorts många gånger, en > del finns inbyggt, andra saker finns inte än. Oavsett vilket, så uppstår > något spektakulärt när alla dessa saker samlas under ett paraply. Om > detta paraplyet dessutom är rekursivt, d.v.s. kan beskrivas genom sig > själv, händer ytterligare något extraordinärt. Då kan man använda > systemet för att manipulera systemet. RDF är definierat i RDF. WRAF är > skrivet i WRAF. Lite samma som om man skulle ha en C++ - kompilator > kapabel att skriva om sig själv när ny funktionalitet behövs läggas till > språket C++. I realtid. > > Lång rambling. Kan du hjälpa mig extrahera huvudpunkterna, så jag kan > förklara detta på ett kortare sätt nästa gång? ;-D :-) Vem är publiken? Ta det på engelska? Har du jämfört med hur jag presenterat mitt projekt? http://jonas.liljegren.org/myself/cv/paranormal_future.html Jag brukar jämföra med dagens sökmotorer: När du söker efter information får du en stor samling dokument som svar. Med RDF sammaställs det väsentliga från alla dessa källor och ger dig ETT dokument som svar. Speciellt utformat efter din fråga, omständigheterna, dina preferenser, osv. Huvudpunkter? * Maskinförståbar information * Kommunikation mellan services (distribuerad arkitektur) * RDF Standard * Anpassad presentation, baserad på betrodd data * Data, funktion och presentation i samma system * Systemet beskrivet i sig självt * Allt i systemet uppdateringsbart -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 2 16:30:59 2000 Date: Wed, 02 Aug 2000 17:30:59 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: Warum WRAF] Jag skickade din preliminära text till en person, i brit på annat. :-/ Det är hemskt mycket att försöka sammanställa. Fick en del gjort i måndags och tisdags. Framsteg. Nu har jag bokat biljett för 2,5 veckor i norge. Även om jag skulle vilja är jag nog itne klar då. Men jag kommer ta en vecka ledigt då. Har märkt att när jag vill fortsätta på WRAF tar det ungefär en dag för att rensa skrivbordet, ytterligare en dag för att komma i stämning och sedan 1-2 timmar för att hitta var jag slutade sist och hur det nu var allt hängde samman. Därför har det inte fungerat med att arbeta på helger. :-( Det finns inget att köra men programmet ser ungefär ut såhär nu: RDF-objekter i sig är en resource. Fleraagents (users) kan ha kopplat sig till olika interface. Exempelvis olika RDFS-scheman eller olika databaser genom samma DBI-interface. Jumptable baseras på agent-signaturen, för att bestämma vad som händer för olika sorters annrop. För att optimera DB har alla olika sorts resurser slagits samman i en enda stor tabell. Det blir en del bytes extra per post, men sparar en del uppslagningar. Har lagt pussel med hur de olika modulerna anropar varandra. Så just nu används 3 generationer av APIs om vart annat, vilket gör att inget fungerar ännu. Har försökt undvika dependency loops och hålla reda på rätt context samtidigt som jag vill kunna cacha objekt och gärna slippa skicka med context-objekt överallt. Och givetvis så att man ska kunna plugga in fler eller nya versioner av interface, scheman, funktioner, osv. Programkoden har långa kommentarer i sig lite här och var. API-skissen är inte uppdaterad, men okej. En del anteckningar finns också i wraf2. SQL-filen är iaf aktuell. Dvs dokument: http://www.uxn.nu/wraf/devel/latest/doc/ Testprogram: http://www.uxn.nu/wraf/devel/latest/bin/w22a.pl Huvudmodulen: http://www.uxn.nu/wraf/devel/latest/lib/RDF_022.pm Resten av modulerna: http://www.uxn.nu/wraf/devel/latest/lib/RDF_022/ En nyckeldel är interfacens registrering av de metoder de erbjuder, baserat på URI-prefix och type. Denna Register-funktion säger att den erbjuder metoden create_model() till alla resurser av typen 'model', oavsett vad de har för URI. Dispatchern tar alla registers från olika interface och skapar dedikerade jumptables för olika sorters resurser. return { '' => { NS_L.'model' => { 'create_model' => [\&create_model], }, } }; -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Thu Aug 3 10:40:32 2000 Date: Thu, 3 Aug 2000 11:40:32 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: Warum WRAF] On Thu, 3 Aug 2000, Stefan Andersson wrote: > > Jag skickade din prelimin=E4ra text till en person, i brit p=E5 annat. >=20 > Vem? stiftelsen.arcia@telia.com Dvs N=E6tverket f=F8r Gr=E6ns=F8verskridande Vetenskap. De har sedan l=E6ng= e haft planer p=E5 ett liknande system. F=F8r sis=E5d=E6r 10 =E5r sedan... :) > > :-/ Det =E4r hemskt mycket att f=F6rs=F6ka sammanst=E4lla. >=20 > Eh, ja. Jag f=F6rs=F6ker egentligen bara g=F6ra en grov f=F6rklarande tex= t, s=E5 > man kan f=E5 folk att fatta =F6ver huvud taget... "N=E6r allt detta kommer tillsammans h=E6nder n=E5got fantastiskt!" :-) = =C6r det tro, hopp eller hype? F=F8r mig =E6r det alla tre. :-) > > Har m=E4rkt att n=E4r jag vill forts=E4tta p=E5 WRAF tar det ungef=E4r = en dag f=F6r > > att rensa skrivbordet, ytterligare en dag f=F6r att komma i st=E4mning = och > > sedan 1-2 timmar f=F6r att hitta var jag slutade sist och hur det nu va= r > > allt h=E4ngde samman. > >=20 > > D=E4rf=F6r har det inte fungerat med att arbeta p=E5 helger. :-( >=20 > S=E5 =E4r det. Hade =F8nskat att det inte vore s=E5. V=E5ndan att dyka ned i koden igen. K=E6nslan av att man =E6nd=E5 inte kommer hinna n=E5got om man ska j= obba med annat n=E6sta dag. > > Det finns inget att k=F6ra men programmet ser ungef=E4r ut s=E5h=E4r nu= : > >=20 > > RDF-objekter i sig =E4r en resource. Fleraagents (users) kan ha kopplat > > sig till olika interface. Exempelvis olika RDFS-scheman eller olika > > databaser genom samma DBI-interface. Jumptable baseras p=E5 Resource Description Framework Schemas scheman och Database Interface interface? Hur skriver jag egentligen? :) > > agent-signaturen, f=F6r att best=E4mma vad som h=E4nder f=F6r olika sor= ters > > annrop. F=F6r att optimera DB har alla olika sorts resurser slagits > > samman i en enda stor tabell. Det blir en del bytes extra per post, men > > sparar en del uppslagningar. >=20 > Cool. Jag k=E4nner att jag vill komma p=E5 banan med detta igen. Jag h=E5= ller > p=E5 att diskutera att starta bolag med ett par f=F6re detta > framfab-kollegor. WRAF =E4r en av de saker jag tagit upp som m=F6jliga > produktid=E9er. Delvis d=E4rf=F6r jag skrev texten. Jag skall ner till Lu= nd i > helgen f=F6r att diskutera med dem. Som jag sagt f=F8rut. Jag "visste" du skulle starta nytt igen och vill h=E6= nga med. Skaru flytta till Lund? Iaf vill jag bli klar med det h=E6r uppdraget s=E5 jag kan forts=E6tta med = WRAF. > > Har lagt pussel med hur de olika modulerna anropar varandra. S=E5 just = nu > > anv=E4nds 3 generationer av APIs om vart annat, vilket g=F6r att inget > > fungerar =E4nnu. Har f=F6rs=F6kt undvika dependency loops och h=E5lla = reda p=E5 > > r=E4tt context samtidigt som jag vill kunna cacha objekt och g=E4rna sl= ippa > > skicka med context-objekt =F6verallt. Och givetvis s=E5 att man ska kun= na > > plugga in fler eller nya versioner av interface, scheman, funktioner, > > osv. > >=20 > > Programkoden har l=E5nga kommentarer i sig lite h=E4r och var. API-skis= sen > > =E4r inte uppdaterad, men okej. En del anteckningar finns ocks=E5 i wra= f2. > > SQL-filen =E4r iaf aktuell. > >=20 > > Dvs dokument: > > http://www.uxn.nu/wraf/devel/latest/doc/ > >=20 > > Testprogram: > > http://www.uxn.nu/wraf/devel/latest/bin/w22a.pl > >=20 > > Huvudmodulen: > > http://www.uxn.nu/wraf/devel/latest/lib/RDF_022.pm > >=20 > > Resten av modulerna: > > http://www.uxn.nu/wraf/devel/latest/lib/RDF_022/ > >=20 > > En nyckeldel =E4r interfacens registrering av de metoder de erbjuder, > > baserat p=E5 URI-prefix och type. Denna Register-funktion s=E4ger att d= en > > erbjuder metoden create_model() till alla resurser av typen 'model', > > oavsett vad de har f=F6r URI. > >=20 > > Dispatchern tar alla registers fr=E5n olika interface och skapar > > dedikerade jumptables f=F6r olika sorters resurser. > >=20 > > return > > { > > '' =3D> > > { > > NS_L.'model' =3D> > > { > > 'create_model' =3D> [\&create_model], > > }, > > } > > }; > >=20 >=20 > Det h=E4r l=E5ter ju stencool! Way! :-) Har n=E6stan kommit s=E5 l=E5ngt att jag kan skapa en model och lagra i databasen. Beh=F8ver dosk justera jumpjumptablen till att hantera de olika URI-prefixen. Sen funderar jag p=E5 en tredje interfacemodul att anv=E6nda f=F8r objekt m= an inte vill ska sparas i databasen, utan enbart tillf=E6lligt i minnet. Exemmpelvis sessionsdata och s=E5dant. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Sat Aug 5 15:07:47 2000 Date: Sat, 5 Aug 2000 16:07:47 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Application framework (was Re: [Templates] TT2 bug) Anybody remember the previous request about this? I would like to see another layer on top of TT for a complete solution including navigation in relational databases, heiarcical content, validating input, nested dependencies in record creation, versioned content management, user priviligies and plugin functions for mailbox and other things. I have started on something like this and would like to describe the diffrent components and what they is supposed to solve. ... I'm a little torn about this becuase I am also deeply engaged in another project (WRAF) with the same goal, but a completly diffrent approach, building from the ground on an RDF engine. A previous prototype in this project uses TT (with templates embedded in the RDF DB) for presentation. The next version may use a custom RDF presentation template mechanism in combination with TT templates. A small amount of info can be found here: http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ That means that I would see a TT based application framework as a temporary solution until WRAF (partly using TT for presentation) is ready for use. On Sat, 5 Aug 2000, Andy Wardley wrote: > I'm about to start a project for Canon to build a conglomerated > mailing list / bulletin board / FAQ-maker / web archive to allow > Canon customers to find out about, discuss, ask question on Canon > products, etc. Think of an online "User's Club" to get an idea. > > I've been prototyping with FAQ-O-Matic which is nice but very hard to > customise. I've been dreaming of a fully-functional engine to handle > the back end for accepting submission via the web or email, and then > acting as a cental dispatcher to forward messages on. I'm thinking that > you could subscribe to a mailing list, set filtering options to ignore > certain subjects, read and/or post via the web if you prefer, provide > simple editing commands for moderators to automatically build discussions > into FAQ's (like FAQ-O-Matic), maybe even go as far as a Slashdot like > environment, and so on, and so on. > > Of course, the front end would be template driven allowing anyone to > install it and simply hack a few templates to get their own look and > feel, to change the layout, or whatever. Or you could hack on the back > end without having to wade through loads of embedded HTML stuff. > > I also notice that a recent discussion on one of the Perl6 lists > was suggesting such a thing. I think this would be a real killer > app and of course, a great example of what TT2 can do. I'm sure we > could find a dozen or so people interested in working on this and > have something built in no time. > > It might also make an excellent subject for an ongoing column in a > magazine such as Web Techniques. Anyone know anyone who writes for > such a journal? :-) > > > A > > -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@rit.se Sat Aug 5 19:43:20 2000 Date: Sat, 5 Aug 2000 20:43:20 +0200 (CEST) From: Jonas Liljegren jonas@rit.se Subject: [RDF] RDF status report http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0019.html --=20 jonas@rit.se RIT AB http://www.rit.se Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36 Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609 From jonas@rit.se Sat Aug 5 20:02:31 2000 Date: Sat, 5 Aug 2000 21:02:31 +0200 (CEST) From: Jonas Liljegren jonas@rit.se Subject: [RDF] WRAF Har kodat p=E5 WRAF st=F8rre delen av dagen =3D-) Tabelldefinitionerna har f=F8r=E6ndrats: =09http://www.uxn.nu/wraf/devel/latest/doc/rdf2.sql Kom p=E5 att jag m=E5ste bryta ut sj=E6lva URI<->id. (Varje model f=F8r en = URI f=E5r sin egen node record.) S=E5 ins=E5g jag ocks=E5 att vi troligen kommer att ha model filters och language filters och senare =E6ven andra filters. S=E5dana filters funderar jag p=E5 att implementera som egna objects. Redan innan detta har varje interface-lista sitt eget object f=F8r en URI. Det betyder allts=E5 att om vi exempelvis har resursen som representerar Jonas. Olika k=E6llor kan ha sagt olika saker om denna resurs. S=E5 om vi h= ar exempelvis kopplat upp oss mot databas A och B och fr=E5gar vad f=F8r properties Jonas har s=E5 f=E5r vi ett annat svar =E6n om n=E5gon uppkoppla= d mot B och C fr=E5gar samma sak. Jag vill ju lagra svaret i objektet. D=E6rf=F8r = har jag ett objekt f=F8r varje kombination av uppkopplade interface. Det =E6r detts om jag internt kallar IDS och i tidigare brev kallat signatur. Och eftersom ett objekt =E6r dedikerat f=F8r enbart en signatur kan den ha en e= nda jumptable som attribut i objektet som anpassats f=F8r att anropa just de funktioner den har tillg=E5ng till. L=E5t s=E6ga att vi inte litar p=E5 Urban. D=E5 vill vi filtrera bort state= ments om Jonas som kommer fr=E5n Urbans models. Det ger helt andra svar p=E5 fr= =E5gor s=E5 som vilka properties Jonas har. Ska denna filtrering ske vid varje request eller ska ett filtrerat objekt skapas? Iaf. Har lagt in create_model i DBI-interfacet nu. Hmm. N=E6stan. Och st=E6dat upp en massa buggar. F=F8rsta g=E5ngen p=E5 flera veckor jag fakti= skt exekverat koden. :-) =C5terst=E5r ocks=E5 att l=E6gga in URI-prefixet i jump-jump-tablen. --=20 jonas@rit.se RIT AB http://www.rit.se Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36 Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609 From jonas@paranormal.se Sun Aug 6 21:58:13 2000 Date: Sun, 6 Aug 2000 22:58:13 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] wraf Har fortsatt p=E5 RDF 0.22 Dispatchern anv=E6nder prefix nu. Och ger b=E6ttre l=F8pande info om vad so= m h=E6nder vid ett metodanrop, dvs skapandet av jumptables. RDF_022::Interface::DBI::V01 =E6r n=E6stan klar f=F8r att man ska kunna ska= pa en model. Resten av modulerna =E6r synkade d=E6r det spelat roll f=F8r testprogrammet= ( bin/w22a.pl ). K=E6nns inte s=E5 motigt l=E6ngre. :-) Kanske delvis f=F8r att jag tror at= t du bryr dig. St=F8tte iofs p=E5 ett heldumt fel som visade sig vara en bugg i en standardmodul till perl (base.pm) s=E5 nu k=F8r jag med perl 5.6 ist=E6llet= =2E.. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Mon Aug 7 17:24:58 2000 Date: Mon, 7 Aug 2000 18:24:58 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] WRAF 0.22 klar Latest sparad som 0.22. Programmet fungerar nu. Dvs om du loggar in och k=F8r /var/www/uxn.nu/wraf/devel/WRAF-0.22/bin/w22a.pl kommer den efter lite debugginfo att svara med "** The uri of the model is [...]". Och den sparas i DBn. Eftersom det inte h=E6nder mer =E6n s=E5 s=E5 kan jag inte s=E6ga hur buggi= g den =E6r. Men nu ska jag g=E5 ett par steg till. En fr=E5ga =E6r hur programmet ska bete sig n=E6r man s=E6ger "ge mig objek= tet som representerar resursen med denna URI". Ska programmet klaga om det inte hittar denna resurs i n=E5got interface, eller ska den v=E6lvilligt skapa objektet om det inte finns? Egentligen inneh=E5ller inte resurserna sj=E6lva n=E5gon data. Det =E6r enb= art n=E6r man kopplar samman dem som information skapas. Men man kanske vill veta om resursen f=F8rekommer i n=E5got interface eller inte. Jag f=F8resl=E5r get() f=F8r att h=E6mta den oavsett vad och find om man ba= ra =E6r intresserad av resurser som redan har data. ...=20 Om get() inte anropas fr=E5n en skrivbar model kan inte n=E5gon ny info kopplas till den. D=E5 borde v=E6l inte heller resursen sparas ned i DBn. M= en DB-interfacet borde kanske =E6nd=E5 acceptera ansvaret? G=E5r vidare med 0.23... --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Mon Aug 7 18:52:00 2000 Date: Mon, 7 Aug 2000 19:52:00 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] RE: Java API (fwd) Forgot to send a copy to our list. Aj =E6m being v=E6rry internatjonal just nu. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Mon, 7 Aug 2000 19:44:46 +0200 (CEST) From: Jonas Liljegren To: "McBride, Brian" Cc: 'Jan Grant' , "RDF Interest (E-mail)" Subject: RE: Java API Resent-Date: Mon, 7 Aug 2000 13:46:01 -0400 (EDT) Resent-From: www-rdf-interest@w3.org On Mon, 7 Aug 2000, McBride, Brian wrote: > > The ability to store class definitions (for example) in an=20 > > RDF model is appealing. >=20 > Could you say a little more about what you have in mind here? >=20 > I did consider having a mapping from RDF types to Java classes > that implement those types so that whenever a resource 'got' > an object of the correct Java class would be instantiated. >=20 > I haven't done that because I don't think the RDF and Java > type models are sufficiently similar, e.g. if a resource has > two types, which one do I instantiate. This is exactly what I have done with WRAF. And this is whay I say "strange OO" in the (very) short presentation: =09http://www.uxn.nu/wraf/ The goal is like skipping several generations of RDF applications and going for the "ultimate" thing. :-) Since I'm just today actualy have a working (bare bones) pre alfa version, I would like to tell a little more about this thing. Hold on. will now write somthing up and send it as a separate email. :-) --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Mon Aug 7 20:21:37 2000 Date: Mon, 7 Aug 2000 21:21:37 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] WRAF 0.22 klar On Mon, 7 Aug 2000, Stefan Andersson wrote: > Hall=E5 d=E4r! En r=F6st fr=E5n graven... Hej. Har precis skrivit till RDF-listan och lovat en presentation. S=E5 jag har m=F8blerat om lite p=E5 webbplatsen. Gjort k=E6llkoden tillg=E6nlig. Och klistrat in en GPL copyright. ;-) api2.html =E6r inte uppdaterad tyv=E6rr. Iaf. N=E5got litet ska jag skriva. > > Egentligen inneh=E5ller inte resurserna sj=E6lva n=E5gon data. Det =E6r= enbart n=E6r > > man kopplar samman dem som information skapas. Men man kanske vill veta= om > > resursen f=F8rekommer i n=E5got interface eller inte. >=20 > Precis. Men i s=E5 fall f=E5r man veta det genom att det returneras en ko= pia > av n=E5got eller en kopia av inget. Fr=E5gan =E4r d=E5: =C4r inget och en= kopia av > inget ekvivalent? D.v.s. =E4r t.ex. ett odefinierad str=E4ng och den tomm= a > str=E4ngen ekvivalenta? Det borde finnas ett s=E4tt att skilja mellan att > objektet inte =E4r definierat, och att det =E4r ett tomt objekt. Eller ha= r > alla objekt minst en property? Om modellen =E4r property-centric m=E5ste = den > ju ha det? Eller? >=20 > F=F6r - i en property-centric v=E4rld, kan man d=E5 inte s=E4ga att _alla= _ > m=F6jliga resurser faktiskt finns? D.v.s. _alla_ objekt finns alltid? Och > s=E5 =E4r det en fr=E5ga om vilka som =E4r intressanta? Objekt kan vara helt informationsl=F8sa. Ska iaf kunna vara det. Och URI-poster i DBn har inte heller n=E5gon information. Helt klart ska man kunna skapa objekt utan att de finns i n=E5got interface och utan att de lagras d=E6r. Tror det =E6r s=E5 det fungerar nu. Det enda = som lagras i objektet =E6r ju en jumptable till metoder som interfacen tillhandah=E5ller. > > Jag f=F8resl=E5r get() f=F8r att h=E6mta den oavsett vad och find om ma= n bara =E6r > > intresserad av resurser som redan har data. ... >=20 > 'find' skulle v=E4l returnera en URI eller en bag av URI som motsvarar > n=E5gon sorts urval, om s=E5 bara efter URI? find_arcs i RDF1 letar statements. T=E6nkte att find kanske returnerar objekt om man skickar med en URI eller en model om man skickar med 0-3 resource objects. Fast de kan ju ist=E6llet ha var sitt namn. Dvs find respektive find_arcs. (Tar resten separat) --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Mon Aug 7 20:51:34 2000 Date: Mon, 7 Aug 2000 21:51:34 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] WRAF 0.22 klar On Mon, 7 Aug 2000, Stefan Andersson wrote: > > G=E5r vidare med 0.23... > > Skitcoolt. Lund sket sig. Men jag gnager vidare efter s=E4tt att f=E5 gjo= rt > detta. Jag satt och hetsade upp mig =F6ver WRAF p=E5 t=E5get till Lund, l= ite > nyt=E4ndning. :-) Hj=E4lp mig hitta en ers=E4ttare f=F6r det h=E4r jobbet s=E5 kan jag k= omma hem snabbare. > Jag har f=E5tt en hel del bra aff=E4rsm=E4ssig feedback p=E5 WRAF. Det ST= ORA > problemet =E4r att ingen kan se vem som =E4r kunden. Alla h=E5ller med om= att > det =E4r kraftfullt och fr=E4ckt, men ingen kan se en klar kund, vem som= =20 > skulle betala f=F6r det, b=E5de vad g=E4ller utveckling av det, och > licensiering. Det =E4r en sv=E5r utmaning. Jag tror p=E5 WRAF och att det kan vara en anv=E6ndbar verktygsl=E5da f=F8r exempelvis webbapplikationer. Exempel: P=E5 RIT beh=F8ver vi ett intran=E6t f=F8r att h=E5lla reda p=E5 kunder och= de tj=E6nster de har. Dvs dom=E6ner, hemkataloger, mailboxar, mailforward, till=E6ggstj=E6nster och annat. Vi beh=F8ver ett =E6rendehanteringssystem. Allts=E5 kommer =E6renden kopplas till kund, anst=E6lld och tj=E6nst. Vi beh=F8ver dokumenthantering och en supportdatabas. S=E5 aktiviteten vid hanteringen av =E6renden skapar dokument f=F8r tj=E6nster som kan s=F8kas a= v kunden. Vi beh=F8ver kontrollera att alla tj=E6nster fungerar och se till s=E5 att alla register =E6r synkade. Dvs ska s=E5dant som webbl=F8senord, FTP-l=F8senord, DNS-entries, mailalias, osv, vara sykat med motsvarande information om vilka tj=E6nster en kund har. Och detta ska vara underlag f=F8r fakturering. Och med kopplingen till de olika servrarna beh=F8vs =E6ven metadata om dessa. Dvs IP-adresser, backup-systemet, n=E6tverk, osv. Kan forts=E6tta l=E6nge. Vad som beskrivs h=E6r =E6r ett stort komplext f=F8r=E6nderligt distribuerat system. Eftersom vi hela tiden utvecklar nya tj=E6nster och anpassar oss efter kundens =F8nskem=E5l kan inte ett statisk= t system fungera. Hur kontaktas en kund? Oftast =E6r det sm=E5f=F8retag, s=E5 det =E6r en person som kontaktas f=F8r information, fakturor, etc. Men det finns mer undantag =E6n regler h=E6r. Vi vet inte i f=F8rv=E6g vilka data v= i beh=F8ver koppla till en kund. Det blir nya saker hela tiden. Vad jag har sagt till alla p=E5 RIT =E6r att jag vill anv=E6nda WRAF som ba= s f=F8r intran=E6tet. Och n=E6r vi kommit en bit p=E5 v=E6gen kan vi generali= sera och hyra ut liknande tj=E6nster f=F8r v=E5ra kunder. Alla v=E5ra sm=E5f=F8retagskunder ska allts=E5 kunna ha kundregister med kopplingar til= l den information de anv=E6nder. Exempelvis deras specifika tj=E6nster. Och vi tar betalt dels per m=E5nad f=F8r att de an=E6vnder systemet via v= =E5ra servrar och dels l=F8pande f=F8r alla nya f=F8r=E6ndringar och ut=F8kningar= de vill ha hj=E6lp med. S=E5 vi bygger och s=E6ljer generaliserade men h=F8gst anpassningsbara extran=E6t. Med webbshoppar, gruppvara, dokumenthantering, kunskapshanteringssystem, kontorsadministration osv. Det m=E5 ta ett tag. Men s=E5 vitt jag kan bed=F8mma har jag friheten att utveckla detta RIT. En blygsam l=F8n. Men n=E6stan total frihet. Och just eftersom vi hostar dessa l=F8sningar finns det inget som hindrar att programvaran =E6r fri. Det kan dessutom ge en extra kraft =E5t utvecklingen och g=F8ra WRAF till industristandard. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Mon Aug 7 21:10:44 2000 Date: Mon, 7 Aug 2000 22:10:44 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] =?iso-8859-1?Q?Plan_f=F8r_forts=2E?= On Mon, 7 Aug 2000, Stefan Andersson wrote: > Vi beh=F6ver ocks=E5 en 'killer-app'-n=E5got som _bara_ WRAF skulle kunna > g=F6ra. Vad =E4r den centrala po=E4ngen med att modellera allt i DLG/RDF[= S], > typ - varf=F6r inte OODB och XML? >=20 > Missf=F6rst=E5 mig r=E4tt - JAG vet. Men WRAF =E4r en lampa, n=E4r jag be= h=F6ver en > laser... och det =E4r stort. Sv=E5rt att =F6vertyga folk att en liten > operation skall kunna genomf=F6ra n=E5got s=E5 stort. Japp. Kan du ha klar texten som beskriver WRAFs f=F8rdelar tills imorgon? Vill skicka den till han p=E5 TT-listan. :-) > Kan vi tr=E4ffas snart igen, n=E4r du k=E4nner att du kan demonstrera > ramverket p=E5 ett vettigt s=E4tt f=F6r mig - d.v.s. modeller, interface, > et.c? S=E5 kan jag f=E5 fundera, och vi kan f=F6rs=F6ka l=E4gga upp en ny= plan? Det =E6r ju egentligen inte s=E5 mycket komponenter i grunden. I princip h=E6mta/spara objekt och triples. Men det finns en del extradetaljer som tar mer tid. Dvs distribuerade properties, implicita properties och att h=E5lla reda p=E5 vad som ska vara implicit respektive explicit. Det blir en hel del specialfall. Sen ska cachesystemet skapas (med expiration) och se till att uppdateringar expirar r=E6tt objekt. Sessionshantering eller presentation har jag inte alls p=E5b=F8rjat. Inte heller c/s-uppdelningen. S=E5 under "=F8versk=E5dlig" tid kommer jag enbart ha sm=E5 program som anv=E6nder RDF-modulen. Det jag har ramverket nu f=F8r =E6r grunden f=F8r hur man kopplar upp sig mot interface och anropar metoder. S=E5: Att skapa presentationsgr=E6nsnittet =E6r ett arbete som inte =E6r p=E5b=F8rjat och som beh=F8ver en hel del jobb. Du =E6r v=E6lkommen att modellera fram lite ideeor om hur det skulle kunna se ut. > Stigarna har inte st=E4ngts f=F6r UXN/WRAF, men vi har fortfarande inget = att > visa. Vi beh=F6ver d=F6da lite alibi, kunna visa p=E5 en liten applikatio= n som > g=F6r det ingen trodde man kunde g=F6ra med en s=E5n liten insats. F=F6r = det =E4r > k=E4rnargumentet i WRAF, som jag ser det. Allt det WRAF glr, kan g=F6ras = med > traditionell tekniker i dag. Argumentet m=E5ste vara att det g=E5r att g= =F6ra > m=E5nga g=E5nger _effektivare_. Och d=E5 kr=E4vs bevis. Exempel. Case. > Demonstrationer. A-ha-upplevelser! Japp. Och f=F8r detta beh=F8vs ju en modell. Det jag g=F8r =E6r bara motorn. Du f=E5r g=E6rna jobba vidare p=E5 just hur demonstrations-schemat ska se ut. S=E5 kan vi synka mot varandra tills det g=E5r att implementera det du t=E6nkt dig. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 08:02:09 2000 Date: Tue, 8 Aug 2000 09:02:09 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] WRAF 0.22 klar On Mon, 7 Aug 2000, Stefan Andersson wrote: > Allts=E5, jag t=E4nkte p=E5 det d=E4r med hur man skall t=E4nka p=E5 att = 'l=E4gga > till' data till modellen, n=E5got som ju inte RDF behandlar egentligen. I > RDF _representerar_ man en modell, man l=E4gger inte till. >=20 > Det handlar ju _egentligen_ om att man g=F6r uttalanden om objekt/resurs, > right? Ja. > Och lokal data om 'remota' objekt kan ju ses som lokal kopia/cache, > right? All data =E6r uppm=E6rkt med vilken model de h=F8r till. Du kan bara g=F8ra f=F8r=E6ndringar i models som du dels =E6ger och som dels fortfarande =E6r "=F8ppna". N=E6r en model =E6r markerad som "closed" =E6r det en signal til= l omv=E6rlden att den inte kommer att f=F8r=E6ndras. Enbart ers=E6ttas med en= ny modell, om det skulle vara aktuellt. > D=E5 =E4r ju egentligen datatill=E4gg helt enkelt lokala kopior av gjorda > statements - d.v.s. om jag g=F6r en serie statements s=E5 uppdaterar jag > samtidigt systemet. Nya statements hamnar i en model som du sj=E6lv =E6ger. Tills vidare kommer alla models att f=E5 en URI under en specifik lokal namespace. N=E6r ett system f=F8r agents/users och authentication finns kan man knyta vilka namespaces som =E6gs av vilken agent. Hittills har man halvt om halvt antagit att modellens inneh=E5ll ska kunna finnas under den URL som representeras av modellens URI. Men det m=E5ste f=F8r=E6ndras med tiden. Det verkar som om man allm=E6nt v=E6ntar p=E5 arbe= tet med digital signatures "trusted web" i samband med XML. > Statementen kan antingen 'l=E4ggas till' i modellen, rymden, genom att ma= n > a) G=F6r systemet uppm=E4rksam p=E5 att en viss resurs g=F6r uttalanden o= m en > 'lokal' resurs (native eller lokal kopia) s=E5 systemet kan inkorporera > resursen i en query, eller kopiera resursen lokalt. Ett interface kan ha hand om resurser som finns n=E5gon annan stans p=E5 webben. Det =E6r interfacets uppgift att se till att uppgifterna =E6r aktuella. Den f=E5r h=E5lla reda p=E5 =F8ppna models och uppdatera motsvara= nde objekt. Man kan ocks=E5 sl=E5 upp om dessa models finns i en lokal DB nedsparade som kopia, och f=E5r d=E5 uppdatera dem med. Det =E6r allts=E5 = min intention att implementera n=E5gon form av "push". > b) F=F6rser systemet med ett set anonyma uttalanden, som f=E5r lokala URI= :er > (klassiskt RDF:: - objektskapande) Nej. Alla uttalanden m=E5ste ske inom en model. Det =E6r allts=E5 numera et= t m=E5ste att f=F8rst skapa en model och d=E6refter kan man g=F8ra statements= i denna model. Och det =E6r allts=E5 t=E6nkt att denna models ska skapas p=E5 basis av n= =E5gon form av authenticiering och data om vem det =E6r som vill skapa en model. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 09:19:50 2000 Date: Tue, 8 Aug 2000 10:19:50 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] RDF (fwd) --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Tue, 08 Aug 2000 09:52:49 +0200 From: Stefan Andersson To: Jonas Liljegren , rdf@uxn.nu Subject: RDF Halloj. H=E4r =E4r ett f=F6rslag till engelsk presentation. Notera att det finns en hel del nyp=E5hitt i den, s=E5dant jag t=E4nkte p=E5 t=E5get. Har jag missa= t n=E5got, har jag ljugit? Speciellt det d=E4r med vad som =E4r standard, rekommendation, et.c... --------------------------------------------------------------------------- Web Resource Application Framework (WRAF) key features: WRAF is primarily designed as a platform for: =B7 Data-driven web applications with complex class hierarchies and inter-resource relations, such as metadata repositories, topic communities and intranets. =B7 Applications collecting, processing and presenting information from many sources, distributed over many processes. =B7 Intelligent agents and robots. =B7 Dynamic content, where the content selection and presentation is a result of complex dependencies. WRAF offers=20 =B7 an consistent interface to and between multiple information sources =B7 the possibility of rich data and metadata modeling through inheritance =B7 an open, standardized and extensible way of describing and exchanging resources, inter- as well as intraorganizational. =B7 a framework for RAD (Rapid Application Development) and realtime system extension through schema remodeling. WRAF is built upon =B7 RDF, an open W3C (WWW Consortium) standard for distributed resource modelling through DLG (Directed Labeled Graphs). =B7 RDF-Schema, the W3C standard for schema modelling under RDF =B7 RDF-XML, the W3C standard for expressing RDF data in XML. =B7 RDF QDS, an query definition schema modelled in RDF. =B7 RDF SDS - The Serialisation Definition Schema is used to describe transformations between a RDF DLG and serialized formats, such as RDF-XML, native XML, [X]HTML, WML, et.c. =B7 WRAF XML SDS - A base SDS for expressing RDF as XML =B7 WRAF [X]HTML SDS - A base SDS for expressing RDF resources as [X]HTML =B7 RDF DB - An interface for storing and retrieving RDF DLG in relational databases =B7 WRAF API - The core functionality, exposing RDF models and interfaces. WRAF IE - The Inference Engine enables applications that do not share data definitions to identify and bridge RDF Schema incompatibilities. Currently, all functionality is implemented as an UNIX service deamon with a cgi/mod_perl client. The RDF, RDF-XML and RDF-Schema are open W3C standards. The RDF DB, WRAF API and WRAF IE are open source as per GNU Public License, and will be given to CPAN upon completion. The RDF QDS and SDS will be submitted as standards proposals upon completion. --------------------------------------------------------------------------- /Stefan From jonas@paranormal.se Tue Aug 8 09:41:35 2000 Date: Tue, 8 Aug 2000 10:41:35 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] WRAF 0.22 klar (fwd) Oups. Gl=F8mde ta med rdf... --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Tue, 8 Aug 2000 10:41:08 +0200 (CEST) From: Jonas Liljegren To: Stefan Andersson Subject: Re: [RDF] WRAF 0.22 klar On Tue, 8 Aug 2000, Stefan Andersson wrote: > > Nya statements hamnar i en model som du sj=E6lv =E6ger.=20 >=20 > 'Anonyma' statements, menar du d=E5? Namngivna b=F6r ju kunna placeras in= i > namngiven model? Anonyma statements m=E5ste f=E5 lokala URIs, men knytas till samma model =E6nd=E5. Det =E6r ett problem. Men man f=E5r v=E6l m=E6rka upp dem p=E5 n= =E5got s=E6tt att de =E6r anonyma. Det skulle varit b=E6ttre med officiella URIs, men det g= =E5r inte att f=E5. > > Ett interface kan ha hand om resurser som finns n=E5gon annan stans p= =E5 > > webben. Det =E6r interfacets uppgift att se till att uppgifterna =E6r > > aktuella. Den f=E5r h=E5lla reda p=E5 =F8ppna models och uppdatera mots= varande > > objekt. Man kan ocks=E5 sl=E5 upp om dessa models finns i en lokal DB > > nedsparade som kopia, och f=E5r d=E5 uppdatera dem med. Det =E6r allts= =E5 min > > intention att implementera n=E5gon form av "push". >=20 > Publish-subscribe... Ja. Det var s=E5 du kallade det. :-) Iaf. Du m=E6rker kanske att jag tar tillvara allt det vi pratat om? :) > > Och det =E6r allts=E5 t=E6nkt att denna models ska skapas p=E5 basis av= n=E5gon form > > av authenticiering och data om vem det =E6r som vill skapa en model. >=20 > Fr=E4ckt, och egentligen ganska sj=E4lvklart. Men: Hur blir n=E5gonsin en > modell medveten om att n=E5gon annan g=F6r ett uttalande som ber=F6r mode= llen? > Jag t=E4nker p=E5 n=E4r man skall st=E4lla fr=E5gor och s=E5. Jag t=E4nke= r mig att man > g=F6r ett uttalande 'Den h=E4r resursen uttalar sig om den h=E4r resursen= '. > Allts=E5 - ett s=E4tt att modellera vilka auktoriteter som skall litas p= =E5 > att f=E5 g=F6ra uttalanden om en viss resurs eller modell. Agenten/usern m=E5ste best=E6mma vilka models han anser som fakta och vilka som inte =E6r det. Det var det jag n=E6mnde f=F8rut om filter. Att man s=E6kert vill kunna fil= trera olika s=F8kningar baserat p=E5 vem som st=E5r f=F8r modellen. Men default har jag t=E6nkt mig att man litar p=E5 allt. Utom det som model= len sj=E6lv angivit som icke-facts. (En icke fact i en modell =E6r egentligen e= n fact i n=E5gon annans. Bara at man inte har tillg=E5ng till den andras modell.) S=E5 jag t=E6nker mig n=E5got i stil med att du placerar filter i RDF-objek= tet innan du kopplar upp. D=E5 ligger filtret i IDS. =20 Men ett b=E6ttre alternativet =E6r att man l=E6gger filtret i en model. Dvs= att man skapar en virituell model som representerar alla statements i alla interface, man bara de som h=F8r till modells man litar p=E5. Alla s=F8kningar sker genom modeln och kommer d=E5 att filtreras enligt det filtret som ligger i model-objektet. I WRAF =E6r det t=E6nkt att alla s=F8kningar ska retunera virituella models. Dessa =E6r inte skrivbara och kommer inte att sparas i n=E5got interface. Dessa models kommer inte bara att best=E5 av en l=E5ng lista resurser utan ist=E6llet av en lista med "s=F8kningar".=20 Om man exempelvis s=F8ker efter alla statements i alla uppkopplade interfac= e s=E5 kommer modeln att best=E5 av en lista med ett element f=F8r varje interface. Om man sedan g=F8r en fortsatt urval ur den modeln kommer en ny model att skapas d=E6r varje element modifieras med det nya kriteriet. Int= e f=F8rr=E6n man faktiskt vill enumerera resurserna kommer dessa att h=E6mtas= fr=E5n respektive interface. Ett element kan allts=E5 vara en annan model, en enstaka resource, ett interface eller ett s=F8kbegrepp. Jag har inte =E6nnu implementerat detta, men det =E6r vad jag planerat. F= =F8r stora datam=E6ngder vill man ju helst uppr=E6tta n=E5gon slags datastr=F8m = mellan interfacen och klientprogrammet. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 17:43:12 2000 Date: Tue, 8 Aug 2000 18:43:12 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] =?iso-8859-1?Q?=C4nnu_mera_WRAF_=28fwd=29?= --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Tue, 08 Aug 2000 17:43:20 +0200 From: Stefan Andersson To: "Jonas Liljegren (E-mail)" Subject: =C4nnu mera WRAF Det h=E4r var vad jag skrev till min Lund-kollega alldeles nyss: Tjaba! Andr=E9s, jag vill inte vara tjatig, men p=E5 v=E4gen ner till Lund satt ja= g och funderade igenom WRAF, f=F6r jag t=E4nkte presentera den f=F6r er. Det = =E4r sv=E5rt. Och jag vet att jag inte f=E5tt ordning p=E5 'vem =E4r kunden'. Ka= nske =E4r det s=E5 att jag m=E5ste _skapa_ en kund genom att visa p=E5 visionen? S=E5, jag t=E4nkte g=F6ra ett f=F6rs=F6k till att f=F6rklara vad den egentl= iga visionen =E4r/kan vara. Hear me out? Scenario: F=F6retaget F=F6retag AB har ett intran=E4t, baserat p=E5 WRAF. Intran=E4tet liknar framfabs lilla gula v=E4ldigt mycket. Nu kommer systemadministrat=F6ren AT p=E5 att i intran=E4tet borde det finnas ett inventarium =F6ver alla maskiner, deras konfigurationer och =E4gare. Anv=E4ndarna finns redan som resurser i intran=E4tet, s=E5 det =E4r inget problem. Vad AT g=F6r =E4r att han 'skapar personlig flik'. Den =E4r helt t= om s=E5 n=E4r som p=E5 en 'l=E4gg till objekt'-knapp. Han trycker p=E5 den, oc= h f=E5r upp en lista =F6ver m=F6jliga objekt att l=E4gga till. Han v=E4ljer 'lista'= =2E Han f=E5r d=E5 upp en =F6versikt =F6ver de objektklasser som finns definierade,= och trycker 'ny'. Han f=E5r d=E5 ge klassen ett namn - 'Dator'. Han f=E5r ocks= =E5 m=F6jlighet att tala om lite om vad som ing=E5r i en 'Dator' - den har t.ex= =2E ett 'Namn' och en '=C4gare'. AT talar om att '=C4gare' =E4r av klassen 'Anv=E4ndare', som ju redan finns. N=E4r han tryckt 'OK' hela v=E4gen tillbaka, har han nu en tom lista framf=F6r sig p=E5 sin personliga flik. N=E4r han nu trycker 'Ny' i listan (alla objekt har genom arv funktionalitet f=F6r 'l=E4gg till', '=E4ndra' och 'ta bort' automatiskt), f= =E5r han upp ett formul=E4r 'ny Dator', med f=E4lten han matade in f=F6rut, bl.a= =2E en lista, '=C4gare', som =E4r en lista =F6ver alla 'Anv=E4ndare'. Han kan d= =E5 knappa in namnet, och v=E4lja en =E4gare. AT g=F6r sedan denna resursen tillg=E4nglig f=F6r en st=F6rre m=E4ngd anv=E4ndare genom att l=E4gga till = fliken till presentationsdefinitionen f=F6r en grupp anv=E4ndare (anv=E4ndare av e= n viss klass) - ocks=E5 i ett webbgr=E4nssnitt. AT har allts=E5 skapat en sim= pel databasapplikation bara genom att beskriva sin verklighet. S=E5 l=E5ngt AT. Ute i 'verkligheten' kommer en anv=E4ndare p=E5 att det ka= nske vore en bra id=E9 att kunna notera var, geografiskt, datorn =E4r. Utan att AT beh=F6ver lyfta ett finger, trycker anv=E4ndaren 'l=E4gg till objekt' p= =E5 sin datorflik. Han f=E5r d=E5 v=E4lja vilken klass av objekt han vill l=E4g= ga till, och v=E4ljer d=E5 'textf=E4lt'. Efter att ha tryckt 'OK', kan han mat= a in namnet p=E5 objektet, 'Plats'. Efter att ha tryckt OK d=E4r ocks=E5, har han nu ett f=E4lt som heter 'Plats' i bilden. (En aspekt =E4r att det faktiskt =E4r v=E4ldigt simpelt i WRAF att l=E5ta d= enne anv=E4ndaren vara den ende som ser f=E4ltet, och det han matat in, tills AT best=E4mmer sig f=F6r att lyfta in den i 'allas' presentationsdefinition. WRAF _handlar_ om undantag.) Well. Hela po=E4ngen =E4r att f=F6r att WRAF dels representerar _allt_, obj= ekt s=E5 v=E4l som relationer, p=E5 samma s=E4tt, kan man enkelt etablera och administrera =E4ven komplicerade relationer. Med ett presentationslager som inte best=E5r av HTML-definitioner, utan ett form-schema, kan systemet anpassa formen efter varje enskilt objekts egenheter. T.ex. l=E5ta bli att visa foto p=E5 anv=E4ndaren, om det inte finns, eller =E4ndra layouten helt= om det finns flera. I vilket fall - jag har l=E4st ut Ender's shadow... Card =E4r bra. J=E4vla krass m=E4nniskosyn, men otroligt bra. Lite Niezsche =F6ver det. Inte s=E5 lite, f=F6rresten... Lev v=E4l! /Stefan PS. Vad betyder 'bicho?' DS. From jonas@paranormal.se Tue Aug 8 18:09:39 2000 Date: Tue, 8 Aug 2000 19:09:39 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Source Forge =C6rch. Kan inte v=E6nta... Jag har registrerat mig p=E5 Source Forge och kommer att l=E6gga upp projek= tet d=E6r. Fr=E5gan =E6r vilken licens vi vill ha. V=E6ljer vi GPL kan inte andra f=F8retag ta betalt f=F8r program baserad p= =E5 v=E5ran kod. (Men jag tror att vi sj=E6lva =E6r undantagna, s=E5 som =E6gar= e.) V=E6ljer vi Artistic License, s=E5 kan de det. Lika s=E5 med LGPL. Jag har lagt upp din intro h=E6r: =09http://www.uxn.nu/wraf/presentation/intro.txt Delen med "WRAF is built upon" =E6r jag tveksam till. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 19:19:47 2000 Date: Tue, 8 Aug 2000 20:19:47 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] SourceForge registration =C6r lite ivrig nu s=E5 det kan h=E6nda att jag g=E5r vidare =E6nd=E5 om ja= g inte f=E5r svar snabbt. Beh=F8ver ange flera saker f=F8r registrering p=E5 SourceForge. Jag vet int= e allt som beh=F8vs f=F8r man fyller i en sak i taget. Spenderade s=E6kert en halvtimma bara f=F8r att l=E6sa "Terms of Service". Iaf: Namn: Vad ska projektet kallas? Ska vi forts=E6tta med WRAF eller t=E6nka m= er l=E5ngsiktigt och d=F8pa projektet till Wraf ist=E6llet? License: =C6r GPL ett bra val? M=E5nga perl-moduler anv=E6nder Artistic License. Men de flesta anv=E6nder v=E6l GPL och Artisitc. ... Ett par anv=E6nder bara GPL. Iaf. Det g=E5r ju att =E6ndra p=E5. Description: M=E5ste ju f=F8rst=E5ss ber=E6tta vad det =E6r f=F8r n=E5got. = Tydligen b=F8r man vara ganska precis. S=E5 nu m=E5ste vi ha en bra beskrivning. Ska funde= ra p=E5 en. N=E5gra synpunkter? S=E5 h=E6r st=E5r det: Step 3: SourceForge Project Registration We now need a short description of your project. This description needs to contain the purpose of the project and a summarization of your goals.=20 If the SourceForge staff approves your project account, the account is to be used purely to meet the goals set forth in this statement. Use of the project account for anything other than the purposes and goals in this statement is prohibited. If you need to change this statement at any time, please inform a staff member and we will assist you in getting a new statement approved.=20 Project Purpose and Summarization=20 REQUIRED: Provide detailed, accurate description=20 --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 19:27:00 2000 Date: Tue, 8 Aug 2000 20:27:00 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: =?iso-8859-1?Q?=C4nnu?= mera WRAF On Tue, 8 Aug 2000, Stefan Andersson wrote: > > Jag ska kommentera dina senaste brev en g=E5ng till lite senare. (Du ve= t hur > > jag brukar vara.. ;) >=20 > Eh, jo, vi h=F6rs i... december? ;) Jag skulle b=F8rja med att kommentara din engelska beskrivning. Jag funderar p=E5 om jag bara ska =E6ndra i den text du skrev. Tror jag g= =F8r det. Klipper och klistrar och l=E6gger till och tar bort. S=E5 mailar jag l= =E6nk till resultatet. Ska ocks=E5 maila resultatet till dels RDF-listan och dels TT-listan. Och dels anv=E6nda till SorrceForge > > Men vill s=E6ga nu med en g=E5ng: =C6r du intresserad av att koda? Ja= g kan > > t=E6nka mig att sl=E6nga upp projektet p=E5 sourceforge p=E5 en g=E5ng. >=20 > Jag har aldrig jobbat i sourceforge. Men jo, jag sitter och funderar p=E5 > om vi skulle g=F6ra ytterligare ett f=F6rs=F6k att arbeta tillsammans. Det =E6r bara f=F8rdelar. Dvs bra webbgr=E6nssnitt f=F8r bugghantering CVS-browsing och massa annat. Du s=E6tter upp en CVS-klient och jobbar med din lokala kopia. Exempelvis i din hemkatalog p=E5 astral eller p=E5 n=E5gon annan dator om du vill. Med CVS kan flera personer jobba med samma fil. Om en deff visar att tv=E5 personer =E6ndrat p=E5 SAMMA RAD i samma fil, s=E5 finns verktyg f=F8r att = merga ihopp versionerna. Emacs har inbyggda funkioner som g=F8r det j=E6tteenkelt att arbeta med CVS= =2E > Annars kan jag ju koncentrera mig p=E5 t.ex. SDS... Det ocks=E5. Kommer v=E6l att l=E6gga upp dokumentationen d=E6r ocks=E5. Men vi beh=E5ller sj=E6lva webbplatsen p=E5 http://uxn.nu/wraf/ --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 20:02:33 2000 Date: Tue, 8 Aug 2000 21:02:33 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Source Forge (fwd) --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Tue, 8 Aug 2000 21:02:15 +0200 (CEST) From: Jonas Liljegren To: Stefan Andersson Subject: Re: [RDF] Source Forge On Tue, 8 Aug 2000, Stefan Andersson wrote: > > Vill vi att andra f=F8retag ska kunna anv=E6nda WRAF-biblioteket i > > kommersiella applikationer? >=20 > Ja. Dvs utan att betala oss. Om du tittar p=E5 licensen f=F8r Qt. Dvs biblioteket som anv=E6nds av KDE, = s=E5 =E6r Qt fritt f=F8r fria program men kostar pengar f=F8r kommersiella program. > > Vill vi att de ska kunna anv=E6nda modifiera eller ta kod fr=E5n > > WRAF-biblioteket utan att beh=F8va distribuera =E6ndringarna? >=20 > Klurigt. Jag =E4r kluven. Nej. Jag tror inte det =E4r en bra id=E9 - geno= mslag > =E4r nyckelt. Vad har t.ex. TT f=F6r licens? TT anv=E6nder den licens som rekommenderas f=F8r perl-moduler: COPYRIGHT Copyright (C) 1996-2000 Andy Wardley. All Rights Reserved. Copyright (C) 1998-2000 Canon Research Centre Europe Ltd. This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Det inneb=E6r att man kan v=E6lja mellan GPL eller Artistic Licence. Det tycker jag =E6r b=E6sta alternativet. Dessutom. Vi har ju inte n=E5got f=F8retag =E6nnu, s=E5 jag kan bara s=E6tt= a copyright till mig sj=E6v. Det k=E6nns som koden fortfarande =E6r mest min. Andy har givit Copyright b=E5de till det f=F8retag p=E5 vars tid han utvecklat TT och till sig sj=E6lvt. Vet inte hur/om man kan ge copyrigt till tv=E5 personer. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 20:18:58 2000 Date: Tue, 8 Aug 2000 21:18:58 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] =?iso-8859-1?Q?Re=3A_=5BRDF=5D_Re=3A_=C4nnu_mera_WRAF_=28fwd?= =?iso-8859-1?Q?=29?= --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Tue, 8 Aug 2000 21:18:36 +0200 (CEST) From: Jonas Liljegren To: Stefan Andersson Subject: Re: [RDF] Re: =C4nnu mera WRAF On Tue, 8 Aug 2000, Stefan Andersson wrote: > > Jag funderar p=E5 om jag bara ska =E6ndra i den text du skrev. Tror jag= g=F8r > > det. Klipper och klistrar och l=E6gger till och tar bort. S=E5 mailar j= ag l=E6nk > > till resultatet. >=20 > Precis vad jag =F6nskade att du skulle g=F6ra. Ok. Sitter v=E6l till 22:50 ungef=E6r. (Approp=E5 det s=E5 =E6r det, f=F8rr= utom att jag hellre vill jobba med WRAF, underbart st=E6lle h=E6r. Sitter p=E5 sjun= de v=E5ningen i en futuristisk kontorsbyggnad med eget rymligt snyggt kontor med f=F8nster mot atriumet. Trappor, g=E5ngar, "altaner" och catwalks kors = och tv=E6rs, med plantor. R=E6ckena, h=F8gt =F8ver marken, =E6r av glas. Svinde= l. Och hiss som g=E5r p=E5 utsidan med glasv=E6gg. Marken =E6r stenbelagd med kull= ar, lyktstolpar, en font=E6n, osv. Och matsalen ligger bortanf=F8r v=E6xtlighet= en, vid flygeln, och in under, med soffor, mysbelysning, etc. :-) Och jo just det. Access via kort dygnet runt. Och hygglig uppkoppling. Med ssh kommerjag till och med f=F8rbi brandv=E6ggen och kan k=F8ra X. > > Ska ocks=E5 maila resultatet till dels RDF-listan och dels TT-listan. O= ch > > dels anv=E6nda till SorrceForge >=20 > Cool. Se mitt f=F6rslag till =E4nnu mer kondenserad SourceForge-beskrivni= ng. Japp. Ska bygga p=E5 det. > > > Jag har aldrig jobbat i sourceforge. Men jo, jag sitter och funderar = p=E5 > > > om vi skulle g=F6ra ytterligare ett f=F6rs=F6k att arbeta tillsammans= =2E > >=20 > > Det =E6r bara f=F8rdelar. Dvs bra webbgr=E6nssnitt f=F8r bugghantering > > CVS-browsing och massa annat. >=20 > Mitt _stora_ problem =E4r att jag: > * Sitter hemma med en ISDN som redan kostar mig 5.000 i kvartalet... > * Sitter hemma i en Windows-milj=F6, med verktyg jag inte vet hur jag > skall f=E5 ihop med CVS. > * Sitter hemma. >=20 > Fan! Om jag skulle sats p=E5 detta, skulle jag vilja sitta n=E5gonstans, = i > ett kontor med fast lina. Undras var man kan hitta det... Varf=F8r betala ca 2000 i m=E5naden n=E6r man kan f=E5 fast uppkoppling f= =F8r n=E6stan 200? (Har du h=F8rt talas om bredbandsbolaget? ;-) Min =F8verenskommelse med Bearcom var p=E5 500 kr/m=E5nad, s=E5 som privatp= erson. *** Du =E6r v=E6lkommen att komma till RIT f=F8r att anv=E6nda deras uppkop= pling. =2E.. Det =E6r vad jag f=F8rs=F8kt antyda. Vi lovar RIT del av frukten av WRAF. Men du beh=F8ver inte binda dig till n=E5got. RITs lokaler =E6r inte v=E6rldens snyggaste. Men vi har plats f=F8r en elle= r tv=E5 personer till. > > > Annars kan jag ju koncentrera mig p=E5 t.ex. SDS... > >=20 > > Det ocks=E5. Kommer v=E6l att l=E6gga upp dokumentationen d=E6r ocks=E5= =2E >=20 > Egentligen kan SDS komma att bli v=E4ldigt enkelt i grunden. Men mer > komplext ju mer komplexa regler man vill skapa... Jag har inte accepterat termen SDS. Men det tar vi sen... > > Men vi beh=E5ller sj=E6lva webbplatsen p=E5 http://uxn.nu/wraf/ >=20 > Vi f=E5r v=E4l hitta p=E5 n=E5got p=E5 uxn.nu ocks=E5... jag kan g=F6ra d= et. Jo. Du menar f=F8retagspresentationen. Jag tycker det =E6r synd om du g=F8r samma "misstag" som jag och blandar privata och f=F8retagssidor. Jag har ju nu lyft ut mina sidor fr=E5n paranormal. T=E6nk p=E5 att f=F8retaget kanske v=E6xer men att vi m=E5ste forts=E6tta a= tt beh=E5lla de l=E6nkar vi skapar. ... Jag fick praktiskt taget publik utsk=E6llning f= =F8r att jag =E6ndrade min l=E6nk fr=E5n paranormal.o.se till paranormal.se, eft= ersom w3.org har en l=E6nk dit. S=E5 vill du verkligen f=F8r all framtid ha dina personliga sidor p=E5 f=F8retagets webbplats? --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 8 22:44:43 2000 Date: Tue, 8 Aug 2000 23:44:43 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Presentation Oj vad sent det blev. H=E6r =E6r en ny presentation. N=E5gra synpunkter? =09http://www.uxn.nu/wraf/ Kan detta anv=E6nds som project presentation and design goals? --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 09:33:27 2000 Date: Wed, 9 Aug 2000 10:33:27 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] SourceForge Jag har skickat iv=E6g ans=F8kan nu. Beskrivning baserad p=E5 webbsidan. Unix name: wraf License: other (man kunde bara v=E6lja en eller annan, s=E5 jag angav othe= r, och skrev in Artistic or GPL, (same as Perl) Svar inom 24 timmar s=E6ger de. Mitt konto =E6r "aigan". Du kan l=E6sa dokumentation h=E6r: =09http://sfdocs.sourceforge.net/sfdocs/ --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 10:42:47 2000 Date: Wed, 9 Aug 2000 11:42:47 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Wraf project status Here is a status report for Wraf: The front page, describing the goal has been updated: http://www.uxn.nu/wraf/ I am in the process of registring the project at https://sourceforge.net/projects/wraf/ We are now two active developers and will soon spend the majority of the time at this. It will have the standard Perl license. that is; Artistic or GPL. The overall architecture of the module is done. We feel that its now just a matter of implementation. The API is based on the discussion around RADIX and the Java RDF API and from the experience from the RDF Schema Editor. It uses a mix of traditional OO and Resource-centred methods. This is the core architecture: 1. my $service = new RDF( @authentication ); Create a service object by telling the system who you are. This, and all objects will be a regular RDF resource with its own types and metadata. 2. $service->connect($interface, @target); Connect to a couple of interfaces. These can be static RDF Schemas, DB storage, a http connection to another internet service or an interface to custom information resources, such as business systems, LDAP or anything else. It could also be interfaces to new functions. Each interface registrer availible methods to the service. These are dependent on a) The URI prefix and b) the resource type. 3. my $model = $service->create_model(); Every statement belongs to a model. This will crate an 'open' model in your default local namespace. create_model() is a method for resources of the type #Service. This method call will on the fly compile a jump table for the service object, consisting of functions from all interfaces implementing this method for the used namespace. The functions will be called in order of authority and the appropriate object returned. I will stop here because this is aproximatly how long I have come so far. But I do have a clear picture of how the rest will be done. Much consideration has been taking to make the system realy fast by caching and other things. The first DBI interface module has been optimized for minimizing the number of queries needed. It will cause some complexity. But that's ok. This is the present table layout: http://www.uxn.nu/wraf/doc/rdf2.sql The API overview, in the same dir as above, is out of date. The current source code can be viewd here: http://www.uxn.nu/wraf/src/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 11:23:55 2000 Date: Wed, 9 Aug 2000 12:23:55 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: pm: Wraf project status On Wed, 9 Aug 2000, Christian Stamgren wrote: > Det h=E4r l=E5ter v=E4ldigt sp=E4nnande,, > Jag tror att jag f=E5r l=E4sa in mig lite .... :-) Du =E6r v=E6lkommen att delta om du vill. S=E6tter nog upp en lista p= =E5 SourceForge snart. Men tills vidare finns denna: http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf > On Wed, 09 Aug 2000, you wrote: > > Here is a status report for Wraf: > >=20 > >=20 > > The front page, describing the goal has been updated: > > http://www.uxn.nu/wraf/ > >=20 > >=20 > > I am in the process of registring the project at=20 > > https://sourceforge.net/projects/wraf/ > >=20 > >=20 > > We are now two active developers and will soon spend the majority of > > the time at this. It will have the standard Perl license. that is; > > Artistic or GPL. > >=20 > >=20 > > The overall architecture of the module is done. We feel that its now > > just a matter of implementation. The API is based on the discussion > > around RADIX and the Java RDF API and from the experience from the RDF > > Schema Editor. It uses a mix of traditional OO and Resource-centred > > methods. > >=20 > > This is the core architecture: > >=20 > >=20 > > 1. my $service =3D new RDF( @authentication ); > >=20 > > Create a service object by telling the system who you are. This, and > > all objects will be a regular RDF resource with its own types and > > metadata. > >=20 > >=20 > > 2. $service->connect($interface, @target); > >=20 > > Connect to a couple of interfaces. These can be static RDF Schemas, DB > > storage, a http connection to another internet service or an interface > > to custom information resources, such as business systems, LDAP or > > anything else. It could also be interfaces to new functions. > >=20 > > Each interface registrer availible methods to the service. These are > > dependent on a) The URI prefix and b) the resource type. > >=20 > >=20 > > 3. my $model =3D $service->create_model(); > >=20 > > Every statement belongs to a model. This will crate an 'open' model > > in your default local namespace. > >=20 > > create_model() is a method for resources of the type #Service. This > > method call will on the fly compile a jump table for the service > > object, consisting of functions from all interfaces implementing this > > method for the used namespace. The functions will be called in order > > of authority and the appropriate object returned. > >=20 > >=20 > >=20 > > I will stop here because this is aproximatly how long I have come so > > far. But I do have a clear picture of how the rest will be done. > > Much consideration has been taking to make the system realy fast by > > caching and other things. > >=20 > > The first DBI interface module has been optimized for minimizing the > > number of queries needed. It will cause some complexity. But that's > > ok. This is the present table layout: > > http://www.uxn.nu/wraf/doc/rdf2.sql > >=20 > > The API overview, in the same dir as above, is out of date. The > > current source code can be viewd here: > > http://www.uxn.nu/wraf/src/ > >=20 > >=20 > > --=20 > > / Jonas - http://jonas.liljegren.org/myself/en/index.html > >=20 > >=20 > >=20 > > _______________________________________________ > > Perl mailing list > > Perl@goteborg.pm.org > > http://goteborg.pm.org/cgi-bin/mailman/listinfo/perl >=20 --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 12:23:24 2000 Date: Wed, 9 Aug 2000 13:23:24 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Hej! V=E4lkommen, Christian! :) H=E4r finns lite l=E6nkar. Men mycket har =E6ndrats s=E5 m=E5nga =E6r brut= na just nu. H=E6r =E6r iaf gamla Schema editorn: =09http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Wed Aug 9 12:08:39 2000 Date: Wed, 9 Aug 2000 13:08:39 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] Hej! Hejsan jonas, Läser du mina tankar ???? Jag sitter precis och skriver ett mail om att jag vill ha information ;^) Christian On Wed, 09 Aug 2000, Jonas Liljegren wrote: > Välkommen, Christian! :) > > Här finns lite lænkar. Men mycket har ændrats så många ær brutna just nu. > > Hær ær iaf gamla Schema editorn: > http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ > > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@paranormal.se Wed Aug 9 12:29:32 2000 Date: Wed, 9 Aug 2000 13:29:32 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Hej! On Wed, 9 Aug 2000, Christian Stamgren wrote: > L=E4ser du mina tankar ???? Ja. :-) > Jag sitter precis och skriver ett mail om att jag vill ha information ;^) Eftersom grunden =E6r RDF, och "Semantic Web", finns det mycket att l=E6sa = om just detta. L=E6nkar till dem finns p=E5 introsidan. Dvs: =09http://www.w3.org/RDF/ =09http://www.w3.org/DesignIssues/ --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 12:41:59 2000 Date: Wed, 9 Aug 2000 13:41:59 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Hej! On Wed, 9 Aug 2000, Christian Stamgren wrote: >=20 > On Wed, 09 Aug 2000, you wrote: > > On Wed, 9 Aug 2000, Christian Stamgren wrote: > >=20 > > > L=E4ser du mina tankar ???? > >=20 > > Ja. :-) > Vad skall vi d=E5 med en mailing lista till ;-)=20 Det =E6r inte alltid tankel=E6sningen fungerar. Och det =E6r besv=E6rligt a= tt skicka diffar via telepati. :-) --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 17:09:02 2000 Date: Wed, 9 Aug 2000 18:09:02 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Namespace registration RDF:: I'm developing a large RDF library for the WRAF project http://www.uxn.nu/wraf/ I would like to register the name "RDF". Second choice is "RDF::Wraf". The long version: ----------------- One could think that they should go under XML::RDF, but I don't agree with that. Reason: The librare doesn't (yet) using XML in any way. XML is used to communicate RDF data. But RDF itself is not based upon RDF. The WRAF modules mainly uses the DBI to store data. XML is not involved. The modules are in alpha stage. They presently consist of RDF RDF::Cache RDF::Config RDF::Constants RDF::Dispatcher RDF::Interface::DBI::V01 RDF::Interface::Schema::RDFS_200001 RDF::Resource RDF::Resource::Class RDF::Resource::Collection RDF::Resource::Collection::Module RDF::Resource::Function RDF::Resource::Interface RDF::Resource::Literal RDF::Resource::Model RDF::Resource::Statement The intention is that new RDF::Interface modules can be released as separate modules. (The reason for this enumeration of the modules was to argue that RDF in itself is big enough.) Eric Prud'hommeaux has created a couple of modules, put in the W3C name space: W3C::Rdf::RdfParser W3C::Rdf::RdfDB W3C::Rdf::RdfVisualizer W3C::Rdf::ListRdfParser Janne Saarela has announced "CPAN Module RDF::Parser V1.01" My first choise for the module name is RDF. But that may shut out other implementations. My second choice for the module name is RDF::Wraf. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 17:10:47 2000 Date: Wed, 9 Aug 2000 18:10:47 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] SourceForge Project Approved (fwd) Jippi! =-) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html ---------- Forwarded message ---------- Date: Wed, 9 Aug 2000 08:49:48 -0700 From: noreply@sourceforge.net To: jonas@paranormal.se Subject: SourceForge Project Approved Your project registration for SourceForge has been approved. Project Full Name: Web Resource Application Framework Project Unix Name: wraf CVS Server: cvs.wraf.sourceforge.net Shell/Web Server: wraf.sourceforge.net Your DNS will take up to a day to become active on our site. Your shell accounts will become active at the next 6-hour cron update. While waiting for your DNS to resolve, you may try shelling into shell.sourceforge.net and pointing CVS to cvs.sourceforge.net. If after six hours your shell accounts still do not work, please open a support ticket so that we may take a look at the problem. Please note that all shell accounts are closed to telnet and only work with SSH1. Your web site is accessible through your shell account. Directory information will be displayed immediately after logging in. Please take some time to read the site documentation about project administration. If you visit your own project page in SourceForge while logged in, you will find additional menu functions to your left labeled "Project Administrator". We highly suggest that you now visit SourceForge and create a public description for your project. This can be done by visiting your project page while logged in, and selecting 'Project Admin' from the menus on the left. Your project will also not appear in the Trove software map until you categorize it in the project administration screens. So that people can find your project, you should do this now. Visit your project while logged in, and select 'Project Admin' from the menus on the left. Enjoy the system, and please tell others about SourceForge. Let us know if there is anything we can do to help you. -- the SourceForge crew From jonas@paranormal.se Wed Aug 9 18:39:59 2000 Date: Wed, 9 Aug 2000 19:39:59 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Source forge Jag har satt upp projektet och b=F8rjat konfigurera det. Samt =E6ven konfigurerat min personliga profil. S=E5 nu =E6r det dags att registrera er: =09http://sourceforge.net/account/register.php Och d=E6refter hoppa in p=E5 projektsidan: =09https://sourceforge.net/projects/wraf/ Hemsida f=F8r projektet =E6r satt till: =09http://www.uxn.nu/wraf/ Det finns flera bra hj=E6lpmedel. Tyv=E6rr verkar diskussionsforum och mailinglists vara tv=E5 olika saker. S=E5 fr=E5gan =E6r vilket vi ska anv= =E6nda till att b=F8rja med. Ska vi g=E5r =F8ver till webbforum (man kan bevaka tr=E5darna) eller =F8ppn= a en mailinglista p=E5 sourceforge eller beh=E5lla denna listan? I vilket fall kommer all utveckling och framtida listtrafik vara p=E5 engelska. Man kan l=E6gga upp en kunskapsprofil och d=E6r finns RDF faktiskt med. Och= s=E5 kan man s=E6tta ut ett antal jobb som beh=F8ver g=F8ras. S=E5 vi har tre s=E6tt att s=E6tta upp vad som ska g=F8ras: 1. Registrera saken som en bugg 2. Anv=E6nda psojekt/task manager (l=E5ter rimligt. :) 3. Registrera saken som ett support=E6rende 4. L=E6gga upp det som en jobb-beskrivning 5. Skapa en tr=E5d om det i ett diskussionsforum Ok. No 2 l=E5ter okej. =20 S=E5: ska vi ha mailinglista och/eller diskussionsgrupper? --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 20:18:11 2000 Date: Wed, 9 Aug 2000 21:18:11 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: joina projektet On Wed, 9 Aug 2000, Christian Stamgren wrote: > -----BEGIN PGP SIGNED MESSAGE----- >=20 > Jag tycker nog det =E4r b=E4ttre med en mailinglista d=E5 f=E5r man ju li= ksom alltid > mailen med ett forum =E4r det l=E4tt att man inte tittar din lika ofta... >=20 > det =E4t nog b=E4ttre med en maillista tills projektet =E4r i full fart .= =2E Ok. Du kan iofs f=E5 mail varje g=E5ng det kommit ett nytt msg, med l=E6nk till sidan. Men jag h=E5ller med. Jag s=E6tter upp en maillista p=E5 Sourceforge och st=E6nger denna lista n= =E6r Stefan kommit med och n=E6r vi flyttat =F8ver allt av intresse till dokumentation, etc. Jag s=E6tter upp lite olika underprojekt nu. Blir 2 till att b=F8rja med. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 21:02:55 2000 Date: Wed, 9 Aug 2000 22:02:55 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Wraf mailing lists Mailing lists att SF will have the form wraf-...@lists.sourceforge.net ... will be the specific list. I could think of names such as "announce", "devel" and "users". But maby it would be better to keep this list for now? Or create the list wraf@uxn.nu instead? Created SF lists can never be deleted. I say we keep this list for now. (SF uses Mailman too...) The home page should refere to the development mailing list. I can think of two more taskmanager groups: * Public Relations * Release 0.01 I have looked at other groupings. The most common use is to create one task list for each release. V0.01 would be ouer release goal. When we have decided on this, I could start listing the things to do. We want to convey our vision of the project and describe what it could do better. That is somthing diffrent from documentation management. Website management would go in the PR group. The two existing groups: - Documentation - General These two grops has some tasks now. You can create new tasks and/or take on unasigned tasks. I wait for a response from modules@cpan.org. It will determine if the library module will be named RDF, RDF::Wraf or maby XML::RDF::Wraf. I will initiate the CVS then this is settled. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Wed Aug 9 21:53:15 2000 Date: Wed, 9 Aug 2000 22:53:15 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Source forge On Wed, 9 Aug 2000, Stefan Andersson wrote: > > S=E5 nu =E6r det dags att registrera er: > > Och d=E6refter hoppa in p=E5 projektsidan: >=20 > Fixat! L=E4gger du till 'steand' i projektet, Jonas? Klart. > > Ska vi g=E5r =F8ver till webbforum (man kan bevaka tr=E5darna) eller = =F8ppna en > > mailinglista p=E5 sourceforge eller beh=E5lla denna listan? >=20 > Bra och sv=E5r fr=E5ga. Vi kan ju beh=E5lla den h=E4r listan, avvakta och= se vad > som h=E4nder? Det =E4r iofs sk=F6nt att ha allt p=E5 ett st=E4lle (SF) =C6ven webbplatsen? S=E5g att de bara har mysql som databas. S=E5 jag vill nog ha kvar webbplat= sen p=E5 www.uxn.nu, s=E5 att jag kan s=E6tta upp en riktig demo, etc. Men vi skulle kunna ha en mailinglista. Hehe. Vi =E6t tre stycken. Ska jag s=E6tta upp en omr=F8stning? ;-) > > I vilket fall kommer all utveckling och framtida listtrafik vara p=E5 > > engelska. >=20 > Alright, then... Yezz man!! :-] > > Man kan l=E6gga upp en kunskapsprofil och d=E6r finns RDF faktiskt med.= Och s=E5 > > kan man s=E6tta ut ett antal jobb som beh=F8ver g=F8ras. >=20 > Damn! Gotta do it right away! :-) > > 1. Registrera saken som en bugg > >=20 > > 2. Anv=E6nda psojekt/task manager (l=E5ter rimligt. :) > >=20 > > 3. Registrera saken som ett support=E6rende > >=20 > > 4. L=E6gga upp det som en jobb-beskrivning > >=20 > > 5. Skapa en tr=E5d om det i ett diskussionsforum > >=20 > > Ok. No 2 l=E5ter okej. > >=20 > > S=E5: ska vi ha mailinglista och/eller diskussionsgrupper? >=20 > Both? It's really two different metaphors. But discussion groups tend to > die if there isn't a lot of traffic, which I think we're not going to > have for starters. Mailinglists, then. >=20 > Btw - welcome Christian! Nice to have you aboard! > (Jonas: should we invite some more ppl when we've gotten a bit more docs > up?) Yes. The first thing I want to do is to use the project manager tool to list all the things TODO and give them a priority, etc. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Thu Aug 10 08:18:47 2000 Date: Thu, 10 Aug 2000 09:18:47 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] Source forge Is there anybody else that has big problems loggin in to sourceforge with the mozzilla nightly build. I was forced to download netscape 4.7 to be able to login.. :-( maby there is something with the SSL connection.. Best regards Christian. On Wed, 09 Aug 2000, you wrote: > On Wed, 9 Aug 2000, Stefan Andersson wrote: > > > > Så nu ær det dags att registrera er: > > > Och dærefter hoppa in på projektsidan: > > > > Fixat! Lägger du till 'steand' i projektet, Jonas? > > Klart. > > > > > Ska vi går øver till webbforum (man kan bevaka trådarna) eller øppna en > > > mailinglista på sourceforge eller behålla denna listan? > > > > Bra och svår fråga. Vi kan ju behålla den här listan, avvakta och se vad > > som händer? Det är iofs skönt att ha allt på ett ställe (SF) > > Æven webbplatsen? > > Såg att de bara har mysql som databas. Så jag vill nog ha kvar webbplatsen > på www.uxn.nu, så att jag kan sætta upp en riktig demo, etc. > > Men vi skulle kunna ha en mailinglista. Hehe. Vi æt tre stycken. Ska jag > sætta upp en omrøstning? ;-) > > > > > I vilket fall kommer all utveckling och framtida listtrafik vara på > > > engelska. > > > > Alright, then... > > Yezz man!! :-] > > > > > Man kan lægga upp en kunskapsprofil och dær finns RDF faktiskt med. Och så > > > kan man sætta ut ett antal jobb som behøver gøras. > > > > Damn! Gotta do it right away! > > :-) > > > > > 1. Registrera saken som en bugg > > > > > > 2. Anvænda psojekt/task manager (låter rimligt. :) > > > > > > 3. Registrera saken som ett supportærende > > > > > > 4. Lægga upp det som en jobb-beskrivning > > > > > > 5. Skapa en tråd om det i ett diskussionsforum > > > > > > Ok. No 2 låter okej. > > > > > > Så: ska vi ha mailinglista och/eller diskussionsgrupper? > > > > Both? It's really two different metaphors. But discussion groups tend to > > die if there isn't a lot of traffic, which I think we're not going to > > have for starters. Mailinglists, then. > > > > Btw - welcome Christian! Nice to have you aboard! > > (Jonas: should we invite some more ppl when we've gotten a bit more docs > > up?) > > Yes. The first thing I want to do is to use the project manager tool to > list all the things TODO and give them a priority, etc. > > > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@paranormal.se Thu Aug 10 08:47:12 2000 Date: Thu, 10 Aug 2000 09:47:12 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Source forge On Thu, 10 Aug 2000, Christian Stamgren wrote: > Is there anybody else that has big problems loggin in to sourceforge with > the mozzilla nightly build. > > I was forced to download netscape 4.7 to be able to login.. :-( > maby there is something with the SSL connection.. I still uses Netscape. You have to have SSL. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Thu Aug 10 08:58:22 2000 Date: Thu, 10 Aug 2000 09:58:22 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] Source forge Ahhh so i am the winner after all ;-) On Thu, 10 Aug 2000, you wrote: > On Thu, 10 Aug 2000, Christian Stamgren wrote: > > > OK, i´m beaten,, i Surrender ;^) > > And MS IE 5. :-( Sitting in a clients office now... > > > > On Thu, 10 Aug 2000, Jonas Liljegren wrote: > > > On Thu, 10 Aug 2000, Christian Stamgren wrote: > > > > > > > I was pretty sure that mozilla had SSL by now, maby i was wrong. > > > > > > > > I need to have mozilla to test the XSL/CSS support so guess i have 2 browsers > > > > now ;^) > > > > > > And I also have Amaya and Lynx and The w3 browser... And Links. > > > > > > > > > -- > > > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Thu Aug 10 10:27:57 2000 Date: Thu, 10 Aug 2000 11:27:57 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] Source forge I guess there was no outcome at all ( but it was fun ) ;^) I might as well tell you now that i´m quite new to RDF never worked with it in a live project. But i guess i´ll be able to catchup and be to some assistant anyway. I worked alot with perl and XML so .... My experience with Mozilla is just client side XSL transformations as i want to use it, when teaching XSL to some programmers here at my company (we are starting a project using AxKit for mod_perl) witch by the way 0.98 was released today. I guess that the support in Mozilla ain´t that great yet.. but it will be... by the way have somebody sean a complete tutorial of the XSL support in Mozilla???? later, Christian On Thu, 10 Aug 2000, youwrote: > So what was the outcome of this discussion? > > Btw. Christian: Are you experienced in the inner workings of Mozilla? I > for one is _very_ interested in what could be done client-wise with > WRAF. I.e. using whatever RDF support is built into Mozilla and combine > it with server-side WRAF? > > /Stefan > > > Christian Stamgren wrote: > > > > Ahhh so i am the winner after all ;-) > > > > On Thu, 10 Aug 2000, you wrote: > > > On Thu, 10 Aug 2000, Christian Stamgren wrote: > > > > > > > OK, i´m beaten,, i Surrender ;^) > > > > > > And MS IE 5. :-( Sitting in a clients office now... > > > > > > > > > > On Thu, 10 Aug 2000, Jonas Liljegren wrote: > > > > > On Thu, 10 Aug 2000, Christian Stamgren wrote: > > > > > > > > > > > I was pretty sure that mozilla had SSL by now, maby i was wrong. > > > > > > > > > > > > I need to have mozilla to test the XSL/CSS support so guess i have 2 browsers > > > > > > now ;^) > > > > > > > > > > And I also have Amaya and Lynx and The w3 browser... And Links. > > > > > > > > > > > > > > > -- > > > > > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > > > > > > > > > -- > > > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > > > _______________________________________________ > > RDF mailing list > > RDF@uxn.nu > > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From christian@stamgren.com Thu Aug 10 11:57:27 2000 Date: Thu, 10 Aug 2000 12:57:27 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] Source forge Are you working on framfab right now ??? i´m on WM-data would be fun to now were you guys work ... later , christian On Thu, 10 Aug 2000, Stefan Andersson wrote: > > I guess there was no outcome at all ( but it was fun ) ;^) > > Okay... > > > I might as well tell you now that i´m quite new to RDF never worked with it in > > a live project. > > Then there's two of us... but that's what we're about to change, neh? > > > But i guess i´ll be able to catchup and be to some assistant anyway. > > I worked alot with perl and XML so .... > > I've worked some with Perl, but mostly with MS-centered technologies. I > come from the wonderful world of Content Management and recently worked > as Technical Account Manager on a company called 'framfab'. ;-D > > > My experience with Mozilla is just client side XSL transformations as i want > > to use it, when teaching XSL to some programmers here at my company (we are > > starting a project using AxKit for mod_perl) witch by the way 0.98 was released > > today. > > Actually - I have very little experience in XSL, but I have a notion the > 'Serialisation' Layer (or whatever we finally decide to call it...) > could draw a lot on XSL thinking. > > > I guess that the support in Mozilla ain´t that great yet.. but it will be... > > by the way have somebody sean a complete tutorial of the XSL support in > > Mozilla???? > > Nope. Sorry. > /Stefan From jonas@paranormal.se Thu Aug 10 14:22:22 2000 Date: Thu, 10 Aug 2000 15:22:22 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: RDF Ok. Here is some comments on your points. I have already taken this into consideration while I wrote http://www.uxn.nu/wraf/ On Tue, 8 Aug 2000, Stefan Andersson wrote: > Web Resource Application Framework (WRAF) key features: >=20 > WRAF is primarily designed as a platform for: > =B7 Data-driven web applications with complex class hierarchies and > inter-resource relations, such as metadata repositories, topic > communities and intranets. Resource is an RDF term. I would say inter-object relations. The list of intended uses is a important point for the presentation of Wraf, and shoud be expanded upon. - Metadata repositories (examples?) - Topic communities (what is that exactly?) - Intranets (examples?) We should compile a list of possible uses. I add this task at SF (under Documentation tasks). > =B7 Applications collecting, processing and presenting information from > many sources, distributed over many processes. Or distrebuted over many domains from diffrent organizations. > =B7 Intelligent agents and robots. How intelligent? ;) > =B7 Dynamic content, where the content selection and presentation is a > result of complex dependencies. Yes. Examples would be good. > WRAF offers=20 > =B7 an consistent interface to and between multiple information sources > =B7 the possibility of rich data and metadata modeling through inheritanc= e > =B7 an open, standardized and extensible way of describing and exchanging > resources, inter- as well as intraorganizational. The resource exchange is going to take much work. The goal is that the process will be cumulative. That is: that it will be possible to extend and grow the system without the old definitions becomming a burden. That is at least my vision. > =B7 a framework for RAD (Rapid Application Development) and realtime > system extension through schema remodeling. Yes. > WRAF is built upon Here we go... > =B7 RDF, an open W3C (WWW Consortium) standard for distributed resource > modelling through DLG (Directed Labeled Graphs). Ok. > =B7 RDF-Schema, the W3C standard for schema modelling under RDF RDF-Schema is a candidate recommendation. This means that there is still time for the W3C members to comment on this thing. W3C wan't to see a few real implementations in order to be satisfied with RDFS. > =B7 RDF-XML, the W3C standard for expressing RDF data in XML. This is called the RDF Syntax. > =B7 RDF QDS, an query definition schema modelled in RDF. This is post 1.0 > =B7 RDF SDS - The Serialisation Definition Schema is used to describe > transformations between a RDF DLG and serialized formats, such as > RDF-XML, native XML, [X]HTML, WML, et.c. Ok. I wonder if maby its best to have some sort of template system in combination with SDS? You still want to do some form of layout. Should we realy go for a system like SmartWorks? > =B7 WRAF XML SDS - A base SDS for expressing RDF as XML > =B7 WRAF [X]HTML SDS - A base SDS for expressing RDF resources as [X]HTML This is also two diffrent contexts. Either you wan't to transfer the requested information (XML) or you wan't to present the information. For information presentation, there will be a lot of supporting style and markers and things. I would like to see some more details on this. In any case. SDS is post 1.0 > =B7 RDF DB - An interface for storing and retrieving RDF DLG in relationa= l > databases It's currently named org.cpan.RDF.Interface.DBI.V01 :-) I was trying to think of some global way of naming CPAN modules. Come to think of Java. :-I The name (resource URI) will of course change. > =B7 WRAF API - The core functionality, exposing RDF models and interfaces= =2E Ok. > WRAF IE - The Inference Engine enables applications that do not share > data definitions to identify and bridge RDF Schema incompatibilities. That's new. - I'm planning for alias functionality. In addition to thet: We will have som rule set that can create new statements based on other statements. And the new statements will be dependent on the old. (Publish subscribe..) But that will come later. (After 1.0) > Currently, all functionality is implemented as an UNIX service deamon > with a cgi/mod_perl client. It will be. :) We prototype worked that way. But there is no reason to start using the deamon before the cache functionality is in place. (Ok. This points was about describing Wraf. I just takeing the opportunity to talk about the development.) > The RDF, RDF-XML and RDF-Schema are open W3C standards. The RDF DB, WRAF > API and WRAF IE are open source as per GNU Public License, and will be > given to CPAN upon completion. The RDF QDS and SDS will be submitted as > standards proposals upon completion. Isn't this a little ambitious? If can find financial support, I bet that Meta Matrix would like to help out here. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Thu Aug 10 16:15:11 2000 Date: Thu, 10 Aug 2000 17:15:11 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] ssh-account att SF I have tested to log in at Sourceforge. It seems that all the users (or at least many of them: 11513) is on the same catalog in the /home/users dir. And all the projects are in the /home/groups dir. And this is our group line in the /etc/group file: wraf:x:10479:aigan,bhazer,steand I think that this is a wery nice integration betwen the web interface and the shell. The SF page is up. http://wraf.sourceforge.net/default_page.php We could shange the page to point to http://www.uxn.nu/wraf/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Fri Aug 11 09:39:31 2000 Date: Fri, 11 Aug 2000 10:39:31 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] RDF modules Hi! I (Jonas Liljegren) and Stefan Andersson has under some time planned discussed and prototyped RDF programs in Perl. I have activly participated in the RDF Intrest Group and have a demo for a prototype I constructed a year ago: http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ The project is called Wraf, and has a page at http://www.uxn.nu/wraf/ and a place at SourceForge: http://sourceforge.net/projects/wraf/ The goals can seem very ambitious. But I'm also a very dedicated for this. And the modules will be useful even with only the basic functionality. I recently made a progress report (distributed mainly to the RDF list): http://www.uxn.nu/wraf/presentation/status.txt I have two reson for writing to you: 1. We (the community) have to decide on a name for the library. I wrote to modules@cpan.org two days ago and havn't got an answer yet. I would like this to be the main RDF module and call it just RDF, because it's built to be extended with new functionality. For example with RDF::Interface::LDAP or RDF::Interface::XML or anything else. Instead of calling the module RDF, it could be called RDF::Wraf. But I would like just RDF better. Many modules is now located in the XML:: space. The Wraf RDF library doesn't have anything specificaly to do with XML. It's built on the RDF data model with interfaces to diffrent storage systems. One of them will be the XML serialization syntax. But the primary storage is a relational database. That's why I don't think that this module belongs in the XML:: namespace. I'm waiting for the final name before I can initiate the CVS archive at SourceForge. (The existing code can be found at http://www.uxn.nu/wraf/src/ ) 2. It would be nice with some publicity. I haven't been active on any XML mailing lists because I'm using DBI rather than plain text files. But there may be some intrest at some lists. I couldn't find any links on the perlxml.com page... Could you recommend any lists/groups/pages? -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Fri Aug 11 10:13:30 2000 Date: Fri, 11 Aug 2000 11:13:30 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] RDF modules ----- Original Message -----=20 From: "Jonas Liljegren" To: Cc: Sent: Friday, August 11, 2000 10:39 AM Subject: [RDF] RDF modules > Hi! >=20 >=20 > I (Jonas Liljegren) and Stefan Andersson has under some time planned > discussed and prototyped RDF programs in Perl. >=20 > I have activly participated in the RDF Intrest Group and have a demo = for a > prototype I constructed a year ago: > http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ >=20 >=20 > The project is called Wraf, and has a page at http://www.uxn.nu/wraf/ = and > a place at SourceForge:=20 > http://sourceforge.net/projects/wraf/ >=20 > The goals can seem very ambitious. But I'm also a very dedicated for > this. And the modules will be useful even with only the basic > functionality. >=20 > I recently made a progress report (distributed mainly to the RDF = list): > http://www.uxn.nu/wraf/presentation/status.txt >=20 >=20 >=20 > I have two reson for writing to you: >=20 >=20 > 1. We (the community) have to decide on a name for the library. =20 >=20 > I wrote to modules@cpan.org two days ago and havn't got an answer yet. = I > would like this to be the main RDF module and call it just RDF, = because > it's built to be extended with new functionality. For example with > RDF::Interface::LDAP or RDF::Interface::XML or anything else. Instead > of calling the module RDF, it could be called RDF::Wraf. But I would = like > just RDF better. >=20 > Many modules is now located in the XML:: space. The Wraf RDF library > doesn't have anything specificaly to do with XML. It's built on the = RDF > data model with interfaces to diffrent storage systems. One of them = will > be the XML serialization syntax. But the primary storage is a = relational > database. That's why I don't think that this module belongs in the > XML:: namespace. >=20 > I'm waiting for the final name before I can initiate the CVS archive = at > SourceForge. (The existing code can be found at=20 > http://www.uxn.nu/wraf/src/ ) >=20 >=20 > 2. It would be nice with some publicity. >=20 > I haven't been active on any XML mailing lists because I'm using DBI > rather than plain text files. But there may be some intrest at some > lists. I couldn't find any links on the perlxml.com page... Could you > recommend any lists/groups/pages? I would recommend the perl xml mailing list hosted by Activestate.. >=20 >=20 > --=20 > / Jonas - http://jonas.liljegren.org/myself/en/index.html Christian Stamgren.. >=20 >=20 > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@paranormal.se Fri Aug 11 11:53:37 2000 Date: Fri, 11 Aug 2000 12:53:37 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] xmlns, uri+name pairs or just uris..? Clarification needed. Wouldn't it make it easier to make a clear rule for this? The convention could be: 1. The RDF Resource (NOT all URIs) can always be separated into the 'model' and the 'name'. 2. The name part will be the part after the last of a demarcation character. In order, look for '#', '/', ':' and ''. (Is the empty URI legal?) 3. The model will be the first part of the string including the demarcation model. 4. The model represents a collection of statements from the authority owning that part of the URI space. 5. Official statements about the URI will either be included in this model or referenced from it (ie seeAlso). 6. If the URI is a property or a class, the model will include a schema or refere to a schema, defining this resource. 7. Other models can extend a schema or say anything they like about a resource. 8. The model may be retrivable, as specified by the protocol, but doesn't have to be. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Sun Aug 13 14:16:43 2000 Date: Sun, 13 Aug 2000 15:16:43 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Module changes * The previous version (0.22) was a mix of normal OO and the resource-objects. I have now restructured the module to throw away the last of the classic OO and solved more of the cyclic dependencies problems. All objects are now just Resource objects. The methods for the subtypes, like literals, models, interfaces, statements, etc, will be handled by the jumptable for the Base interface. * Since what you get at the first call is a Service resource, I found it natural to rename the Module RDF::Service. I think this settles the naming issue. * I had to think about just how to create a new resource. Put the thoughts as a new document at SF. :-) http://sourceforge.net/docman/display_doc.php?docid=418&group_id=9479 The CVS will be up within two weaks. I have four weeks left with the current asignment. After that it will be Wraf full time. :-) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Mon Aug 14 14:44:40 2000 Date: Mon, 14 Aug 2000 15:44:40 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] rdfdb someone... This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C00606.8EC54FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello fellow project members,, in my struggle to learn as much as posssible of RDF in a short time I = have come across the=20 RDFDB but not that much info about it. This project is a RDF project so I figure somebody maby would now = something about this database. I=B4m looking for any kind of documentation. Best regards=20 Christian Stamgren. ------=_NextPart_000_00CD_01C00606.8EC54FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello = fellow project members,,
in my struggle to learn as much as posssible of RDF = in a short=20 time I have come across the
RDFDB but not that much info about it.
 
This project is a RDF project so I figure somebody = maby would=20 now something about this database.
 
I=B4m looking for any kind of = documentation.
 
Best regards
 
Christian Stamgren.
------=_NextPart_000_00CD_01C00606.8EC54FC0-- From stefan@c64.org Mon Aug 14 15:14:41 2000 Date: Mon, 14 Aug 2000 16:14:41 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] rdfdb someone... Yo! RDFBD is Erics (I don't remember his last name) implementation of an RDF Perl API and interface to storing and retrieving RDF in a relational database. Take a look at: http://dev.w3.org/cvsweb/~checkout~/perl/modules/W3C/Rdf/RdfDB.html Have you looked at the WRAF Resource link list? http://www.uxn.nu/wraf/links.html (There's a lot of swedish texts as well as english) Cheers! /Stefan > Christian Stamgren wrote: >=20 > Hello fellow project members,, > in my struggle to learn as much as posssible of RDF in a short time I > have come across the > RDFDB but not that much info about it. >=20 > This project is a RDF project so I figure somebody maby would now > something about this database. >=20 > I=B4m looking for any kind of documentation. >=20 > Best regards >=20 > Christian Stamgren. From jonas@paranormal.se Tue Aug 15 07:58:28 2000 Date: Tue, 15 Aug 2000 08:58:28 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] rdfdb Hmm. Tis was not Erics Perl module. This is something else. http://www.guha.com/rdfdb/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Tue Aug 15 08:46:23 2000 Date: Tue, 15 Aug 2000 09:46:23 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] rdfdb YES,, this was what i was looking for ..... anybody worked or looked at this database.. Christian ----- Original Message -----=20 From: "Jonas Liljegren" To: Sent: Tuesday, August 15, 2000 8:58 AM Subject: [RDF] rdfdb > Hmm. Tis was not Erics Perl module. This is something else. >=20 > http://www.guha.com/rdfdb/ >=20 >=20 > --=20 > / Jonas - http://jonas.liljegren.org/myself/en/index.html >=20 >=20 > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@paranormal.se Tue Aug 15 09:00:15 2000 Date: Tue, 15 Aug 2000 10:00:15 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Metamatrix Greg FitzPatrick wrot to me today about another meeting. :-) He is the head researcher at Metamatrix http://www.metamatrix.se/ Just want to forward the bit I wrote abut Wraf: What we will build is something that can be used for all types of web applications. Whatever it is you would like us to do, we can do it with Wraf. - It's a server deamon taking care of client requests - We will develop a web-based user interface, but any type of interface ca be used. Especially for automatic agents. - It's not the fastest way to do things, but we will make sure it's fast enough. - This is for the sake of the Semantic Web. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 15 09:06:54 2000 Date: Tue, 15 Aug 2000 10:06:54 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] rdfdb On Tue, 15 Aug 2000, Christian Stamgren wrote: > anybody worked or looked at this database.. Not me. Wraf is intended to do much more than rdfdb. And especially, we want to do the DB connection much more efficient. > ----- Original Message ----- > From: "Jonas Liljegren" > To: > Sent: Tuesday, August 15, 2000 8:58 AM > Subject: [RDF] rdfdb > > > > Hmm. Tis was not Erics Perl module. This is something else. > > > > http://www.guha.com/rdfdb/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From christian@stamgren.com Tue Aug 15 09:23:02 2000 Date: Tue, 15 Aug 2000 10:23:02 +0200 From: Christian Stamgren christian@stamgren.com Subject: [RDF] rdfdb Great becouse i really liked the ide=B4=20 so i guess i=B4m going to like wraf even more then ;^) By the way,, how many of us live in GBG how about a meting face to face = i=B4m might be movin to STHLM sone .... Christian. ----- Original Message -----=20 From: "Jonas Liljegren" To: "Christian Stamgren" Cc: Sent: Tuesday, August 15, 2000 10:06 AM Subject: Re: [RDF] rdfdb > On Tue, 15 Aug 2000, Christian Stamgren wrote: >=20 > > anybody worked or looked at this database.. >=20 > Not me. >=20 >=20 > Wraf is intended to do much more than rdfdb. And especially, we want = to do > the DB connection much more efficient. >=20 >=20 > > ----- Original Message -----=20 > > From: "Jonas Liljegren" > > To: > > Sent: Tuesday, August 15, 2000 8:58 AM > > Subject: [RDF] rdfdb > >=20 > >=20 > > > Hmm. Tis was not Erics Perl module. This is something else. > > >=20 > > > http://www.guha.com/rdfdb/ >=20 > --=20 > / Jonas - http://jonas.liljegren.org/myself/en/index.html >=20 From stefan@c64.org Tue Aug 15 10:35:14 2000 Date: Tue, 15 Aug 2000 11:35:14 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] rdfdb Ah, now I've looked into it, too. Actually, there are a couple of implementations of the 'How to store and retrieve triples'-problem, more or less efficient and flexible. There's also a couple of implementations of 'how to query RDF[S]' - but WRAF is the only one, as far as I have seen, that is trying to take a wider stand - by making an application platform for RDF[S]. I should mention right away that Jonas and me have slightly different ambitions when it comes to WRAF. Jonas is more interested in the metadata processing and cross-linking aspects. Myself, I am a bit more concerned with the presentation/serialization aspects a.k.a. 'content'. (The things Jonas won't let me call Serialization Description Schemas...) :-) But Christian raised an issue. We should not call our interface to relational databases 'RDFDB', not in coding, and not in presenting it. /Stefan Jonas Liljegren wrote: > > On Tue, 15 Aug 2000, Christian Stamgren wrote: > > > anybody worked or looked at this database.. > > Not me. > > Wraf is intended to do much more than rdfdb. And especially, we want to do > the DB connection much more efficient. > > > ----- Original Message ----- > > From: "Jonas Liljegren" > > To: > > Sent: Tuesday, August 15, 2000 8:58 AM > > Subject: [RDF] rdfdb > > > > > > > Hmm. Tis was not Erics Perl module. This is something else. > > > > > > http://www.guha.com/rdfdb/ > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@paranormal.se Tue Aug 15 10:59:00 2000 Date: Tue, 15 Aug 2000 11:59:00 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] rdfdb On Tue, 15 Aug 2000, Stefan Andersson wrote: > I should mention right away that Jonas and me have slightly different > ambitions when it comes to WRAF. Jonas is more interested in the > metadata processing and cross-linking aspects. Myself, I am a bit more > concerned with the presentation/serialization aspects a.k.a. 'content'. I think of the SDS as the next step, after we got the engine working. But the enginge shoule definitly be ready for SDS. And I don't think it's to early to start thinking about SDS. But I would love to use Wraf for many things even without the SDS interface. > (The things Jonas won't let me call Serialization Description > Schemas...) :-) I made a more detaild response later. The reaction was mostly of the presentation of SDS. > But Christian raised an issue. We should not call our interface to > relational databases 'RDFDB', not in coding, and not in presenting it. That's like not calling PostgreSQL an SQL server, because M$ choose bold names. I call the present module for the RDF::Service::Interface::DBI::V01 We could easily add a RDF::Service::Interface::RDFDB::V01 as an interface for the RDFDB. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Tue Aug 15 12:09:12 2000 Date: Tue, 15 Aug 2000 13:09:12 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Some linx I don't know if you've seen this, but... vCard 3.0 as RDF http://www.dstc.edu.au/Research/Projects/rdf/draft-iannella-vcard-rdf-00.txt (Jonas, didn't you do something like this?) Mozillas RDF resources http://www.mozilla.org/rdf/doc/ (This is why I want us to get onto the Mozilla waggon as well...) /Stefan From jonas@paranormal.se Tue Aug 15 12:23:50 2000 Date: Tue, 15 Aug 2000 13:23:50 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Some linx On Tue, 15 Aug 2000, Stefan Andersson wrote: > vCard 3.0 as RDF > http://www.dstc.edu.au/Research/Projects/rdf/draft-iannella-vcard-rdf-00.txt > (Jonas, didn't you do something like this?) I demonstrated how a RDF version of iCal could look like. But didn't continue with that. We want to have a collection of standard schemas to build on. It would be a good test for compability to have two overlapping schams and have them work together. Especially if they uses diffrent structures and not only diffrent names. We should continue collecting links for things intresting for the goals of the Wraf projeect. I have set up three tasks in the Documentation group at SF. Feel free to sign up for one of them. (Source Forge completly changed look a couple of days agoo...) http://sourceforge.net/pm/task.php?group_project_id=3499&group_id=9479&func=browse -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Tue Aug 15 13:24:16 2000 Date: Tue, 15 Aug 2000 14:24:16 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] rdfdb On Tue, 15 Aug 2000, Christian Stamgren wrote: > Shure thing but i don=B4t think that we should reinvent the wheel if we d= on=B4t have to ......... > i think that it=B4s right to use tool that are allready developed. You would still have to do all the other things. What RDFDB gives: * import/unimport RDF xml-files * insert/delete triples * a basic query language What RDFDB misses: * It does not bind statements to models * It does not make the 'fact' shortcut for reified statements * No alias mechanism * No container optimization * No support for uri prefixes * No support for blobs * No URI asignment for statement * No RDFS methods * No checking of duplicate statements The experience with the RDF Schema editor http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ made us want to optimize for the most common case. That is: the realy heavy use of types and subClassOf and the constant use of label in the development enviroment. It does make it easy to import RDF data and to make queries. But it will not be a good place to store the bulk of the data from Wraf. So: I would like to have an interface to RDFDB. It may be a little easier to do some queries. But it doesn't cut back on the work we have to do. RDFDB is too limited to be used as the main storage interface. It should only be used with simple static data. --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Tue Aug 15 14:37:13 2000 Date: Tue, 15 Aug 2000 15:37:13 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] rdfdb This text is actually something of a statement. Maybe we ought to compile a mini-FAQ on a page somewhere 'why WRAF instead of NN'? /Stefan > What RDFDB gives: > * import/unimport RDF xml-files > * insert/delete triples > * a basic query language > > What RDFDB misses: > * It does not bind statements to models > * It does not make the 'fact' shortcut for reified statements > * No alias mechanism > * No container optimization > * No support for uri prefixes > * No support for blobs > * No URI asignment for statement > * No RDFS methods > * No checking of duplicate statements > > The experience with the RDF Schema editor > http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ made us want to > optimize for the most common case. That is: the realy heavy use of types > and subClassOf and the constant use of label in the development > enviroment. > > It does make it easy to import RDF data and to make queries. But it will > not be a good place to store the bulk of the data from Wraf. > > So: I would like to have an interface to RDFDB. It may be a little easier > to do some queries. But it doesn't cut back on the work we have to > do. RDFDB is too limited to be used as the main storage interface. It > should only be used with simple static data. From stefan@c64.org Tue Aug 15 15:48:10 2000 Date: Tue, 15 Aug 2000 16:48:10 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Re: RDF > > Web Resource Application Framework (WRAF) key features: > > > > WRAF is primarily designed as a platform for: > > =B7 Data-driven web applications with complex class hierarchies and > > inter-resource relations, such as metadata repositories, topic > > communities and intranets. >=20 > Resource is an RDF term. I would say inter-object relations. Ahh, but I was trying to make a point - we're not really dealing with 'objects' as commonly understood, right? We're dealing with 'whatchamacallits', right? Hence 'resources'. I'd say the terms 'object' and 'resource' are not interchangeable. > - Metadata repositories (examples?) Yahoo. DMOZ. Directory servers. Data about things. The 'repository' bit is to emphasize the distributed nature of it. > - Topic communities (what is that exactly?) Paranormal. Every other community centered around a topic. I.e. every other community. > - Intranets (examples?) Whoa! Employee data, project data, supplier/customer/client data, documentation, administrative data. Everything cross-linked. > We should compile a list of possible uses. I add this task at SF (unde= r > Documentation tasks). Right! =20 > > =B7 Applications collecting, processing and presenting information fr= om > > many sources, distributed over many processes. >=20 > Or distrebuted over many domains from diffrent organizations. Yes. Domains, organizations and processes. What a fine mess we're cooking. ;-D =20 > > =B7 Intelligent agents and robots. >=20 > How intelligent? ;) Not-very at the moment, of course, but just maybe smart enough to get some real work done... and I'm still convinced, as is the Mozilla-RDF-folks, that a generic inferencing mechanism on the client side, coupled with a flexible presentation/UI layer, would be a _good_ thing. > > =B7 Dynamic content, where the content selection and presentation is = a > > result of complex dependencies. >=20 > Yes. Examples would be good. one2one is somewhat outdated, but personalization (preference by tracking), collaborative filtering (if I like A and B, and you like A, maybe you like B too), content screening (no filthy language for me), target media (WAP sucks, gimme broadband!), skins (I always wanted a more sci-fi-look to my Yahoo), preferences (language, search results per screen) and community trust relationships (ePinions) are some others. =20 > > WRAF offers > > =B7 an consistent interface to and between multiple information sourc= es > > =B7 the possibility of rich data and metadata modeling through inheri= tance > > =B7 an open, standardized and extensible way of describing and exchan= ging > > resources, inter- as well as intraorganizational. >=20 > The resource exchange is going to take much work. The goal is that the > process will be cumulative. That is: that it will be possible to extend > and grow the system without the old definitions becomming a burden. Th= at > is at least my vision. Of course. This text was somewhat meant as 'hoopla' - what we're aiming at, not what we have at the moment! > > WRAF is built upon >=20 > Here we go... ... again, here we go, go, go, to the temple of consumption... > > =B7 RDF-Schema, the W3C standard for schema modelling under RDF >=20 > RDF-Schema is a candidate recommendation. This means that there is stil= l > time for the W3C members to comment on this thing. W3C wan't to see a f= ew > real implementations in order to be satisfied with RDFS. Lets give it to them, then, shall we? ;-D =20 > > =B7 RDF-XML, the W3C standard for expressing RDF data in XML. >=20 > This is called the RDF Syntax. I know, but I thought having 'XML' somewhere in it would look good. =20 > > =B7 RDF QDS, an query definition schema modelled in RDF. >=20 > This is post 1.0 Actually, I see it as more of parallell endeavours. A QDS can be designed outside of WRAF. Although, QDS is probably some way away. Mind you, we will pretty quick need some way of describing subsets of models. =20 > > =B7 RDF SDS - The Serialisation Definition Schema is used to describe > > transformations between a RDF DLG and serialized formats, such as > > RDF-XML, native XML, [X]HTML, WML, et.c. >=20 > Ok. I wonder if maby its best to have some sort of template system in > combination with SDS? You still want to do some form of layout. Actually - I think it's pretty much up to the implementers. I think we will probably have both. But I still feel a SDS is the coolest way to go. Probably the slowest, most inefficient as well. Oh, well. > Should we realy go for a system like SmartWorks? Well, the same applies here. Some people will write apps using the RDF classes. Some may even do a SmartWorker-type inheritance-style app framework. Me, I have a vision of code-less systems development. The user just describes his reality and his needs, and the system is smart enough to give him a place to store his reality, present it (to himself and others) and combine it with other peoples views on reality. That is actually what I think that more than 50% of applications do anyway, and probably more than 75% of web applications... =20 > > =B7 WRAF XML SDS - A base SDS for expressing RDF as XML > > =B7 WRAF [X]HTML SDS - A base SDS for expressing RDF resources as [X]= HTML >=20 > This is also two diffrent contexts. Either you wan't to transfer the > requested information (XML) or you wan't to present the information. I don't see this as two different contexts. To transfer, you'll have to present. The 'present' you're thinking of is when information is to be 'transferred' to a human mind. > For > information presentation, there will be a lot of supporting style and > markers and things. Yup. Hence 'Serialization Description Schema'. I see RDF-Syntax as one SDS. =20 > I would like to see some more details on this. >=20 > In any case. SDS is post 1.0 The same applies to this as to QDS. And, because I'm the one bitchin' about both SDS and QDS, it'll probably happen post 'Stefan-getting-the-thumb-out'. =20 > > WRAF IE - The Inference Engine enables applications that do not share > > data definitions to identify and bridge RDF Schema incompatibilities. >=20 > That's new.=20 Yeah. But not really. We've discussed it. I just thought I'd put it up there with all the other visions. This is something we could start discussing. 'Rules of inference'. Sounds lika a DS9 episode... > > Currently, all functionality is implemented as an UNIX service deamon > > with a cgi/mod_perl client. >=20 > It will be. :) We prototype worked that way. But there is no reason to > start using the deamon before the cache functionality is in place. But it sounds nice... ;-D =20 > > The RDF, RDF-XML and RDF-Schema are open W3C standards. The RDF DB, W= RAF > > API and WRAF IE are open source as per GNU Public License, and will b= e > > given to CPAN upon completion. The RDF QDS and SDS will be submitted = as > > standards proposals upon completion. >=20 > Isn't this a little ambitious? I thought this WAS an ambitious venture? I really think that if we succeed in creating sound, working, schemas, we should submit them. If they're not accepted, at least we created the hoopla, so somebody else would be inspired to make it happen. > If can find financial support, I bet that Meta Matrix would like to hel= p > out here. Any witch way is up. Take care, /Stefan From stefan@c64.org Tue Aug 15 18:42:43 2000 Date: Tue, 15 Aug 2000 19:42:43 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] w3c.org/RDF Damn! You sign off the list for a few months and suddenly the world explodes! Got some catching up to do, neh? /Stefan From stefan@c64.org Tue Aug 15 19:35:35 2000 Date: Tue, 15 Aug 2000 20:35:35 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Some 'competitors' and 'partners' Yo ppl! http://www.zope.org Complete (?) application platform built upon DTML-templates and an object storage. (Looking into it right now...) http://nestroy.wi-inf.uni-essen.de/xwmf/ RDF-Syntax-parser, Query Retrieval http://www.guha.com/rdfdb/ RDF-Syntax-parser, Storage, Query Retrieval There's a lot of RDF Schemas popping up, as well as services exposing [meta-]data as RDF Syntax, I think we ought to a) collect them into a resource overview for future test reference b) start working on the RDF Syntax interface as soon as possible... Yet another task in the task list? Ja ne! /Stefan From stefan@c64.org Tue Aug 15 21:58:34 2000 Date: Tue, 15 Aug 2000 22:58:34 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] SDS - the basic idea Yo! I'll try to get the whole SDS thing started softly by explaining the main concepts. There is another document, in swedish, with a slightly different angle, but not that much juicier. This will suffice. For now. Abstract: Serialization Description Schemas are meant to be a generalized way of describing serializations of primarily text, but also binary data. Justification: By describing serialization in a RDF-based way, a party can serialize it's output suitable for another party without any development efforts. A schema approach featuring inheritance also makes it possible to construct an object representation 'on-the-fly', without development efforts. Added benefits also comes from the possibility of a third party synthesizing serialization schemas contructing compromises between different serialisation demands - as for example a combination of personalization, target medias (HTML/WAP, Slow connection, Browser version et.c.) and multiple sources. Other efforts: I have not looked deeply into what have been done in terms of for example XPointers, and although it's text-oriented, not DLG-oriented, there surely must be some concepts worth considering. The same goes for XSL and CSS. Requirements: * The SDS should consist of as few operators as possible. This is because implementation should be easy. * The SDS should consist of 'levels of complexity' This is to accomplish the Perl mantra 'easy things...' * The SDS should embrace RDF Schema as base schema. Because the definition should be as inference-friendly as RDF Schema itself. * The SDS should be property-centric. * The SDS should work in a many-to-many context - a resource could use any SDS, and a SDS could apply to any resource. This implies some sort of selection mechanism based on 'context'. * The SDS should support inheritance, substitution and overloading. Schemas should be able to override underlying schema definitions. This also implies some sort of model prioritizing. This prioritizing could be the base for content negotiation. * An SDS should be able to work both as 'master' and 'slave' That is, be both accessible as an object in itself, deducing necessary data resources, and be able to serialize a given object. * The SDS should, as far as possible, be modeled upon existing Schema extensions. Careful inventory and re-examination underways is key. * The SDS should be modelled as a one-way hierarchy. Unbreaking loops should not be possible to construct. * Your requirement here Notes: * Caching is crucial. Hence WRAF. * As far as I know, there is no way in RDF Schema to describe parallell class hierarchy 'leaps', that is, to describe that if a serialization definition of a 'person' includes a 'name', it should be that resources 'name'. Wheter this should mean the _attribute_ 'name' of the resource or the attributes of _type_ 'name' is an unresolved issue. Most probably this is up to exactly what the resource pointer points to, a Class or an attribute... Actually, this Basic koncepts: * A 'Serialization model', the definitions that implements a certain serialization context. F.ex. 'XHTML' would be a serialization model describing how to present base objects in XHTML. 'Stefans web preferences' would be a serialization model describing how I want my webpages to look. * 'Context' a node definiting a certain selection critera. * 'Ennullment' - if no child attribute exists, it should not be rendered. This solves the most basic logic operation: Exclusion. A extremely simple draft: One of the simplest examples I can come up with, is describing a serialization as a collection of collections: Stefan -- type --> Person SerDef -- subClassOf --> Class asHTML -- type --> SerDef Stefan -- serializedAs --> PersonAsHTML PersonAsHTML -- subClassOf --> asHTML PersonAsHTML -- appliesTo --> Person PersonAsHTML -- context --> HTML PersonAsHTML -- type --> #Seq PersonAsHTML -- _1 --> { photo } // This is the 'leap' i talk about. PersonAsHTML -- _2 --> { name } // This too. Something like that. /Stefan From stefan@c64.org Tue Aug 15 22:17:32 2000 Date: Tue, 15 Aug 2000 23:17:32 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Simple Object Access Protocol, anyone? On popular demand: Jonas, how difficult would it be to do the following in the fanatically flexible 'Practical Extraction and Reporting Language'? a) Wrapping STDOUT and the return-value of a process initiated thru CGI in a bit more STDOUT on the form: {return-value} {STDOUT output} b) Chaining a function call to an URL, so all the calls to funktion(param1, param2) results in: - an POST access to the chained URL:en with the following content: {param1} {param2} and taking the result as of a) above, returning it as the function result. c) Making an function in a CGI-script compatible with a) and b) Everything of course seamless, preferrably defining a function with something like 'sub funktion REMOTE (url)', to chain it to the URL, and 'USE Wraf::Remote' in the CGI-Script. Optionally - an packet#function - construct to collect multiple functions in a simgle file. Catch my drift? /Stefan From stefan@c64.org Wed Aug 16 07:03:03 2000 Date: Wed, 16 Aug 2000 08:03:03 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Model vs. Session/Context Hi all! I just realized (maybe yesterdays news) that the koncept of Session/Context maps neatly onto the koncept of 'model space', that is: In WRAF you (if I'm not mistaken...) activate different interfaces and models, and construct a super-model consisting of all the models relevant to the application? (Should there be a base model consisting of a list of all the available interfaces?) Now, this could work as a context delimiter - you only activate those models that are relevant to the current CONTEXT. Context/Session then could work as a list of the models relevant to the context. After thinking of this, I realized this: What happens if a class definition references objects in a model not activated? Or vice versa - if an objects class definition resides in a non-activated model? But of course, this is a known problem in RDF - what to do if an Schema Resource is non-existential... Cheers, /Stefan From jonas@paranormal.se Wed Aug 16 09:08:23 2000 Date: Wed, 16 Aug 2000 10:08:23 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] SDS - the basic idea On Tue, 15 Aug 2000, Stefan Andersson wrote: > I'll try to get the whole SDS thing started softly by explaining the > main concepts. Ok. I would like to look at it from the other direction: Take a couple of test cases and see what has to be done to create them. Speculate, at large, on the rendering mechanism for some pages. We have to think about things like presentation hierarchy (for encapsulment, not content), navigation objects, status indicators and flexibility of placement/layout. Lets take a couple of pages, and explain how they would be constructed with SDS: 1. http://www.uxn.nu/wraf/ 2. http://www.useit.com/about/nographics.html 3. http://www.debian.org/ 4. http://www.cnn.com/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Wed Aug 16 19:51:45 2000 Date: Wed, 16 Aug 2000 20:51:45 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Little bits of thinkering... Yo, ppl! I'm reading about MS new OO language C# (C-sharp) on: http://msdn.microsoft.com/msdnmag/nettop.asp The language is pitched as a 'Java killer', aiming for most of the nifty features that made Java cool. It's just about as 'keep it simple and useful' as I have come to expect MS to be... ( Hi Jonas! ;-d ) Anyway. I thought I'd relate some of the things to WRAF... #1: C# is using function namespaces, by using the statement 'using ns' you 'load' namespace (module) ns, and so gain access to all the functions in it. Pure WRAF. (It also have a 'aliasing' method to avoid namespace collisions... wuzzies) #2: There is no file boundary any more. All programs are classes, which means a file can hold more than one program. Remember my package#function thought yesterday? WRAF me, baby! #3: It is totally COM+ integrated, wich means all different levels of MS-compatible object technologies can access each other seamlessly - operating system, server, client, script and dll. And with SOAP, method invocations goes thru firewalls as well... yummy! And WRAFfy! #4: Did I tell you about the 'parallell failure channel' I thought of some years ago? I think every language should have an 'error stack' you could put all the messages, non-critical failures, critical failures and breaks in, so that when a process finally stops, you have a complete failure log stack. Of course this would consist of diagnostic data and plain text messages as well as error codes. This way, you could safely assume that the error was reported on the correct level, and brought up the levels... No, it's not in C#, I just came to think about it when I read about C# new error handling, which still is of ye olde 'try/catch' type... and #ifdef DEBUG * shiver of disgust * (The parallell failure channel really should be a feature of the semi-SOAP I'm more and more interested in developing! We really should call it WORF, for Web Object Remote Functions! (Or WRAF Object Remote Functinality...)) Other than that, I think MS has succeeded in making another 'lets semi-script it all together, but in the end script it all' solution... I don't think I'll be using it... Damn! This is getting dangerously close to what I saw in that vision back in '97. Thank God MS obviously haven't seen the data == presentation == logic thing yet, and thought about combining it with recursive self-reference. Gotta move faster, boys! /Stefan From stefan@c64.org Wed Aug 16 20:32:18 2000 Date: Wed, 16 Aug 2000 21:32:18 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Little bits of thinkering... I just felt the urge to comment on myself: > #1: C# is using function namespaces, by using the statement 'using ns' > you 'load' namespace (module) ns, and so gain access to all the > functions in it. Pure WRAF. Also pure Perl, and pure Java, and pure XML, of course. > #2: There is no file boundary any more. All programs are classes, which > means a file can hold more than one program. Remember my > package#function thought yesterday? WRAF me, baby! Also pure Perl, and pure Java, and pure XML, of course. > Other than that, I think MS has succeeded in making another 'lets > semi-script it all together, but in the end script it all' solution... I > don't think I'll be using it... The reactions from the developer community has been, to say the least, mixed. > Gotta move faster, boys! Look who's talking. To himself, even. Kram, /Stefan From jonas@paranormal.se Wed Aug 16 20:32:50 2000 Date: Wed, 16 Aug 2000 21:32:50 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Little bits of thinkering... On Wed, 16 Aug 2000, Stefan Andersson wrote: > I'm reading about MS new OO language C# (C-sharp) on: > http://msdn.microsoft.com/msdnmag/nettop.asp > > The language is pitched as a 'Java killer', aiming for most of the nifty > features that made Java cool. Larry Wall made a reference to a interview with the C# head architect on Oreilly: http://windows.oreilly.com/news/hejlsberg_0800.html He said: Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. I'm as entusiastic as ever over the work with Perl 6 that is going on. Everything is going to get better, faster, smaller, easier, more intuitive, powerful and with loads of new cool fetaures. ;-) And its inspiering to read the language design discussions. This stage of the Wraf development is rather low level. We are designing a meta-language. (Perl v6 is planned to be alpha in one year and beta in two years, aproximatly.) > #4: Did I tell you about the 'parallell failure channel' I thought of > some years ago? I think every language should have an 'error stack' you > could put all the messages, non-critical failures, critical failures and > breaks in, so that when a process finally stops, you have a complete > failure log stack. Of course this would consist of diagnostic data and > plain text messages as well as error codes. This way, you could safely > assume that the error was reported on the correct level, and brought up > the levels... How would this differ from a normal traceback availible by the perl Carp functions? Maby you could give a more detaild example. Or explain how this could aply to Wraf. A general problem is that the error doesnt originate in the current branch of the call tree, but from another branch there a shared data structure was modified with bad data. > (The parallell failure channel really should be a feature of the > semi-SOAP I'm more and more interested in developing! We really should > call it WORF, for Web Object Remote Functions! (Or WRAF Object Remote > Functinality...)) Thats what the services do. It should be easy to just ad more services on diffrent machines, or use any service on the web. And it should be able to handle more trafic and more data by this distribution. The data replication should be transparent as an effect of the normal cache functions. But this is not my first intended use of Wraf... > Damn! This is getting dangerously close to what I saw in that vision > back in '97. Thank God MS obviously haven't seen the data == > presentation == logic thing yet, and thought about combining it with > recursive self-reference. Hush! You are on a open source mailing list. Sombody could actualy read this!! Maby we shold put a GPL copyright on every message? ;) Anyway... Two more days to go. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Thu Aug 17 14:50:44 2000 Date: Thu, 17 Aug 2000 15:50:44 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Little bits of thinkering... > > The language is pitched as a 'Java killer', aiming for most of the nifty > > features that made Java cool. > > Larry Wall made a reference to a interview with the C# head architect on > Oreilly: > http://windows.oreilly.com/news/hejlsberg_0800.html Quite an interesting article. But something about this whole C#-thing gives me the creeps. What the heck, maybe I'm going geek. :-D (I actually spent about an hour formulating a somewhat 'sharp' response to the msdn-article - and just as I was about to press 'submit' my Netscape crashed. Spooky...) > He said: > Here's another article that talks about a lot of the things we > *should* be thinking. In fact, it's possible this article should > be required reading for anyone who aspires to be a Perl designer. Hmmm. I'm not really sure I understand what he means. Maybe he was refferring to the component architecture thing, maybe he was refferring to MS surveying its developer community. Maybe he was just trying piss some purists off... > I'm as entusiastic as ever over the work with Perl 6 that is going > on. Everything is going to get better, faster, smaller, easier, more > intuitive, powerful and with loads of new cool fetaures. ;-) I'd say that some sort of object persistense and the ability of seamlessly invoke, serialize and transfer objects - properties and methods - would be right up there in the top 5. But I'm no Perl guy. > And its inspiering to read the language design discussions. This stage of > the Wraf development is rather low level. We are designing a > meta-language. Umm. I thought we were developing APIs and schemas? ?-| > > #4: Did I tell you about the 'parallell failure channel' I thought of > > some years ago? > How would this differ from a normal traceback availible by the perl Carp > functions? * It would (in my fantasies, that is) be an integrated result handling solution, not just a diagnostic tool. * It would separate the information flow into manageable, semantic, parts * It would be a required part of all components. I don't know if all Perl functions and modules are croaking, carping and confessing, but I don't think so? > Maby you could give a more detaild example. Well - If you'd get something like this back from a WORF: Sorry! Wouldn't that make you feel you could do all sorts of nifty automatic things with that output? Maybe even in some cases automatically deduce the source of the error and re-submit a corrected function invocation? :-D (I must add that this is off the top of my head) > Or explain how this could aply > to Wraf. :-D > A general problem is that the error doesnt originate in the > current branch of the call tree, but from another branch there a shared > data structure was modified with bad data. Yes. That is a problem. But that's not really what I was adressing. > > (The parallell failure channel really should be a feature of the > > semi-SOAP I'm more and more interested in developing! We really should > > call it WORF, for Web Object Remote Functions! (Or WRAF Object Remote > > Functinality...)) > > Thats what the services do. It should be easy to just ad more services on > diffrent machines, or use any service on the web. And it should be able to > handle more trafic and more data by this distribution. The data > replication should be transparent as an effect of the normal cache > functions. Yep. function equals data equals presentation. All the web servers in the world are just component repositories, waiting for somebody to invocate their member functions... ye-haa! (As soon as I get this damn paper of mine written, I'll sit myself down and write a prototype WORF application. Just to see it work.) > But this is not my first intended use of Wraf... Naah, it's just one more of those 'wouldn't it be cool if...') > > Damn! This is getting dangerously close to what I saw in that vision > > back in '97. Thank God MS obviously haven't seen the data == > > presentation == logic thing yet, and thought about combining it with > > recursive self-reference. > > Hush! You are on a open source mailing list. Sombody could actualy read > this!! Naah once more. We're just a bunch of spaced-out dreamers, right? > Maby we shold put a GPL copyright on every message? ;) Won't you make the 'mailman' do that? ;-D > Anyway... Two more days to go. Yup. See you monday. /Stefan From danbri@w3.org Fri Aug 18 11:10:31 2000 Date: Fri, 18 Aug 2000 06:10:31 -0400 (EDT) From: Dan Brickley danbri@w3.org Subject: [RDF] Re: RDF digest, Vol 1 #25 - 1 msg On Fri, 18 Aug 2000 rdf-request@uxn.nu wrote: > > > Damn! This is getting dangerously close to what I saw in that vision > > > back in '97. Thank God MS obviously haven't seen the data == > > > presentation == logic thing yet, and thought about combining it with > > > recursive self-reference. > > > > Hush! You are on a open source mailing list. Sombody could actualy read > > this!! > > Naah once more. We're just a bunch of spaced-out dreamers, right? > > > Maby we shold put a GPL copyright on every message? ;) > > Won't you make the 'mailman' do that? ;-D Reminds me to say 'hi'! I signed up after having stumbled across the mailing list at SourceForge, and having seen the occasional teaser msg on www-rdf-interest... (Spaced out dreamers who ship running code? That would be the perfect balance :-) BTW there are a few RDFish things coming together that seem to want to use SourceForge. I was wondering about their 'foundries' notion as perhaps providing tools to help communicate across project. Not sure quite what that'd amount to though. Dan From jonas@paranormal.se Fri Aug 18 11:47:51 2000 Date: Fri, 18 Aug 2000 12:47:51 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: RDF digest, Vol 1 #25 - 1 msg On Fri, 18 Aug 2000, Dan Brickley wrote: > BTW there are a few RDFish things coming together that seem to want to use > SourceForge. I was wondering about their 'foundries' notion as perhaps > providing tools to help communicate across project. Not sure quite what > that'd amount to though. Here is a list http://sourceforge.net/search/?words=RDF&type_of_search=soft It's frustrating to constantly get more things to consider. Just as I have a clear idea how to do things, and actualy have som code, there comes a couple of things that could be used as a base. Maby we could have used Redland. But I feel that we should do a indipendant implementation and maby use those C libraries in a future rewrite provided they have the functions we require. http://www.redland.opensource.ac.uk/docs/api/index.html -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From danbri@w3.org Fri Aug 18 12:14:33 2000 Date: Fri, 18 Aug 2000 07:14:33 -0400 (EDT) From: Dan Brickley danbri@w3.org Subject: [RDF] Re: RDF digest, Vol 1 #25 - 1 msg > It's frustrating to constantly get more things to consider. Yeah, but it's not all bad! Things can only get better and more interesting. More code == more fun... > Just as I have a clear idea how to do things, and actualy have som code, > there comes a couple of things that could be used as a base. Yeah, appreciate the frustration. I personally want to get on and build higher level apps; right now I'm trying that via strawman APIs against work-in-progress backends. By this time next year I hope we'll all have some common base(s) to build on... > Maby we could have used Redland. But I feel that we should do a > indipendant implementation and maby use those C libraries in a future > rewrite provided they have the functions we require. Makes sense. Dave is about to roll a release of Redland for people to play with. Good opportunity to revisit the common APIs thread on www-rdf-interest I think... Dan > http://www.redland.opensource.ac.uk/docs/api/index.html > > From stefan@c64.org Fri Aug 18 12:59:32 2000 Date: Fri, 18 Aug 2000 13:59:32 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Re: RDF digest, Vol 1 #25 - 1 msg Hi Dan! > > It's frustrating to constantly get more things to consider. > > Yeah, but it's not all bad! Things can only get better and more > interesting. More code == more fun... I'd say it's also both stimulationg and frustrating to see how RDF interest is exploding, but still not that many cool, useable, public applications have emerged. I just explained to Jonas that it feels like it must have felt in '94 watching the web boulder start rolling... you feel there's great opportunity, but what will be the 'killer-apps', who will get the first-mover advantage? > > Just as I have a clear idea how to do things, and actualy have som code, > > there comes a couple of things that could be used as a base. > > Yeah, appreciate the frustration. I personally want to get on and build > higher level apps; right now I'm trying that via strawman APIs against > work-in-progress backends. By this time next year I hope we'll all have > some common base(s) to build on... On a different note, I'm currently writing a e-business-paper touching on the incompabilities between XML and RDF, and I'm beginning to get really concerned with the way RDF (the DLG part) and RDF Schema digress konceptually with XML, XML Schema and RDF Syntax. I'm not really finished with the paper yet, but I begin to sense a ticking bomb there... at least if we're supposed to use RDF and RDF Schema derivatives to describe e-business transactions. Which, as far as I can see, is the only way we'll have even a remote chance of automatic schema conflict resolution, which in turn is a prerequisite for an open, global, automated electronic marketplace... That's why I felt it was somewhat disheartening to read the Cambridge Communique. > > Maby we could have used Redland. But I feel that we should do a > > indipendant implementation and maby use those C libraries in a future > > rewrite provided they have the functions we require. > > Makes sense. Dave is about to roll a release of Redland for people to play > with. Good opportunity to revisit the common APIs thread on > www-rdf-interest I think... Actually, this is equally frustrating. But I think you are right. In a year or so, there will probably have emerged some larger code bases. Right now it feels very much like '...and this one gives me _that_' - but I do think that Jonas think[er]ing is a tad extra. Kram, /Stefan From jonas@paranormal.se Sat Aug 19 20:35:55 2000 Date: Sat, 19 Aug 2000 21:35:55 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] rdfdb Christian Stamgren wrote: > > I don´t say that RDFDB is the same thing as wraf i just say this maby is something to build from or maby "steal" some ideas from. > > just som toughts maby in havn´t got the hole picture of wraf. It's ok. I have studied and taken input for years now. It's not that we doesn't apreciate new things. But that it's realy time to build on what we have now. And thats initialy my job... But we will have a release within a month. And we will have the public CVS within a week. > ----- Original Message ----- > From: "Jonas Liljegren" > To: "Christian Stamgren" > Sent: Tuesday, August 15, 2000 2:22 PM > Subject: Re: [RDF] rdfdb > > On Tue, 15 Aug 2000, Christian Stamgren wrote: > > > Shure thing but i don´t think that we should reinvent the wheel if we don´t have to ......... > > i think that it´s right to use tool that are allready developed. > > You would still have to do all the other things. > > What RDFDB gives: > * import/unimport RDF xml-files > * insert/delete triples > * a basic query language > > What RDFDB misses: > * It does not bind statements to models > * It does not make the 'fact' shortcut for reified statements > * No alias mechanism > * No container optimization > * No support for uri prefixes > * No support for blobs > * No URI asignment for statement > * No RDFS methods > * No checking of duplicate statements > > The experience with the RDF Schema editor > http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ made us want to > optimize for the most common case. That is: the realy heavy use of types > and subClassOf and the constant use of label in the development > enviroment. > > It does make it easy to import RDF data and to make queries. But it will > not be a good place to store the bulk of the data from Wraf. > > So: I would like to have an interface to RDFDB. It may be a little easier > to do some queries. But it doesn't cut back on the work we have to > do. RDFDB is too limited to be used as the main storage interface. It > should only be used with simple static data. > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Sun Aug 20 14:12:07 2000 Date: Sun, 20 Aug 2000 15:12:07 +0200 From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] [Fwd: RDF Database Specifications] This is a multi-part message in MIME format. --------------35186C4A5092BC984BA9B7EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit More things to think about. :-) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html --------------35186C4A5092BC984BA9B7EE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Envelope-to: jonas@liljegren.org Received: from www19.w3.org ([18.29.0.19]) by astral.paranormal.se with esmtp (Exim 3.12 #1 (Debian)) id 13QU2A-00012I-00 for ; Sun, 20 Aug 2000 14:17:02 +0200 Received: (from daemon@localhost) by www19.w3.org (8.11.0/8.9.0) id e7KCEBI11660; Sun, 20 Aug 2000 08:14:11 -0400 (EDT) Resent-Date: Sun, 20 Aug 2000 08:14:11 -0400 (EDT) Resent-Message-Id: <200008201214.e7KCEBI11660@www19.w3.org> Message-ID: <399FCA5B.C128B483@doc.ic.ac.uk> Date: Sun, 20 Aug 2000 13:09:00 +0100 From: Alex Barnell X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: "www-rdf-interest@w3.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RDF Database Specifications Resent-From: www-rdf-interest@w3.org X-Mailing-List: archive/latest/1248 X-Loop: www-rdf-interest@w3.org Sender: www-rdf-interest-request@w3.org Resent-Sender: www-rdf-interest-request@w3.org Precedence: list Resent-Bcc: X-Mozilla-Status2: 00000000 Hi, I am interested in developing a RDF database with the following features: 1. Write access to the database is unrestricted 2. An RDF entry has the option of having a digital signature. The encrpytion scheme, public key and signature should be associated with all the triples making up the RDF entry. Digital signatures should be checked on insertion to the database. 3. The database must be searchable in some manner, possibly similar to an SQL select statement. The idea is to return the RDF entries that satisfy the search criteria. 4. The search must allow approximate matches to be returned i.e. criteria on string literals should allow up to n insertions/deletions/substitutions. This would be similar to what Glimpse allows (www.webglimpse.org). A score between 0.0 and 1.0 should be associated with each search result. The search query should be able to specify both the maximum number of results desired, and also a minimum score threshold for the results. 5. A search query must be able to specify a list of trusted public keys. Only the triples associated with these public keys should be considered when constructing search results. Is anyone else working on similar projects? I am finding it hard to come up with a database design that satisfies all these criteria. Regards, Alex --------------35186C4A5092BC984BA9B7EE-- From stefan@c64.org Sun Aug 20 21:05:40 2000 Date: Sun, 20 Aug 2000 22:05:40 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] rdfdb Yo! > > I should mention right away that Jonas and me have slightly different > > ambitions when it comes to WRAF. Jonas is more interested in the > > metadata processing and cross-linking aspects. Myself, I am a bit more > > concerned with the presentation/serialization aspects a.k.a. 'content'. > > I think of the SDS as the next step, after we got the engine working. > But the enginge shoule definitly be ready for SDS. And I don't think it's > to early to start thinking about SDS. Yeah. I think I've changed my ambitions a bit. Right now it feels like the SDS is simply too big a munch. On a historical note: Jonas and I made a prototypish SDS based on Template Toolkit. (That is, Jonas hacking it, and I stood behind him cheering wildly and handing him Cola. Something like that...) Unfortunately it took somewhere around 1.500 database queries to build a single page, even with simple caching of triples. It's clear that multi-level caching has to be an integral part of the platform for anything like it to ever be useable. Or anything RDF at all, I'd say... Jonas'll digress, I'm sure... ;-) But even if the prototype took 90 seconds to build a simple page, it was damn cool to se it done at all. The point was, that the prototype took a model, and serialized it into HTML, based on the Schema definition, a context model, and HTML template declarations on resource and class (with multiple inheritance) level, dependant on the context model. So - in such few words: You told the prototype what object you wanted to see, and in what context, (context being whatewer you choose it to be, we tested it with 'view' vs. 'edit', but it could have been 'HTML', 'XML', 'WML'... or of course both simultaneous) - and the prototype found all candidate templates and elected one based on closest match with context specifications. On a per-resource basis. With multiple inheritance. Oh, I already said that. Way nifty! But way tooo slow, alas. But that is one of the things we hope to achieve with the all new-and-improved WRAF... > But I would love to use Wraf for many things even without the SDS > interface. >From now, I'll concentrate on working on the 'application' layer, that is - try to find some really cool [killer] applications for WRAF and WRAF-like application frameworks. The SOAP/WORF thing just gotta get coded. And I'll look into what can be done with the Mozilla stuff. And I want to make a database-to-RDF Schema converter and interface. And we need a reimplementation of the schema editor to support the multi-model architecture of WRAF... and I can think of a dozen other nifty stuffs just lying there. > > (The things Jonas won't let me call Serialization Description > > Schemas...) :-) > > I made a more detaild response later. The reaction was mostly of the > presentation of SDS. Ah, that came from our marketing department. ;-D ASP - Acronyms Sounds Posh. > > But Christian raised an issue. We should not call our interface to > > relational databases 'RDFDB', not in coding, and not in presenting it. > > That's like not calling PostgreSQL an SQL server, because M$ choose bold > names. Naah. That's like not calling PostgreSQL 'SQL Server', because it's a generic term for a class of products. > I call the present module for the RDF::Service::Interface::DBI::V01 Now THAT's a product name! Almost as cool as 'TI TMS320C64x'. I think we should call the DBI interface 'willabrook'! ;-D Sleep tight! /Stefan From guha@guha.com Mon Aug 21 17:12:51 2000 Date: Mon, 21 Aug 2000 09:12:51 -0700 From: Guha guha@guha.com Subject: [RDF] 10,000 queries to build a page 1,500 queries to build a page is not that bad. The Epinions website is built on top of an in-memory RDF database and many of the pages take over 10,000 queries for each page. The first version of the site ran on 4 intel machines and supported 100s of thousands of pages a day. Guha From jonas@paranormal.se Mon Aug 21 22:37:51 2000 Date: Mon, 21 Aug 2000 23:37:51 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] 10,000 queries to build a page On Mon, 21 Aug 2000, Guha wrote: > 1,500 queries to build a page is not that bad. That's 1,500 unique queries. Any duplicates was taken from the cache. In any case: We are now trying to use more high-level RDF storage, optimized for the common case. And we plan to cahce in several levels and register the dependencies of the cached "infered" properties, so that they will be updated if the source of the inference changed. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From guha@guha.com Mon Aug 21 22:38:50 2000 Date: Mon, 21 Aug 2000 14:38:50 -0700 From: Guha guha@guha.com Subject: [RDF] 10,000 queries to build a page I understand. Epinions does 10k unique queries. The WOT calculations are done in real time and are very expensive. Guha Jonas Liljegren wrote: > On Mon, 21 Aug 2000, Guha wrote: > > > 1,500 queries to build a page is not that bad. > > That's 1,500 unique queries. Any duplicates was taken from the > cache. > > In any case: We are now trying to use more high-level RDF storage, > optimized for the common case. And we plan to cahce in several levels and > register the dependencies of the cached "infered" properties, so that they > will be updated if the source of the inference changed. > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@paranormal.se Fri Aug 25 17:57:11 2000 Date: Fri, 25 Aug 2000 18:57:11 +0200 (CEST) From: Jonas Liljegren jonas@paranormal.se Subject: [RDF] Re: SV: Instant RDF On Fri, 25 Aug 2000, Greg FitzPatrick wrote: > > > > > > > > > > > > ski:qualvalue="gt 5" rdf:value=""/> > > > We can skip one level with help of the parseType attribute. But that makes the Euid resource anonymous. We have to go back to give Euid explicitly (using the euid property): One more note: I don't think that my generalized usage of rdf:value has been fully adopted by the RDF community yet... -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@rit.se Fri Aug 25 22:53:33 2000 Date: Fri, 25 Aug 2000 23:53:33 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Wraf code Well... It's friday. Most of the time went to hardware and software upgrades. Only got to active programming a couple of hours ago. I have extended and cleaned up the code for associating types statements with resources. And here is the result from running the test program: jonas@jonas:~/project/RDF-Service$ bin/w23a.pl Starting test program Bootstrap Registring RDF/Service/Interface/Base/V01.pm AUTOLOAD connect http://paranormal.se/rdf/2000/04/24/local/service/20000825T234014-001->go('connect', 'RDF::Service::Interface::Schema::RDFS_200001') Creating a prefixlist for IDS 5 Finding the prefix for http://paranormal.se/rdf/2000/04/24/local/service/20000825T234014-001 to be '' Jumptable for http://paranormal.se/rdf/2000/04/24/local/service/20000825T234014-001 is defined to 5/6/4-3-2 Constructing 5/6/4-3-2 jumptable http://cpan.org/rdf/module/RDF/Service/Interface/Base/V01 http://paranormal.se/rdf/2000/04/24/localService find_node() connect() http://paranormal.se/rdf/2000/04/24/localModel list_arcs() http://www.w3.org/2000/01/rdf-schema#Resource desig() set_types() Dispatching connect... Registring RDF/Service/Interface/Schema/RDFS_200001.pm AUTOLOAD connect http://paranormal.se/rdf/2000/04/24/local/service/20000825T234014-001->go('connect', 'RDF::Service::Interface::DBI::V01', 'dbi:Pg:dbname=wraf022', 'wwwdata') Dispatching connect... Registring RDF/Service/Interface/DBI/V01.pm DBI->connect(dbname=wraf022) failed: FATAL 1: Database "wraf022" does not exist in the system catalog. at /home/jonas/project/RDF-Service/bin/../lib/RDF/Service/Interface/DBI/V01.pm line 39 Time to create the DB on the new computer. :-) More to come next week... From jonas@rit.se Sat Aug 26 22:34:35 2000 Date: Sat, 26 Aug 2000 23:34:35 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] CVS update I initiated the CVS yesterday. The current version can now connect to Base, Schema and DBI and creates a model with help of DBI. The debugging output is more helpful. This is the output I get from running bin/w23a.pl : Starting test program Bootstrap Registring RDF/Service/Interface/Base/V01.pm IDS: 5 AUTOLOAD connect http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001->go('connect', 'RDF::Service::Interface::Schema::RDFS_200001') Creating a prefixlist for IDS 5 Finding the prefix for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 to be '' Jumptable for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 is defined to 5/6/4-3-2 Constructing 5/6/4-3-2 jumptable http://cpan.org/rdf/module/RDF/Service/Interface/Base/V01 http://paranormal.se/rdf/2000/04/24/localService find_node() connect() http://paranormal.se/rdf/2000/04/24/localModel list_arcs() http://www.w3.org/2000/01/rdf-schema#Resource desig() set_types() Dispatching connect... Registring RDF/Service/Interface/Schema/RDFS_200001.pm IDS: 5-7 AUTOLOAD connect http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001->go('connect', 'RDF::Service::Interface::DBI::V01', 'HASH(0x8283e30)') Creating a prefixlist for IDS 5-7 Finding the prefix for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 to be '' Jumptable for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 is defined to 5-7/6/4-3-2 Constructing 5-7/6/4-3-2 jumptable http://cpan.org/rdf/module/RDF/Service/Interface/Base/V01 http://paranormal.se/rdf/2000/04/24/localService find_node() connect() http://paranormal.se/rdf/2000/04/24/localModel list_arcs() http://www.w3.org/2000/01/rdf-schema#Resource desig() set_types() http://cpan.org/rdf/module/RDF/Service/Interface/Schema/RDFS_200001 Dispatching connect... Registring RDF/Service/Interface/DBI/V01.pm Store DBH for http://cpan.org/rdf/module/RDF/Service/Interface/DBI/V01?connect=dbi%3APg%3Adbname%3Dwraf022&name=wwwdata in [PRIVATE]{8}{'dbh'} IDS: 5-7-8 AUTOLOAD create_model http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001->go('create_model') Creating a prefixlist for IDS 5-7-8 Finding the prefix for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 to be '' Jumptable for http://paranormal.se/rdf/2000/04/24/local/service/20000826T232750-001 is defined to 5-7-8/6/4-3-2 Constructing 5-7-8/6/4-3-2 jumptable http://cpan.org/rdf/module/RDF/Service/Interface/Base/V01 http://paranormal.se/rdf/2000/04/24/localService find_node() connect() http://paranormal.se/rdf/2000/04/24/localModel list_arcs() http://www.w3.org/2000/01/rdf-schema#Resource desig() set_types() http://cpan.org/rdf/module/RDF/Service/Interface/Schema/RDFS_200001 http://cpan.org/rdf/module/RDF/Service/Interface/DBI/V01?connect=dbi%3APg%3Adbname%3Dwraf022&name=wwwdata http://paranormal.se/rdf/2000/04/24/localModel create_model() http://www.w3.org/2000/01/rdf-schema#Resource set_types() Dispatching create_model... Creating node http://paranormal.se/rdf/2000/04/24/local/model/20000826T232751-001# Getting DBH for http://cpan.org/rdf/module/RDF/Service/Interface/DBI/V01?connect=dbi%3APg%3Adbname%3Dwraf022&name=wwwdata from [PRIVATE]{8}{'dbh'} ***http://paranormal.se/rdf/2000/04/24/local/model/20000826T232751-001# IDS: 5-7-8 From jonas@rit.se Fri Sep 1 19:57:29 2000 Date: Fri, 01 Sep 2000 20:57:29 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] CVS update You can now - connect to the DB - create a model - use the model to add an arc - list the properties for a subject And the arcs are stored and retrieved from the DB The API is rather object sentric as oposed to the DB that stores the arcs as separate records. So what should be in the first alfa release? What shoule you be able to do? Some simple scenarios... From jonas@liljegren.org Wed Sep 20 09:13:24 2000 Date: 20 Sep 2000 10:13:24 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] An attempt on a project plan New CVS update. The module is slowly shaping up. Mainly more work on creation of resources in the form of statements about models, services, types and more. The state of the DB now remains stable. The involved resources gets stored with the first run and stays the same under repeated runs. This is my plan. With aproximatly 1.5 weeks for each alfa stage. This plan is also stored in the TODO file in the CVS. Prototype case one: Address register DONE - Add properties - View all properties for person - Get all persons that match a specific literal string - Remove/change statements --- (alfa 1) - Store data using P3P - View heiarcical presentation of person - Get all persons that match a string out on a limb - Search on a combination of properties --- (alfa 2) - Implement c/s architecture - Implement callbacks to updated cache on changes in the source - Create a web HTML interface to register --- (alfa 3) - Session metadata - User identification --- (alfa 4) - SDL general data displaying - Create new fields via HTML --- (beta 1) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Wed Sep 20 18:37:43 2000 Date: 20 Sep 2000 19:37:43 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Usage with TT2 I have started on a prototype program for implementing a simple person register using Template Toolkit 2. This is TT2 code for listing all propertis/values for a specific resource. * "Desig" is a method to get the best availible designation of the resource. That would be the literal value, the label, the uri minus some specific namespace or just the whole uri. * The "${NS_L}" thing is a reference to the local namespace. * The s object is the "session" (Service) object. [% subj = s.get_node("${NS_L}#S1") %]

And here is [% subj.desig %]

    [% FOREACH prop = subj.get_props_list %]
  • [% prop.desig %]: [% subj.get_objects_list(prop).0.desig %] [% END %]
-- / Jonas - http://jonas.liljegren.org/myself/en/index.html From Stefan.Andersson@ullmans.com Thu Sep 21 07:31:01 2000 Date: Thu, 21 Sep 2000 08:31:01 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: [RDF] Usage with TT2 Damn cool! /Stefan > I have started on a prototype program for implementing a simple person > register using Template Toolkit 2. > > This is TT2 code for listing all propertis/values for a specific > resource. > > * "Desig" is a method to get the best availible designation of the > resource. That would be the literal value, the label, the uri minus > some specific namespace or just the whole uri. > > * The "${NS_L}" thing is a reference to the local namespace. > > * The s object is the "session" (Service) object. > > > > [% subj = s.get_node("${NS_L}#S1") %] > >

And here is [% subj.desig %]

> >
    > [% FOREACH prop = subj.get_props_list %] >
  • [% prop.desig %]: [% subj.get_objects_list(prop).0.desig %] > [% END %] >
From jonas@liljegren.org Thu Sep 21 13:37:04 2000 Date: 21 Sep 2000 14:37:04 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Non-fact statements Just a thought. The DB model includes fields that states if the statements is to be considered facts or not. This is a common solution to represent reified statements. But the introduction of "trusted models" makes it possible to skip that field. A reification statement talks about some statement possible from another model. Non-fact statements from a non-specified model could just be placed in some special model that defaults to untrusted. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Thu Sep 21 13:43:44 2000 Date: 21 Sep 2000 14:43:44 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Version handling Versionhandling comes partly by itself. Each model is a group of statements from a specific agent at a specific time. The time and agent gets stored in the model metadata. If the same agent (person) updates some data, that is done in a new model. A presentation of a resource propertis could just display propertes from a specific agent or all later data from later than a specific date. But how do we say that one statement should replace another statement? Or that a specific statement or group of them should be deleted? What would be a good way of handling this? -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Thu Sep 21 20:48:42 2000 Date: Thu, 21 Sep 2000 21:48:42 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Non-fact statements > Just a thought. > > The DB model includes fields that states if the statements is to be > considered facts or not. This is a common solution to represent > reified statements. > > But the introduction of "trusted models" makes it possible to skip > that field. A reification statement talks about some statement > possible from another model. > > Non-fact statements from a non-specified model could just be placed in > some special model that defaults to untrusted. Well, actually, I've always found the division between 'fact' and non-fact a bit silly. There is no such thing as a 'fact', only trusted or non-trusted statements/data. A model can be judged trustworthy based on its internal consistency, or its backing by an authority. There is _always_ an issuer of the statement, implicit or explicit. The trick is wheter the system _remembers_ (is aware of and has retained the knowledge of) who the issuer was. And - these are different levels of indirection. If my system were to access the model http://www.w3.org/1999/02/22-rdf-syntax-ns the _primary_ _implicit_ issuer of the model would be the actualized http daemon on www.w3.org. Now, if the returned model would include some sort of standardized 'attributed_to', that would be an _secondary_ _explicit_ statement of issuer. One could imagine a _secondary_ _implicit_ statement of issuer based upon the OS 'last_updated_by' or by file system rights. Now, if the _primary_ issuer wasn't trustworthy, there is no way you could trust the issued model, and thus not the attribution in it. That's pretty banal. But the opposite is true as well. Just because the primary source is trusted, that does not mean the secondary has to be. If I was to try to summarize, it would be by pointing to a thought-provoking paper on trust published by E Gerck and the MCG: http://www.mcg.org.br/trustdef.htm Read it. I mean it. Then read it again. Kram, /Stefan BTW. Why doesn't the w3.org/rdf page use RDF for content declaration? Never trust a skinny chef... ;-) From stefan@c64.org Thu Sep 21 21:08:08 2000 Date: Thu, 21 Sep 2000 22:08:08 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] Version handling Warning: Rant-in-the-night > Versionhandling comes partly by itself. > > Each model is a group of statements from a specific agent at a > specific time. The time and agent gets stored in the model metadata. > > If the same agent (person) updates some data, that is done in a new > model. A presentation of a resource propertis could just display > propertes from a specific agent or all later data from later than a > specific date. > > But how do we say that one statement should replace another statement? > Or that a specific statement or group of them should be deleted? > > What would be a good way of handling this? I'd say there is no 'good' way of handling it. Either you go the full nine yards, and implement a system capable of handling true (hyperdimensional) context, which probably would be humongously big and slow, or you have to cut it down. And cutting down necessarily means letting out. In 'the real world' we do remember stuff that an agent has said before even if that agent says something else now. Is the discrepansies between now and then too wide, or if we encounter them too often, we will have to downgrade our trust in that source. Once more trust. Trust is key. My point being that every statement is separated in time and space from every other statement. The idea that two statements are 'the same' is a connection done on the idea plane - thus one would need a layer of root data, and another interconnecting layer of 'sameness' or 'class'. That is, 'instance' has to be a recursive in the same way as 'class' is. Once more - class vs instance. Actually - one could say 'version' roughly means 'sufficiently equivalent', that is, 'all those instances could fill roughly the same function, but with small, maybe critical, differences'. Sameness/Differentness as a vector... hmm. With increasing time one supposes increased accumulation of experience and inference, thus the versions ordered temporally represents increasing experience and inference... but where is the breaking points? Where is the 'this is one version, and now it has changed enough that we may call it another'? I see the analogy to the 'what is a model, and what is not'-question. Internal concistency seems like a good measure... * yawwn * 'night! /Stefan From jonas@liljegren.org Sat Sep 23 17:39:20 2000 Date: 23 Sep 2000 18:39:20 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] CVS Update Will try to make an alfa release tomorrow. The current code has an example program for adding persons, listing persons and deleting persons. Each person has a first- and last name. It seems to work fine. But there are many many things that are not yet done. The menu has a "Init db" option to register the Person class. ... What should I call the method for listing all the objects of a spcific class? objects_list() is already used for listing the objects for all arcs with a specific subj and pred. Maby call it class_objects_list()? The idea was to always return "virtual models" containing the result of selections, unless the mothod has the _list prefix, in which case it should return a list reference instead. There is another destinction between get_ find_ and create_ methods. The get_ methods will either find or create the node depending on if it already exist or not. The create methods can usualy generate a unique uri if non is specified. You should be able to either use the object or the URI as a parameter for method calls. That's not possible right now... This is how all persons are listed: [% persons = s.get_node("${NS_L}/Class#Person").objects_list %] [% FOREACH person = persons %] [% END %]
[% person.get_objects_list(s.get_node("${NS_L}/Property#first_name")).0.value %] [% person.get_objects_list(s.get_node("${NS_L}/Property#last_name")).0.value %]
-- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Sun Sep 24 21:12:05 2000 Date: 24 Sep 2000 22:12:05 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] RDF::Service I recently uploaded the file RDF-Service-0.01.tar.gz and would like to add this to the Perl 5 Module List. Name DSLI Description Info ------------- ---- -------------------------------------------- ----- RDF::Service ampO RDF API with DBI and other backends JONAS This is part of Wraf, as described on its homepage and att SourceForge: http://www.uxn.nu/wraf/ http://sourceforge.net/projects/wraf/ Appropriate categories for this and other RDF modules would be: 07_Database_Interfaces 11_String_Lang_Text_Proc 15_World_Wide_Web_HTML_HTTP_CGI The main community for RDF discussions about new programs and libraries are the RDF Intrest Group mailing-list at W3C: http://lists.w3.org/Archives/Public/www-rdf-interest/ -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Sun Sep 24 21:16:52 2000 Date: 24 Sep 2000 22:16:52 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] First release Ok. I have collected the files and released them as RDF-Service-0.01.tar.gz The file is uploaded to CPAN and SourceForge What you can do with the 0.01 version: * create * list * update * delete -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Mon Sep 25 09:28:53 2000 Date: 25 Sep 2000 10:28:53 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: RDF digest, Vol 1 #36 - 2 msgs (fwd) Dan Brickley writes: > interesting... :-) > > is an announcment on www-rdf-interest (and perl-xml?) looming? :-) It's comming. But maby I will wait until the second release. One of the major points with Wraf is to handle multiple sources even then they are overlapping. The bases for this is there but nit working yet. I will sort this out by connecting two databases and try out assorted conflicts. But ok. I will send out an announce then CPAN has been updated with the file. (Maby tomorrow.) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Mon Sep 25 09:43:11 2000 Date: 25 Sep 2000 10:43:11 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: RDF digest, Vol 1 #36 - 2 msgs (fwd) Dan Brickley writes: > On 25 Sep 2000, Jonas Liljegren wrote: > > > One of the major points with Wraf is to handle multiple sources even > > then they are overlapping. The bases for this is there but nit > > working yet. I will sort this out by connecting two databases and > > try out assorted conflicts. > > Cool! When they're overlapping is the interesting case I think. When you > have anonymous nodes that represent the same thing, that's even more > interesting. I nearly have Perl code finished to deal with the latter > case; will be interesting to see if it plugs into your framework... How do you represent anonymous resources? For now, I just generates URIs for everything. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From danbri@w3.org Mon Sep 25 10:38:22 2000 Date: Mon, 25 Sep 2000 05:38:22 -0400 (EDT) From: Dan Brickley danbri@w3.org Subject: [RDF] Re: RDF digest, Vol 1 #36 - 2 msgs (fwd) On 25 Sep 2000, Jonas Liljegren wrote: > Dan Brickley writes: > > > On 25 Sep 2000, Jonas Liljegren wrote: > > > > > One of the major points with Wraf is to handle multiple sources even > > > then they are overlapping. The bases for this is there but nit > > > working yet. I will sort this out by connecting two databases and > > > try out assorted conflicts. > > > > Cool! When they're overlapping is the interesting case I think. When you > > have anonymous nodes that represent the same thing, that's even more > > interesting. I nearly have Perl code finished to deal with the latter > > case; will be interesting to see if it plugs into your framework... > > How do you represent anonymous resources? > > For now, I just generates URIs for everything. Internally generated identifiers are necessary for database management, but if I don't know the 'real' URI for something I make sure I represent that lack of knowledge. Then I use meta-knowledge about certain predicates (eg. 'personalMailbox','corporateHomepage') to fold together nodes that 'must' be the same because they share a property/value pair that implies they are the self-same node... Dan From jonas@liljegren.org Mon Sep 25 13:19:20 2000 Date: 25 Sep 2000 14:19:20 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Non-fact statements Stefan Andersson writes: > > Non-fact statements from a non-specified model could just be placed in > > some special model that defaults to untrusted. > > Well, actually, I've always found the division between 'fact' and > non-fact a bit silly. There is no such thing as a 'fact', only trusted > or non-trusted statements/data. Yes. But you just have to believe in something before you can start mistrust. The system base logic has a whole lot of RDF implicit and explicit. Those base statements must be trusted. My first thought was to consider fact statements the unquestioned truths and mark all "user" and imported statements as non-facts. > A model can be judged trustworthy based on its internal consistency, or > its backing by an authority. There is _always_ an issuer of the > statement, implicit or explicit. The trick is wheter the system > _remembers_ (is aware of and has retained the knowledge of) who the > issuer was. Wraf ties a model to every statement. That model will hold that data. i don't know how much has been done in modeling this in RDF. Maby it would be better to wait with the details. But the main functionality is to get a level of trust for a specific statement. that could maby be calculated from the statement content and the model. That is: the trust can differ acording to the type of statement. > And - these are different levels of indirection. > > If my system were to access the model > http://www.w3.org/1999/02/22-rdf-syntax-ns > the _primary_ _implicit_ issuer of the model would be the actualized > http daemon on www.w3.org. > > Now, if the returned model would include some sort of standardized > 'attributed_to', that would be an _secondary_ _explicit_ statement of > issuer. > One could imagine a _secondary_ _implicit_ statement of issuer based > upon the OS 'last_updated_by' or by file system rights. > > Now, if the _primary_ issuer wasn't trustworthy, there is no way you > could trust the issued model, and thus not the attribution in it. That's > pretty banal. But the opposite is true as well. Just because the primary > source is trusted, that does not mean the secondary has to be. Yes. That will be contained in the model metadata. > If I was to try to summarize, it would be by pointing to a > thought-provoking paper on trust published by E Gerck and the MCG: > > http://www.mcg.org.br/trustdef.htm > > Read it. I mean it. Then read it again. and you call that a summary?!? It's long! I have printed it and will look at it later. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From Stefan.Andersson@ullmans.com Mon Sep 25 13:40:53 2000 Date: Mon, 25 Sep 2000 14:40:53 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: [RDF] Non-fact statements > > > Non-fact statements from a non-specified model could just be placed in > > > some special model that defaults to untrusted. > > > > Well, actually, I've always found the division between 'fact' and > > non-fact a bit silly. There is no such thing as a 'fact', only trusted > > or non-trusted statements/data. > > Yes. But you just have to believe in something before you can start > mistrust. Hmm.. I would change that to 'without trust there can be no communication, but without communication, there is nothing to trust.' So I guess you're right. I think that starting point would be 'the things I know I know' - a single trust statement. Or set of trust statements. ROOT statement. Hmmm.. > The system base logic has a whole lot of RDF implicit and > explicit. Those base statements must be trusted. My first thought was > to consider fact statements the unquestioned truths and mark all > "user" and imported statements as non-facts. Actually, what we do is optimizing thru faith. There is nothing 'must' about it. And I don't always trust my own memory. I could import faulty or fraudulent data. > > A model can be judged trustworthy based on its internal consistency, or > > its backing by an authority. There is _always_ an issuer of the > > statement, implicit or explicit. The trick is wheter the system > > _remembers_ (is aware of and has retained the knowledge of) who the > > issuer was. > > Wraf ties a model to every statement. That model will hold that data. > i don't know how much has been done in modeling this in RDF. Maby it > would be better to wait with the details. But the main functionality > is to get a level of trust for a specific statement. that could maby > be calculated from the statement content and the model. That is: the > trust can differ acording to the type of statement. Hmmm. I'm not entirely with you on that last statement. But I can quote Gerck - 'there are no degrees of trust. Either you trust, or you dont.' - and I think he is right. > > And - these are different levels of indirection. > > > > If my system were to access the model > > http://www.w3.org/1999/02/22-rdf-syntax-ns > > the _primary_ _implicit_ issuer of the model would be the actualized > > http daemon on www.w3.org. > > > > Now, if the returned model would include some sort of standardized > > 'attributed_to', that would be an _secondary_ _explicit_ statement of > > issuer. > > One could imagine a _secondary_ _implicit_ statement of issuer based > > upon the OS 'last_updated_by' or by file system rights. > > > > Now, if the _primary_ issuer wasn't trustworthy, there is no way you > > could trust the issued model, and thus not the attribution in it. That's > > pretty banal. But the opposite is true as well. Just because the primary > > source is trusted, that does not mean the secondary has to be. > > Yes. That will be contained in the model metadata. I think the 'model' should be treated simply as an optimization by concept, and not as a built-in prerequisite. But you already know my view on this. > > If I was to try to summarize, it would be by pointing to a > > thought-provoking paper on trust published by E Gerck and the MCG: > > > > http://www.mcg.org.br/trustdef.htm > > > > Read it. I mean it. Then read it again. > and you call that a summary?!? It's long! I have printed it and will look at it later. Ah, sorry, sorrryyy! No, my summary was the act of pointing to the document, not the document in itself. The document is long. And hard to penetrate. But, I think, rewarding. Is there anybody else on the list that know anything about Gerck? Kram, /Stefan From jonas@liljegren.org Mon Sep 25 13:55:58 2000 Date: 25 Sep 2000 14:55:58 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Version handling Stefan Andersson writes: > > But how do we say that one statement should replace another statement? > > Or that a specific statement or group of them should be deleted? > > > > What would be a good way of handling this? > > I'd say there is no 'good' way of handling it. Either you go the full > nine yards, and implement a system capable of handling true > (hyperdimensional) context, which probably would be humongously big and > slow, or you have to cut it down. And cutting down necessarily means > letting out. I meant to ask; what is the best way of handling this? We don't have to have the ultimate versioning system. It would be nice if it could be extended to the ultimate system. :) The basic thing we want to do is to filter out previous versions of a statement. Let's say that I chnage the phone number. The old statement remains but should not normaly be shown. We could base the version handling on statements bound to a point in time. Every statement belongs to a model and the model has a creation date (and maby should have a last-updated-date (in case for "open models")). The date information could be used to see what information is the most recent. But I could have two phone numbers so it wouldn't be right to just exclude one of the numbers if the other is more recent. The old number must be expired in some way. Time based versioning is nice because it let's you examine a systems state in a previous time. But updated information could also be about correctd information. The old information wasn't correct at any time. Help me out here... > In 'the real world' we do remember stuff that an agent has said before > even if that agent says something else now. Is the discrepansies between > now and then too wide, or if we encounter them too often, we will have > to downgrade our trust in that source. Once more trust. Trust is key. Well. that's not the problem. > My point being that every statement is separated in time and space from > every other statement. The idea that two statements are 'the same' is a > connection done on the idea plane - thus one would need a layer of root > data, and another interconnecting layer of 'sameness' or 'class'. Yes. And I think that one simple way to do it is that just say that the new statement should replace the old. That would be new_statement --replaces--> old_statement If you combine this with the trust thing, you would have to implement an efficient way to select all non-replaced statements except those replaced by non-trusted statements, unless those in turn has been replaced with a trusted statement... I just ask for an efficient model for the implementation. > That is, 'instance' has to be a recursive in the same way as 'class' > is. Once more - class vs instance. Now I lost you. > Actually - one could say 'version' roughly means 'sufficiently > equivalent', that is, 'all those instances could fill roughly the same > function, but with small, maybe critical, differences'. Ah. Now I think that I understand. You can produce two statements about diffrent things, but that contradict each other in some way. Which of the statements should we follow? > Sameness/Differentness as a vector... hmm. With increasing time one > supposes increased accumulation of experience and inference, thus the > versions ordered temporally represents increasing experience and > inference... but where is the breaking points? Where is the 'this is one > version, and now it has changed enough that we may call it another'? I > see the analogy to the 'what is a model, and what is not'-question. > Internal concistency seems like a good measure... This is a question about the granuality of time? Where shouldn't be a problem to group models i larger groups. The basic use for models is just so that we don't have to have a lot of metadata about each statement. And in the case of imported RDF/XML documents, there is a clear unit that would become the model. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Mon Sep 25 14:23:37 2000 Date: 25 Sep 2000 15:23:37 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: SV: [RDF] Non-fact statements Stefan Andersson writes: > > > > Non-fact statements from a non-specified model could just be placed in > > > > some special model that defaults to untrusted. > > > > > > Well, actually, I've always found the division between 'fact' and > > > non-fact a bit silly. There is no such thing as a 'fact', only trusted > > > or non-trusted statements/data. > > > > Yes. But you just have to believe in something before you can start > > mistrust. > > Hmm.. I would change that to 'without trust there can be no communication, > but without communication, there is nothing to trust.' So I guess you're > right. I think that starting point would be 'the things I know I know' - a > single trust statement. Or set of trust statements. ROOT statement. Hmmm.. I think I am what I think, I think... Or something. ;) I just say that you always trust the Wraf service. I you don't trust Wraf. You can't trust it then it says that you trust/mistrust other things. > > The system base logic has a whole lot of RDF implicit and > > explicit. Those base statements must be trusted. My first thought was > > to consider fact statements the unquestioned truths and mark all > > "user" and imported statements as non-facts. > > Actually, what we do is optimizing thru faith. There is nothing 'must' about > it. And I don't always trust my own memory. I could import faulty or > fraudulent data. Ok. I will implement the $self->leap_of_faith($model) ;-) > > > A model can be judged trustworthy based on its internal consistency, or > > > its backing by an authority. There is _always_ an issuer of the > > > statement, implicit or explicit. The trick is wheter the system > > > _remembers_ (is aware of and has retained the knowledge of) who the > > > issuer was. > > > > Wraf ties a model to every statement. That model will hold that data. > > i don't know how much has been done in modeling this in RDF. Maby it > > would be better to wait with the details. But the main functionality > > is to get a level of trust for a specific statement. that could maby > > be calculated from the statement content and the model. That is: the > > trust can differ acording to the type of statement. > > Hmmm. I'm not entirely with you on that last statement. But I can quote > Gerck - 'there are no degrees of trust. Either you trust, or you dont.' - > and I think he is right. So you har only 80% sure of it? ;-) I like the Fuzzy logic expert systems. But most of the base logic will use binary truth. My statement above was about P3P type things. If you know that an agent is an expert in one topic but don't know much in another topic, you would ascribe diffrent levels of trust dependent on the subject type or maby property. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From Stefan.Andersson@ullmans.com Mon Sep 25 14:35:35 2000 Date: Mon, 25 Sep 2000 15:35:35 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: SV: [RDF] Non-fact statements > I think I am what I think, I think... Or something. ;) A friend of mine has examined the 'Cogito ergo sum' reasoning and concluded it was based on faulty presumtions... > I just say that you always trust the Wraf service. I you don't trust > Wraf. You can't trust it then it says that you trust/mistrust other > things. Yes, of course. Optimization thru faith. But: this is an implicit trust. One _could_ think of an architecture where even this had to be made explicit. Gerck (once again...) uses encryption as a 'routing' mechanism: distribute encrypted data freely, only the correct recipient will be able to open it, and the recipient would always be sure it was from the right sender... > > Actually, what we do is optimizing thru faith. There is nothing 'must' about > > it. And I don't always trust my own memory. I could import faulty or > > fraudulent data. > > Ok. I will implement the $self->leap_of_faith($model) ;-) Hihi. $self->lift_by_hair($self) > > Hmmm. I'm not entirely with you on that last statement. But I can quote > > Gerck - 'there are no degrees of trust. Either you trust, or you dont.' - > > and I think he is right. > > So you har only 80% sure of it? ;-) > > I like the Fuzzy logic expert systems. But most of the base logic > will use binary truth. Yoda: "No, there is no 'try'. Either you do, or you don't." (or something like it) > My statement above was about P3P type things. If you know that an > agent is an expert in one topic but don't know much in another topic, > you would ascribe diffrent levels of trust dependent on the subject > type or maby property. Hmmm... actually, trust is a multidimensional vector, consisting of all the trust-points. /Stefan From jonas@liljegren.org Mon Sep 25 15:04:41 2000 Date: 25 Sep 2000 16:04:41 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: SV: SV: [RDF] Non-fact statements Stefan Andersson writes: > > I think I am what I think, I think... Or something. ;) > > A friend of mine has examined the 'Cogito ergo sum' reasoning and concluded > it was based on faulty presumtions... I don't think you friend exist. ;) > > I like the Fuzzy logic expert systems. But most of the base logic > > will use binary truth. > > Yoda: "No, there is no 'try'. Either you do, or you don't." (or something > like it) Hmm. That doesn't seem practical. How do you get the most probable answer to a question if you don't trust anyone? -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Tue Sep 26 10:04:23 2000 Date: 26 Sep 2000 11:04:23 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] functions / properties We have the intention to not differentiate between properties and functions. A property value can be determined using any algorithm. A function call with parameters should be the same as a query model. Further : All functions should have a unique URI in the same manner that the module itself is a resource, as is the resulting interface. That means that you in the interface could use properties as methods. For example: "$person->contact->home->phone->value" or something like that. This would require you to first register shortcuts for the functions and properties you would like to use in this way. That is: tell the service how to translate the name to the full uri. Any nonregistred functions can still be called with something like $person->get( "http://.../" ). One important use of this property/function equality is the presentation layer. The presentation of a resource is a property. That presentation resource has metadata saying what type of presnetation it is - the context. A resource can have several presentations. The method call for the presentation can send arguments to make the selection among the presentations. Like: $person -> presentation( format => 'html', layout =) $fancy_layout, trust => $my_trust, ) -> value; Or something like that... And you could be certain that this would be true: $person -> presentation( format => 'html', layout =) $fancy_layout, trust => $my_trust, ) -> format -> value eq 'html'; So the style would also be used for normal propertues: $person->first_name(according_to=>$this_person)->value; But what is the model of those generated statements? The resulting model would be a product of the issuer of the involved function as well as all parameters used. The reson I write this now is because I just now want to define the calling order of the functions in the jumptable. It should be called in order of speciality. The type of the resource is used. An connected model can define that one class is a subClassOf another class. And the RDFS model will programmaticly say that the specific class is subClassOf all classes that the super-class is subClassOf. This subClassOf thing will now serve as the test for this property/function implementation. I intended to ask how this should be done, but it seem that I answerd my own question. Thank you for your time. :-) But I would still like some comments. (Small note: There has been a short interruption in the connection to the uxn.nu server. It seems to work now. Blame Stockholm-DGIX-DPT.telenordia.se.) -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Wed Sep 27 08:59:38 2000 Date: 27 Sep 2000 09:59:38 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] CVS Update The yesterdays update fixed a couple of things: - Shortend get_node() to get() - You can now use either node or uri for many parameters - declare_add_type() now adds implicit types based on subClassOf - added a guard against infinite recursions -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From Stefan.Andersson@ullmans.com Wed Sep 27 10:48:00 2000 Date: Wed, 27 Sep 2000 11:48:00 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: [RDF] Version handling > I meant to ask; what is the best way of handling this? Ah, damn - a concrete question. > We don't have to have the ultimate versioning system. It would be nice > if it could be extended to the ultimate system. :) Mmmm... * dreamy voice * > The basic thing we want to do is to filter out previous versions of a > statement. Let's say that I chnage the phone number. The old > statement remains but should not normaly be shown. Yeah, there is a few 'atomic' filters - 'current valid version (a.k.a. latest)' that deserves an extra optimization boost, but (as you know) I think it's an interesting idea to think of a filter as a 'virtual model', so you have this vast ocean of resources, and look thru the 'latest' spectacles, you'll only see the model consisting of all the 'latest' resources. > We could base the version handling on statements bound to a point in > time. Every statement belongs to a model and the model has a creation > date (and maby should have a last-updated-date (in case for "open > models")). > > The date information could be used to see what information is the most > recent. But I could have two phone numbers so it wouldn't be right to > just exclude one of the numbers if the other is more recent. The old > number must be expired in some way. Actually, that's a rather interesting example. It illuminates the point that it is not enough with f.ex. 'home phone'. And I still maintain that you never 'change' a statement. You revoke an earlier statement, and make a new. It kind of solves your problem, doesn't it? > Time based versioning is nice because it let's you examine a systems > state in a previous time. But updated information could also be about > correctd information. The old information wasn't correct at any time. See above. > Help me out here... Rocket ranger to the rescue! > > In 'the real world' we do remember stuff that an agent has said before > > even if that agent says something else now. Is the discrepansies between > > now and then too wide, or if we encounter them too often, we will have > > to downgrade our trust in that source. Once more trust. Trust is key. > > Well. that's not the problem. Ummm. You lost me on this track? > > My point being that every statement is separated in time and space from > > every other statement. The idea that two statements are 'the same' is a > > connection done on the idea plane - thus one would need a layer of root > > data, and another interconnecting layer of 'sameness' or 'class'. > > Yes. And I think that one simple way to do it is that just say that > the new statement should replace the old. That would be > > new_statement --replaces--> old_statement > > If you combine this with the trust thing, you would have to implement > an efficient way to select all non-replaced statements except those > replaced by non-trusted statements, unless those in turn has been > replaced with a trusted statement... > > I just ask for an efficient model for the implementation. Well. Based on my work with this kind of models in content managing, I'd say that what you need is a 'created' - 'revoked' model, where you'd apply a cached filter on what resources are 'created' but not 'revoked', these are your current model. (Actually, our CM model was a wee bit more complicated, as you had four states: 'created', 'updated', 'published', 'revoked' to separate the two levels of publishing - the level where only the author saw the changes, and the level where everybody could see the changes.) > > Actually - one could say 'version' roughly means 'sufficiently > > equivalent', that is, 'all those instances could fill roughly the same > > function, but with small, maybe critical, differences'. > > Ah. Now I think that I understand. Versioning points to the fact that you should be able to say 'this instance is a sub-instance of this instance' a.k.a. 'version'. > You can produce two statements about diffrent things, but that > contradict each other in some way. Which of the statements should we > follow? The trick is to isolate the discrepancy - the very thing I was hoping we could implement intelligently in WRAF. /Stefan From jonas@liljegren.org Wed Sep 27 19:32:43 2000 Date: 27 Sep 2000 20:32:43 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: SV: [RDF] Version handling Stefan Andersson writes: > > The basic thing we want to do is to filter out previous versions of a > > statement. Let's say that I chnage the phone number. The old > > statement remains but should not normaly be shown. > > Yeah, there is a few 'atomic' filters - 'current valid version (a.k.a. > latest)' that deserves an extra optimization boost, but (as you know) I > think it's an interesting idea to think of a filter as a 'virtual model', so > you have this vast ocean of resources, and look thru the 'latest' > spectacles, you'll only see the model consisting of all the 'latest' > resources. How do you combine this with trust? Let's say that a untrusted person updates the information. He revokes the earlier data and create a new version. If you say: $s->latest->get($person) it would get the person in the model produced by the latest() filter. If you put trust *AFTER* latest(): $s->latest->trust($my_list)->get($person) you could end up with nothing at al. The latest() filter will only return the latest triples, but some of those triples may be untrusted. You would have to create a combined filter because you want to get the latest trusted information. Maby like: $filtered_person = $s->filter( version => 'latest', trust => $my_list )->get($person) The returned person must be a filtered person. Subsequent calls to phone_number must use the same filter. Either that, or you have to supply the filter to every operation. I'm considering actualy have you submit a context variable wit every call. But that could be done implicitly with a thin uniqe filter object that encapsulate the real object. The real object would be cached and would hold all the data but the encapsuylating thin object would be new every time and contain the specific context of the call, to know what to filter out. The calling object is not enough context. > > We could base the version handling on statements bound to a point in > > time. Every statement belongs to a model and the model has a creation > > date (and maby should have a last-updated-date (in case for "open > > models")). > > > > The date information could be used to see what information is the most > > recent. But I could have two phone numbers so it wouldn't be right to > > just exclude one of the numbers if the other is more recent. The old > > number must be expired in some way. > > Actually, that's a rather interesting example. It illuminates the point that > it is not enough with f.ex. 'home phone'. And I still maintain that you > never 'change' a statement. You revoke an earlier statement, and make a new. > It kind of solves your problem, doesn't it? I think so. But there could be many agents revoking a statement. The person revoking the statement would often not be the same person that made the statement. That means that there is no cheap way to integrate that status in the system. It would be one full blown statement for each revoked statement. Or maby you would revoke an entire model. You could also collect the revoked statements in a collection. But that would realy hurt performance. For the DBI interface: could we catch most cases by assuming that there will usualy only be at most _one_ revokation per statement? Maby we could even let the person insert the revokation statement in the original model and by that only allow the model owner to revoke the statment? Think about the case there a statement has been revoked by an untrusted (anonymous?) agent. How can we handle that in an efficiant manner? > > I just ask for an efficient model for the implementation. > > Well. Based on my work with this kind of models in content managing, I'd say > that what you need is a 'created' - 'revoked' model, where you'd apply a > cached filter on what resources are 'created' but not 'revoked', these are > your current model. > (Actually, our CM model was a wee bit more complicated, as you had four > states: 'created', 'updated', 'published', 'revoked' to separate the two > levels of publishing - the level where only the author saw the changes, and > the level where everybody could see the changes.) Nothing stopping you from adding properties like "published". Now. Thinking about it: I have planned for many form of distributed properties. They can be distributed over uri-prefixes, collections or models. One soulution could be to distribute the revokation statement over the intended target. There are two things in this discussion: 1. How to represent VC (version control) in RDF::Service 2. How to reprecent VC in the DBI interface A requst for a property for a node will trigger the init_props() call to the involved interfaces. The type property are separatly handled by the init_types() call. I think that this is the most efficient way to do it. That means that if you are intrested in any property of a node, all properties will be retrieved. This will later be combined with "secondary properties" that will be initiated one by one, such as the dynamic properties. Maby we should allow the interface to not set up all the properties. But then we must have a way to know what has been returned. Let's say that the interface only return the latest version. How will the program know that there are other properties if another session wants to have all properties? Should we just make an exception for versions, or are there a general solution? Each interface can have it's own solution on how to store/handle versions. Some may not support versions. But the DBI interface is intended to be general purpouse. It could implement revoke statements by distributing them over the target statments, if there are more than one. > > > Actually - one could say 'version' roughly means 'sufficiently > > > equivalent', that is, 'all those instances could fill roughly the same > > > function, but with small, maybe critical, differences'. > > > > Ah. Now I think that I understand. > > Versioning points to the fact that you should be able to say 'this instance > is a sub-instance of this instance' a.k.a. 'version'. That dcan't be done if all you do is to revoke one statement and create another. That doesn't say that the nes statment is a version of the other one. > > You can produce two statements about diffrent things, but that > > contradict each other in some way. Which of the statements should we > > follow? > > The trick is to isolate the discrepancy - the very thing I was hoping we > could implement intelligently in WRAF. Well. If you have two models; some of the statements in the model could be about the same thing. It would be up to the constraints of the object to point aout that there exist a contradiction. The contradicting statments could turn up only after some logic machine has infered new statments from the original. But this doesn't sau how you will resolve the conflict. I think that this is the same problem as in DB replication. In one way or the other you choose the one to follow and the one to ignore. This could be done by authority, date or by just ask the agent or someone who has the authority to make the choice. But that can wait to a later stage. The question now is how to encode that one statement or model should be used instead of another (by the time that choice has been made). -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Thu Sep 28 10:17:35 2000 Date: 28 Sep 2000 11:17:35 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: RDF digest, Vol 1 #36 - 2 msgs (fwd) Dan Brickley writes: > On 25 Sep 2000, Jonas Liljegren wrote: > > > How do you represent anonymous resources? > > Internally generated identifiers are necessary for database management, > but if I don't know the 'real' URI for something I make sure I represent > that lack of knowledge. Then I use meta-knowledge about certain predicates > (eg. 'personalMailbox','corporateHomepage') to fold together nodes that > 'must' be the same because they share a property/value pair that implies > they are the self-same node... Statements ---------- Let's say you have two identical statements: S1: p1(s1,o1) S2: p1(s1,o1) If these two statements belongs to the same model, we could merge S2 into S1. But if they belongs to diffrent models (maby stated at diffrent times by diffrent agents) they are not the same stating and can not have the same URI. (I remember the discussion about the diffrence about the stating and the statement.) We may look at S1 and S2 (from diffrent models) as the same statement but diffrent statings. Subjects -------- Let's say we have: S1: p1(s1,o1) S2: p1(s2,o1) This could be resolved by cardinality metadata. If p1 only allow one subject for each object, you would have to resolve this in one way or the other. Maby one of the statements are false. If s1 and s2 are marked as autogenerated (and p1 has the said constraint) s2 could be merged into s1. But it *could* be that S2 is a false statement. You would also have to consider the authority for the two agents over the two subject namespaces. Here is one illustrating example: DB1: hasTheWorldRecordIn(Person1,Discus) DB2: hasTheWorldRecordIn(Person2,Discus) (I would normaly switch place for subj and obj here, and the same resoning holds for the same subj and diffrent objs, but we started the example with diffrent subjs.) What we see is that DB1 and DB2 has diffrent ideas about who the record holder is. If Person1 and Person2 has the same name and the same date of birth, we could probably say that they are the same person. But how much verification do we need to say that s1 and s2 are the same? I don't think that cardinality is enough for this. Literals -------- I have made a difference between static and dynamic literals; literals that allways stays the same and literals that could change their value. * A static literal resource represents the actual value. This value can be the value of many properties. These literals are actualy just normal resources that have a stored literal representation (and may have properties of its own). A static literal can represent a specific web page. It changes if the actual web page changes. * A dynamic literal represents the property for a specific resource. If the propery is the age of a specific resource, the literal would change continualy to represent the current age. But the literal URI would stay the same. ... You may know my view on literals: http://jonas.liljegren.org/perl/proj/rdf/schema_editor/letters/literals_3.txt This means that you can't merge literal URIs unless they are static literals. And how do you know if a literal is static or not? Maby another property for stating that? -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Thu Sep 28 16:38:54 2000 Date: 28 Sep 2000 17:38:54 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] ANNOUNCE: RDF::Service v0.01 The following message is a courtesy copy of an article that has been posted to comp.lang.perl.announce as well. The first alpha release of RDF::Service from the Wraf project http://www.uxn.nu/wraf/ has entered CPAN as file: $CPAN/authors/id/J/JO/JONAS/RDF-Service-0.01.tar.gz size: 41482 md5: 3eb77c161d902382ce3d51ccad61aea5 DESCRIPTION Wraf implements a RDF API that hopes to realize the Semantic Web. The framework uses RDF for data, user interface, modules and object methods. It uses interfaces to other sources in order to integrate all data in one enviroment, regardless of storage form. The homepage for Wraf is http://www.uxn.nu/wraf/ there you can find the developers mailinglist and more background information. Please send any comments to the developer mailinglist. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From rahul@reno.cis.upenn.edu Thu Sep 28 19:12:44 2000 Date: Thu, 28 Sep 2000 14:12:44 -0400 (EDT) From: Rahul Dave rahul@reno.cis.upenn.edu Subject: [RDF] Re: ANNOUNCE: RDF::Service v0.01 > Wraf implements a RDF API that hopes to realize the Semantic > Web. The framework uses RDF for data, user interface, modules and > object methods. Very intersting. I find the usage of RDF for object method and property representation particularly intriguing. It can lead to the creation of an object model with replaceable implementations of web services and property accessors. I rambled a bit about this in http://www.egroups.com/message/decentralization/237. The key point there is that an object model defined in RDF is extensible, and also queryable. So Newer methods, or services can be added by web sites to user's existing objects..and metadata can be combined across applications. >It uses interfaces to other sources in order to > integrate all data in one enviroment, regardless of storage form. Caching stored metadata obtained from the multiple sources will be needed to have efficiency. Any thoughts on whether a generic RDF db like RDFDB or some sort of object database which captures the model at a coarser granularity than individual triples is favorable? Rahul From jonas@liljegren.org Thu Sep 28 19:11:43 2000 Date: 28 Sep 2000 20:11:43 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: ANNOUNCE: RDF::Service v0.01 Dan Brickley writes: > cool! Any chance of a pointer from http://www.uxn.nu/wraf/ to the > API? (even if it's into the SourceForge CVS...) Not much documentation yet. And it will continue to change. Here is a list, but it doesn't say much: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/RDF-Service/doc/api.html?rev=1.3&content-type=text/html&cvsroot=wraf This says a little more: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/RDF-Service/doc/html/jumptable.html?rev=1.2&content-type=text/html&cvsroot=wraf But I think that its more easy to just look at the examples. This lists first and last name of all resources of type Person. I don't like the method names and will probably change them. [% FOREACH person = s.get("${NS_L}/Class#Person").objects_list %] [% END %]
[% person.get_objects_list("${NS_L}/Property#first_name").0.value %] [% person.get_objects_list("${NS_L}/Property#last_name").0.value %]
-- / Jonas - http://jonas.liljegren.org/myself/en/index.html From stefan@c64.org Thu Sep 28 20:51:11 2000 Date: Thu, 28 Sep 2000 21:51:11 +0200 From: Stefan Andersson stefan@c64.org Subject: SV: [RDF] Version handling Actually, I've just begun to read the book 'The User Illusion : Cutting Consciousness Down to Size' by Tor N=F6rretranders. (In swedish: ' M=E4rk V=E4rlden') - I've only gotten like 70 pages into it, but it is reeaaally interesting with regards to WRAF and the kinds of issues we're battling here. One of the main points in the book is that 'forgetting' information (and, I suppose, selecting) is more costly than obtaining it... and he makes the 1-to-1 connection between information and entropy. And actually touches on formulas as a strategy of battling 'entropy'. I've just realized that some of my presumptions with regards to 'information' and caching and what-have-you might have been wrong. Or at least too shallow. (But one of the things I think is more correct, is every viewers right to a subjective POV and _level_ of information - or personal degree of information entropy, so to speak. It is the _viewer_ that is the anchoring point, not the _model_.) Stay tuned. /Stefan Jonas Liljegren wrote: >=20 > Stefan Andersson writes: >=20 > > > The basic thing we want to do is to filter out previous versions of= a > > > statement. Let's say that I chnage the phone number. The old > > > statement remains but should not normaly be shown. > > > > Yeah, there is a few 'atomic' filters - 'current valid version (a.k.a. > > latest)' that deserves an extra optimization boost, but (as you know)= I > > think it's an interesting idea to think of a filter as a 'virtual mod= el', so > > you have this vast ocean of resources, and look thru the 'latest' > > spectacles, you'll only see the model consisting of all the 'latest' > > resources. >=20 > How do you combine this with trust? >=20 > Let's say that a untrusted person updates the information. He revokes > the earlier data and create a new version. >=20 > If you say: $s->latest->get($person) it would get the person in the > model produced by the latest() filter. If you put trust *AFTER* > latest(): $s->latest->trust($my_list)->get($person) you could end up > with nothing at al. The latest() filter will only return the latest > triples, but some of those triples may be untrusted. >=20 > You would have to create a combined filter because you want to get the > latest trusted information. Maby like: >=20 > $filtered_person =3D $s->filter( version =3D> 'latest', trust =3D> $my_= list )->get($person) >=20 > The returned person must be a filtered person. Subsequent calls to > phone_number must use the same filter. Either that, or you have to > supply the filter to every operation. >=20 > I'm considering actualy have you submit a context variable wit every > call. But that could be done implicitly with a thin uniqe filter > object that encapsulate the real object. The real object would be > cached and would hold all the data but the encapsuylating thin object > would be new every time and contain the specific context of the call, > to know what to filter out. The calling object is not enough context. >=20 > > > We could base the version handling on statements bound to a point i= n > > > time. Every statement belongs to a model and the model has a creat= ion > > > date (and maby should have a last-updated-date (in case for "open > > > models")). > > > > > > The date information could be used to see what information is the m= ost > > > recent. But I could have two phone numbers so it wouldn't be right= to > > > just exclude one of the numbers if the other is more recent. The o= ld > > > number must be expired in some way. > > > > Actually, that's a rather interesting example. It illuminates the poi= nt that > > it is not enough with f.ex. 'home phone'. And I still maintain that y= ou > > never 'change' a statement. You revoke an earlier statement, and make= a new. > > It kind of solves your problem, doesn't it? >=20 > I think so. >=20 > But there could be many agents revoking a statement. The person > revoking the statement would often not be the same person that made > the statement. That means that there is no cheap way to integrate > that status in the system. It would be one full blown statement for > each revoked statement. Or maby you would revoke an entire model. You > could also collect the revoked statements in a collection. But that > would realy hurt performance. >=20 > For the DBI interface: could we catch most cases by assuming that > there will usualy only be at most _one_ revokation per statement? >=20 > Maby we could even let the person insert the revokation statement in > the original model and by that only allow the model owner to revoke > the statment? >=20 > Think about the case there a statement has been revoked by an > untrusted (anonymous?) agent. How can we handle that in an efficiant > manner? >=20 > > > I just ask for an efficient model for the implementation. > > > > Well. Based on my work with this kind of models in content managing, = I'd say > > that what you need is a 'created' - 'revoked' model, where you'd appl= y a > > cached filter on what resources are 'created' but not 'revoked', thes= e are > > your current model. > > (Actually, our CM model was a wee bit more complicated, as you had fo= ur > > states: 'created', 'updated', 'published', 'revoked' to separate the = two > > levels of publishing - the level where only the author saw the change= s, and > > the level where everybody could see the changes.) >=20 > Nothing stopping you from adding properties like "published". >=20 > Now. Thinking about it: I have planned for many form of distributed > properties. They can be distributed over uri-prefixes, collections or > models. One soulution could be to distribute the revokation statement > over the intended target. >=20 > There are two things in this discussion: > 1. How to represent VC (version control) in RDF::Service > 2. How to reprecent VC in the DBI interface >=20 > A requst for a property for a node will trigger the init_props() call > to the involved interfaces. The type property are separatly handled > by the init_types() call. I think that this is the most efficient way > to do it. >=20 > That means that if you are intrested in any property of a node, all > properties will be retrieved. >=20 > This will later be combined with "secondary properties" that will be > initiated one by one, such as the dynamic properties. >=20 > Maby we should allow the interface to not set up all the properties. > But then we must have a way to know what has been returned. Let's say > that the interface only return the latest version. How will the > program know that there are other properties if another session wants > to have all properties? Should we just make an exception for > versions, or are there a general solution? >=20 > Each interface can have it's own solution on how to store/handle > versions. Some may not support versions. But the DBI interface is > intended to be general purpouse. It could implement revoke statements > by distributing them over the target statments, if there are more than > one. >=20 > > > > Actually - one could say 'version' roughly means 'sufficiently > > > > equivalent', that is, 'all those instances could fill roughly the= same > > > > function, but with small, maybe critical, differences'. > > > > > > Ah. Now I think that I understand. > > > > Versioning points to the fact that you should be able to say 'this in= stance > > is a sub-instance of this instance' a.k.a. 'version'. >=20 > That dcan't be done if all you do is to revoke one statement and > create another. That doesn't say that the nes statment is a version > of the other one. >=20 > > > You can produce two statements about diffrent things, but that > > > contradict each other in some way. Which of the statements should = we > > > follow? > > > > The trick is to isolate the discrepancy - the very thing I was hoping= we > > could implement intelligently in WRAF. >=20 > Well. If you have two models; some of the statements in the model > could be about the same thing. It would be up to the constraints of > the object to point aout that there exist a contradiction. The > contradicting statments could turn up only after some logic machine > has infered new statments from the original. >=20 > But this doesn't sau how you will resolve the conflict. I think that > this is the same problem as in DB replication. In one way or the > other you choose the one to follow and the one to ignore. This could > be done by authority, date or by just ask the agent or someone who has > the authority to make the choice. >=20 > But that can wait to a later stage. The question now is how to encode > that one statement or model should be used instead of another (by the > time that choice has been made). >=20 > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html >=20 > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@liljegren.org Fri Sep 29 08:12:16 2000 Date: 29 Sep 2000 09:12:16 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: SV: [RDF] Version handling Stefan Andersson writes: > Actually, I've just begun to read the book 'The User Illusion : Cutting > Consciousness Down to Size' by Tor N=F6rretranders. (In swedish: ' M=E4rk > V=E4rlden') - I've only gotten like 70 pages into it, but it is reeaaally > interesting with regards to WRAF and the kinds of issues we're battling > here. One of the main points in the book is that 'forgetting' > information (and, I suppose, selecting) is more costly than obtaining > it... and he makes the 1-to-1 connection between information and > entropy. And actually touches on formulas as a strategy of battling > 'entropy'. Would you like to explain why its so? > I've just realized that some of my presumptions with regards to > 'information' and caching and what-have-you might have been wrong. Or at > least too shallow. Which presumptions? > (But one of the things I think is more correct, is every viewers right > to a subjective POV and _level_ of information - or personal degree of > information entropy, so to speak. It is the _viewer_ that is the > anchoring point, not the _model_.) What effect does this have on the implementation? How will the agents POV influence, for example, the list of properties returned for a requested resource? How does this relate to the context thing we planning to include? ( Including session information, personal preferences and the accumulated filters from previous requests). --=20 / Jonas - http://jonas.liljegren.org/myself/en/index.html From alberto.reggiori@jrc.it Fri Sep 29 08:53:20 2000 Date: Fri, 29 Sep 2000 09:53:20 +0200 From: Alberto Reggiori alberto.reggiori@jrc.it Subject: [RDF] RDF::Service vs. RDF API I saw your announcement about RDF::Service and I found it very interesting because I am trying to build something similar using Perl TIE interface over a Berkeley DB TCP/IP based DBMS we built. I am just wondering now how all this WRAF work [1] relate to the proposed API draft of Sergey Melnik [2] and if there is a Perl implementation of it (a part pro-solutions one) I understand that the RDF::Service approach is a bit wider in scope (caching, CORBA DII like interface) but it seems to me that the main difference is about how you access/query the underling model. Any pointer to a discussion about it? What is good or bad of the two different views? Yours Alberto [1] http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/RDF-Service/doc/api.html?rev=1.3&content-type=text/html&cvsroot=wraf [2] http://www-db.stanford.edu/~melnik/rdf/api.html From jonas@liljegren.org Fri Sep 29 08:50:10 2000 Date: 29 Sep 2000 09:50:10 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: ANNOUNCE: RDF::Service v0.01 Rahul Dave writes: > > Wraf implements a RDF API that hopes to realize the Semantic > > Web. The framework uses RDF for data, user interface, modules and > > object methods. > > Very intersting. > > I find the usage of RDF for object method and property representation > particularly intriguing. It can lead to the creation of an object model > with replaceable implementations of web services and property accessors. > > I rambled a bit about this > in http://www.egroups.com/message/decentralization/237. Yes. That's what we have done here. > The key point there is that an object model defined in RDF is extensible, and > also queryable. The module is called RDF::Service because it's intended to function as a service deamon for requests. The key point here is that you dynamicly can plug in new interfaces. Each interface can define new methods for resources of specific types. Each interface can be specificaly designed for a certain information source and/or provide specialized methods for influencing something. There will be general and specialized interfaces against other RDF services and internet content. That means that a method call can be sent from one service to another. The interfaces register the things they handle. The Service dispatcher then sends each call to the right destinations. And since the interfaces, modules and functions in them self are resources, they can be transparently imported then they are needed. Lets say that a service tries to connect to a interface that doesn't exist on the server. The interface can be found and automaticly downloaded and stored in the locale chache, ready for execution. The same goes for new methods for a specific interface. This will result in completly transparent software upgrades. > So Newer methods, or services can be added by web sites > to user's existing objects..and metadata can be combined across applications. Yes. And with a little intelligent divition of the service work, a complex system could be distributed across several servers. > >It uses interfaces to other sources in order to > > integrate all data in one enviroment, regardless of storage form. > > Caching stored metadata obtained from the multiple sources will be needed > to have efficiency. Any thoughts on whether a generic RDF db like RDFDB or > some sort of object database which captures the model at a coarser granularity > than individual triples is favorable? The Wraf project tries to gain a little efficiency by optimizing for the common cases. RDFDB seems to be fast in it's simplicity. But we have a custom DB interface to gain flexability. >From an earlier message in the Wraf mailinglist archive: What RDFDB gives: * import/unimport RDF xml-files * insert/delete triples * a basic query language What RDFDB misses: * It does not bind statements to models * It does not make the 'fact' shortcut for reified statements * No alias mechanism * No container optimization * No support for uri prefixes * No support for blobs * No URI asignment for statement * No RDFS methods * No checking of duplicate statements The experience with the RDF Schema editor http://jonas.liljegren.org/perl/proj/rdf/schema_editor/ made us want to optimize for the most common case. That is: the realy heavy use of types and subClassOf and the constant use of label in the development enviroment. It does make it easy to import RDF data and to make queries. But it will not be a good place to store the bulk of the data from Wraf. So: I would like to have an interface to RDFDB. It may be a little easier to do some queries. But it doesn't cut back on the work we have to do. RDFDB is too limited to be used as the main storage interface. It should only be used with simple static data. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Fri Sep 29 11:04:11 2000 Date: 29 Sep 2000 12:04:11 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: RDF::Service vs. RDF API Alberto Reggiori writes: > I saw your announcement about RDF::Service and I found it very > interesting because I am trying to build something similar using Perl TIE > interface over a Berkeley DB TCP/IP based DBMS we built. Maby you would like to join the project? :) > I am just wondering now how all this WRAF work [1] > relate to the proposed API draft of Sergey Melnik [2] I have followed and participated in the API discussion from the first RADIX proposal. The API is influenced by this discussion. The API structure will be compatible. We will use moels and virtual models as the base for operations. We will have equivalent methods with the same name, like add(), contains(), create(), elements(), find(), etc. But the implementation will be done the Perl way. The basic operations uses the subject resource. In principal, we are trying to achive this: $person_email = $model->get($person_uri)->home->online->email->value; A property is a method is a property. Filters/specifiers/queries can be supplied along the call path: $person_name = $person->first_name(according_to=>$this_person)->value; > and if there is a Perl implementation of it (a part pro-solutions one) RDF::Service is a alpha release of the Wraf core module. It *is* working code. A sample CGI program is included. It uses the included RDF::Service::Interface::DBI::V01 to implement a simple person database. You can list, view, create, adit and delete person records. > I understand that the RDF::Service approach is a bit wider in scope (caching, CORBA > DII like interface) but it seems to me that the main difference is > about how you access/query the underling model. The implementation work is focused on the practical neads and goals of what we want to do. All the functionality will be implemented as needed. We will start with limited implementations and expand each aspect then this is required. The functions implemented are a direct result of what the example applications require. I just create the interface that I would like to use myself. And Perl lets me do just that. :-) > Any pointer to a discussion about it? Join the Wraf mailing list: http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf The archive can be find here: http://www.uxn.nu/pipermail/rdf/2000/thread.html > What is good or bad of the two different views? I think that the biggest diffrence between Wraf and other RDF implementations is the interface system that lets you combine many data sources. You can create interfaces to existing systems and authorized additions in the RDF::Service will directly update the backend system. > [1] http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/RDF-Service/doc/api.html?rev=1.3&content-type=text/html&cvsroot=wraf > [2] http://www-db.stanford.edu/~melnik/rdf/api.html -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From happiness@mise.to Mon Oct 2 07:09:48 2000 Date: Mon, 2 Oct 2000 15:09:48 +0900 From: =?iso-2022-jp?B?QnVzc2luZXNzIE9ORQ==?= happiness@mise.to Subject: [RDF] =?iso-2022-jp?B?GyRCJVshPCVgJVohPCU4PmUkR0dSOCtDVyQ3JF4kNyQ/ISMbKEI=?= $B=i$a$^$7$F(BBusiness one$B$H?=$7$^$9$3$NEY5.J}MM$N(B $B%"%I%l%9$r%M%C%H%5!<%U%#%sCf$KGR8+$$$?$7%a!<%kCW$7$^$7$?!#(B $B$I$3$N%5%$%H$G8+$D$1$?$+$b$*Ez$($G$-$^$9!#(B $B$3$N%a!<%k$,7h$7$FITFCDjB??t$KAw$i$l$F$$$k$H$O;W$o$J$$$G2<$5$$!#!#(B $B@'Hs$H$b2<5-$NMW7o$r$48!F$D:$-$?$/;W$$$^$9!#(B $BI,$:$*Lr$KN)$F$k$H;W$$$^$9!#(B $B3J0B%a!<%k%"%I%l%9:G=*2A3J(B100$BK|7o0l@Z%@%V$j$J$7$r(B15000$B1_$GDs6!CW$7$^$9(B!!! $B%[!<%`%Z!<%8$N%"%/%;%9?t$O>e$,$C$F$$$^$9$G$7$g$&$+(B? $B%$%s%?!<%M%C%H%S%8%M%9$r9T$&>e$G(BDM$B$O$D$-$b$N$G$9!#(B $BEvJ}?'!9$J=j$+$i%"%I%l%9$re$2$^$7$?!#(B $B$3$l0J>e$K0B$/$K$O$"$j$^$;$s(B $B%j%9%/$,7c8:$9$kAw?.$N;EJ}$NEy$*65$(CW$7$^$9!#(B $B$^$?$*$^$1Ey$b$D$1$5$;$FD:$-$^$9!#(B $B:#$,Gc$$;~$G$9!#@'Hs$4MxMQ2<$5$$!#(B $B$^$?J,3d$G$9$,(B 10$BK|7o(B1500$B1_$+$iAw%a!<%kEy2D(B)$B?6$j9~$_8}:B$N$_$G$9!#(B $BEvJ}$N=j;}$7$F$$$k%"%I%l%9$rGd$C$F$$$?$@$/$@$1$G$9!#(B $B%N%k%^Ey0l@Z$J$7!#(B $B5.J}MM$OL>Jm$r(B15000$B1_0J>e$GGd$j$^$9!#(B 50000$B1_$GGd$C$?>l9g(B35000$B1_$,(B $B5.J}$Nl9g$*5RMM$OEvJ}$K(B15000$B1_$r?6$j9~$_$^$9!#(B $B$=$7$FEvJ}$,%j%9%H$r0MMj52<$5$$!#(B $BBeM}E9EPO?$44uK>$NJ}$O2<5-$r%3%T!<$7(B $BHNGdBeM}E9EPO?$HL@5-$7JV?.2<$5$$!#(B $B!e5-$^$G(B) From jonas@liljegren.org Wed Oct 4 19:05:54 2000 Date: 04 Oct 2000 20:05:54 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] CVS update The latest version will handle multipple DBI interfaces. In order to work out the details, I connected to two DBI interfaces, using two diffrent database tables. All the basic functions (from the first alpha) now works in this situation. Next on the list is to change some of the function names to be more equal to Sergey Melniks Java RDF API. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Wed Oct 4 20:21:44 2000 Date: 04 Oct 2000 21:21:44 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] CVS update Jonas Liljegren writes: > Next on the list is to change some of the function names to be more > equal to Sergey Melniks Java RDF API. Uh. Forget about that. There arn't much that can be done equaly. These are, in my opinion, the core classes: http://www-db.stanford.edu/~melnik/rdf/api-doc/org/w3c/rdf/model/Model.html http://www-db.stanford.edu/~melnik/rdf/api-doc/org/w3c/rdf/model/NodeFactory.html Creating a literal: Java: literal = factory.createLiteral("My string"); Perl: $lit = $model->create_literal("My string"); Wraf places the literal directly in the calling model. Creating a resource: Java: resource = factory.createResource("http://a.b/c"); Perl: $node = $model->get("http://a.b/c"); Wraf retrieve the node if it exists and creates it if it doesn't exist. If no uri is specified, a unique uri is created, based on the model uri. That would be the same as the java createUniqueResource(). Creating a statement: Java: statement = factory.createStatement($subj, $pred, $obj); Perl: $arc = $model->add_arc($arc_uri, $pred, $subj, $obj); Let the $arc_uri be undefined to let the statement uri be autogenerated. As with all statements, the arcs is directly placed in the calling model. The find() method will be implemented later. Some of the other methods from the Model class can also be implemented. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Wed Oct 4 21:14:36 2000 Date: 04 Oct 2000 22:14:36 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Queries, filters, context, trust, and more... I will now try to write down what came up under the last discussion about Wraf with Stefan Andersson. Some of this builds on what has been said in a earlier message: http://www.uxn.nu/pipermail/rdf/2000/000118.html Let's say we have a P3P-like tree structure for person information: A --type--> Person A --contact--> B B --home--> C C --phone--> "0012345" You could (but not in the alpha version) get the phone number value by saying: $phone_str = $person->contact->home->phone->value; The person could have two home phone numbers. You shouldn't have to write: $phone_str = $person->contact->[0]->home->[0]->phone->[0]->value; This would be the first contact information (maby out of many sources), the first of the person home addresses, the first phone in that home. You shouldn't have to know exactly what the path to the information is. This will hopefully give the same answer: $phone_str = $person->phone->value; ... provided that the person only has one phone number. And you should be able to specify the properties of what it is you are requesting: $phone_str = $person->phone( destination => home )->value; The specified properties acts as a search criterion. Every resource object lives in the context of their retrieval. The original object is the service object, which is unique for each session. A session consist of the 'discussion' between the Service and the Agent. The metadata of the service object will contain information about what is known about the agent. This will include the starting time for the session and IP address. If the agent is authenticating itself to the service, there will be a lot of metadata. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Thu Oct 5 08:54:23 2000 Date: 05 Oct 2000 09:54:23 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Queries, filters, context, trust, and more.., part 2 Here are a couple of things to add to the feature list: Versioning, authorization and trust. Let's say that the person has a lot of phone numbers. - A person could say that the number has changed. The request should retrieve the latest number rather than the old incorrect number. - If the person stating that the number has changed is untrusted, we should instead retreive the previous number. - If the previous number is restricted, we would have to accept the later untrusted number. But we could also try to convince the service that we are authorized to recieve the restricted information. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From Stefan.Andersson@ullmans.com Thu Oct 5 09:21:18 2000 Date: Thu, 5 Oct 2000 10:21:18 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: [RDF] Queries, filters, context, trust, and more.., part 2 > Here are a couple of things to add to the feature list: Versioning, > authorization and trust. Yay! =20 > Let's say that the person has a lot of phone numbers. =20 >=20 > - A person could say that the number has changed. The request = should > retrieve the latest number rather than the old incorrect number. >=20 > - If the person stating that the number has changed is untrusted, we > should instead retreive the previous number. Actually - this is a case where a change in current affairs is = definitive. If I change my telephone number, I wouldn't want anybody to use my old number, which now goes to some other poor soul. I think that there are classes of changes. Something like: * This is a correction of an erroneous fact. The past fact has never = been correct. (I stated it, though. And that could be a relevant fact.) * This is an update. The past fact was correct, but as from now, the = new fact will be valid. It is a new version with respect to _time_. * This is a total change or addition. The past fact and the new has = nothing to do temporally with each other. It is a new version with respect to _function_ An example: Case 1: I have phone number A. I kill it. I have no phone. Then I have a new = phone number B. Case 2: I have phone number A. I add a new number B. Now I have two phone = numbers. Then I kill phone A. Case 3: I have phone number A. I let the phone company change it inte phone = number B. Case 4: I have phone number B. Now. The factual representation of all the (in the end) equivalent = cases will (most probably) be different. And think thru what happens when you query the cases at different points... I think there is an implicit _intentional_ layer on top of this. There = is a difference between these cases, not only in how far apart the actions = are. > - If the previous number is restricted, we would have to accept the > later untrusted number. But we could also try to convince the > service that we are authorized to recieve the restricted > information. This is the concept of inter-process _interaction_ - I'm currently = working on getting small, relatively dumb, mobile thingies act more intelligent = by means of _interacting_ with smarter, bigger, stationary thingies. /Stefan Stefan Andersson Ullman Communications Johannebergsgatan 30 412 55 G=F6teborg Tel: +46-31-708 26 13 Mail: stefan.andersson@ullmans.com From jonas@liljegren.org Thu Oct 5 19:24:34 2000 Date: 05 Oct 2000 20:24:34 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Encapsulating resources with the context Wraf stores the resource objects in a cache in order to save time and memory. The object holds the custom method jumptable and the information about all types and properties. But the list of methods, types and properties will be diffrent depending on which interfaces are used. It's up to each agent to declare the scope of the discussion by declaring what interfaces to use. This means that we cache one resource object (for a specific uri) for each combinatin of connected interfaces. (The order of connection specifies the chain of authority.) -- This is how the current CVS version works. The assumption here is that only a few combinations will be used, so that the same cache can be used by most of the sessions. Changes of what interface used will eventually be confined to updated versions of the core interfaces. > Every resource object lives in the context of their retrieval. The > original object is the service object, which is unique for each > session. A session consist of the 'discussion' between the Service > and the Agent. This would require unique objects for each session and even for each retrieval within the session. As a compromise, I will encapsulate the cached objects with a context wrapper. The context will hold pointers to the caller, the filters and the session. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Thu Oct 5 19:25:11 2000 Date: 05 Oct 2000 20:25:11 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Models and virtual models I think that there may be some difference in the interpretation of what a model is. We have to adopt some terminology. 1. A collection of statements with metadata about their origin (Model) 2. All resources mentioned in a statement collection (Virtual model) 3. All resources matching specified parameters (Virtual model) 4. A collection witch explicitly has a number of member resources (Container) 5. Some combinations of the above We could have used other names. Maby the virtual models could be called collections. But this is how I have used the words. This is the idea: Models and Virtual models are subClassOf Container. A virtual model will allways contain all matching resources. Every Interface is a virtual model of all the resources mentioned in all contained models. The Service object is a virtual model of all resources in the connected interface virtual models. All models are at the same time a virtual model of all contained resources. This means that the models and virtual models are (will be) used to constrain a search for resoruces. But each resource will still have all their properties, from all connected interfaces. And the get() method will allways get the resource, even if it's not containd in the model. All statements are tied to a model. The model says who the stater of the statement is. The inclusion of a statement in a virtual model does not mean that the virtual model stater has stated the included statements. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Fri Oct 6 18:49:10 2000 Date: 06 Oct 2000 19:49:10 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Transformation rules About implicit properties and translations Given the path $person->contact->home->phone->value > You shouldn't have to know exactly what the path to the information > is. This will hopefully give the same answer: > > $phone_str = $person->phone->value; > > ... provided that the person only has one phone number. This will probably depend on a lot of specified translation rules. The inference will result in implicit (second order) properties. A --type--> Person A --contact--> B B --home--> C C --phone--> D D --value--> "0012345" ==> A --phone--> D D --type--> Home contact phone number The same goes for the name: A --name--> E E --first--> F F --value--> 'Jonas' E --last--> G G --value--> 'Liljegren' ==> E --value--> H H --value--> 'Jonas Liljegren' H --type--> Full Name E --value--> I I --value--> 'Jonas' I --type--> First Name A litral resource always has a value property. That nice paradox let's you separate multiple values by their metadata. Since the method value() is used to (recursively if necessery) retrieve the contained data, we would have to use another method, value_li(), to get the actual resource. $res->value_li() will most of the time point back to $res, allowing you to do strange things like $literal->value_li->value_li->value_li->value. How to actualy specify the transformation rules is beyond the scope for Wraf 1.0. This is just some preliminary plans for 2.0 -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Fri Oct 6 17:59:30 2000 Date: 06 Oct 2000 18:59:30 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Queries, filters, context, trust, and more... And now the conclusion. :-) Jonas Liljegren writes: > Let's say we have a P3P-like tree structure for person information: > > A --type--> Person > A --contact--> B > B --home--> C > C --phone--> "0012345" > The person could have two home phone numbers. You shouldn't have to > write: > > $phone_str = $person->contact->[0]->home->[0]->phone->[0]->value; > > This would be the first contact information (maby out of many > sources), the first of the person home addresses, the first phone in > that home. The key here is the diffrence between the wanted answer and the availible answer. For every question, you would expect none, one, some or all answers. A query for a specific resource could specify the wanted properties for that resource. As an example: "Give me the resource of type Person with the name 'Jonas'." $res = $selection->node( type => $Person, name => 'Jonas' ); In addition to the local explicit properties, you will have general default "expectations" inherited from the parent context. These will include the preference to get the version of the answer believed to be the correct one, and that you want to know what is true in this time rather than some past or future time. The agent preferences will be used in every session. The session preferences will state the contect for the current discussion. But what is the expection on the format of the result? How many results do we expect? But first: what formats *can* we send? Let's say we want the phone number: $number = $persons->node( name => 'Jonas' )->phone; There can be any number of 'Jonas' with any number of phone numbers each. The possible answers partly depends on the number of matches. With one match we could: 1. Return the literal resource 2. Return the literal value 3. Return a list of literal resources 4. Return a list of literal values 5. Return a selection containing the literal resource 6. Return info about the number of matches 7. Try to increase or decrease the number of matches by applying more preferences 8. Ask caller for more/less restrictive parameters If there are two matching persons with possibly several phone numbers each, we could, in addition to the above, return trees or trimmed trees. 9. Construct metadata for each matched person about how that person matched the phone number query. Return a selection of the matched persons. 10. Return a complete XML serialized model with the whole tree of the matched information. 11. Return the matched information as a perl hash tree 12. Return only the first nth levels of the tree The detail of how this will function with a HTML user interface depends on the SDL (presentation schema) that will be implemented at a later stage. In this stage, we will focus on items 1-6 for any combination of none or more matches at any part of the tree. These are the general responses: No such property: return undef No such resource: Throw an exception More than one match: Throw an exception 1. Return the literal resource $number = $persons->node( name => 'Jonas' )->phone->li; The li "dynamic" property is used to get a specific resource from a container. In this case, the selection resulting from the search on phone. li() without a parameter will get item 0 but throw an exception if there are more than one item. One match: Return the resource object 2. Return the literal value $number = $persons->node( name => 'Jonas' )->phone->value; All resources of type Literal has the content availible with the value() method. One match: Return the value 3. Return a list of literal resources $numbers = $persons->node( name => 'Jonas' )->phone->list; The list() method returns a list with all the resources in the selection. This _could_ be implemented by binding the list to a custom class, making it internally function like an enumeration / iterator. Any number of matches, including no property: Return the list No such resource: Throw an exception 4. Return a list of literal values $numbers = $persons->node( name => 'Jonas' )->phone->value_list; The value_list() method returns a list with all the literal values in the selection. Any number of matches, including no property: Return the list No such resource: Throw an exception 5. Return a selection containing the literal $numbers = $persons->node( name => 'Jonas' )->phone Since this is the default, theres not much to say... 6. Return info about the number of matches $numbers = $persons->node( name => 'Jonas' )->phone->size Exceptions: Exceptions will be thrown in the form of a resource object containing the information about what happend. Each caller in the path can handle the exception with the help of the context information. A simple case for this would be then you want to get Jonas' phone number, but there are two jonas. The exception object will say that the selection (of persons named jonas) has more than one item, and it will point to the selection resource. This would typicaly be handled by listing the resources and letting the user chose one of them. But that's up to the agent. To be continued... -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Sat Oct 7 21:22:13 2000 Date: 07 Oct 2000 22:22:13 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Models and virtual models Hmm... While thinking about it. I don't think it's right to call the virtual models for virtual models. Any other suggestions? "Selection" maby? I will go with "selection" unless something better comes up. Jonas Liljegren writes: > I think that there may be some difference in the interpretation of > what a model is. We have to adopt some terminology. > > 1. A collection of statements with metadata about their origin (Model) > > 2. All resources mentioned in a statement collection (Virtual model) > > 3. All resources matching specified parameters (Virtual model) > > 4. A collection witch explicitly has a number of member resources (Container) > > 5. Some combinations of the above > > We could have used other names. Maby the virtual models could be > called collections. But this is how I have used the words. > > This is the idea: > > Models and Virtual models are subClassOf Container. A virtual model > will allways contain all matching resources. Every Interface is a > virtual model of all the resources mentioned in all contained models. > The Service object is a virtual model of all resources in the > connected interface virtual models. All models are at the same time a > virtual model of all contained resources. > > This means that the models and virtual models are (will be) used to > constrain a search for resoruces. But each resource will still have > all their properties, from all connected interfaces. And the get() > method will allways get the resource, even if it's not containd in the > model. > > All statements are tied to a model. The model says who the stater of > the statement is. The inclusion of a statement in a virtual model > does not mean that the virtual model stater has stated the included > statements. > > -- > / Jonas - http://jonas.liljegren.org/myself/en/index.html > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Sat Oct 7 23:31:18 2000 Date: 08 Oct 2000 00:31:18 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: SV: [RDF] Queries, filters, context, trust, and more.., part 2 Stefan Andersson writes: > > Let's say that the person has a lot of phone numbers. > > > > - A person could say that the number has changed. The request should > > retrieve the latest number rather than the old incorrect number. > > > > - If the person stating that the number has changed is untrusted, we > > should instead retreive the previous number. > > Actually - this is a case where a change in current affairs is definitive. > If I change my telephone number, I wouldn't want anybody to use my old > number, which now goes to some other poor soul. > > I think that there are classes of changes. Something like: Yes. > * This is a correction of an erroneous fact. The past fact has never been > correct. (I stated it, though. And that could be a relevant fact.) > * This is an update. The past fact was correct, but as from now, the new > fact will be valid. It is a new version with respect to _time_. > * This is a total change or addition. The past fact and the new has nothing > to do temporally with each other. It is a new version with respect to > _function_ What do you mean here? > An example: > Case 1: > I have phone number A. I kill it. I have no phone. Then I have a new phone > number B. > Case 2: > I have phone number A. I add a new number B. Now I have two phone numbers. > Then I kill phone A. > Case 3: > I have phone number A. I let the phone company change it inte phone number > B. > Case 4: > I have phone number B. > > Now. The factual representation of all the (in the end) equivalent cases > will (most probably) be different. And think thru what happens when you > query the cases at different points... > > I think there is an implicit _intentional_ layer on top of this. There is a > difference between these cases, not only in how far apart the actions are. The most importent thing I'm trying to do now is to determine how the data must be structured in order to efficiently handle these types of filterings or queries. We will hopefully find a generic representation that will work equally well with any other sort of filtering. The structure should handle resources with a large number of properties. (In fact, there could theoreticaly be a infinite number of properties.) Most agents will only be intrested in a small subset of the properties. This means that interfaces should not have to send all data to the service. But it should still send data that would probably be requested later. - We have to remember if a property has been imported or not. ... I think it's clear how to do that. The other thing is the internal chaching of the properties. There could be any number of lookup tables. Each type of question will best be presented in a specialized lookup table. Somehow, we have to dynamicly detect the common types of questions and build lookup tables to handle them. Any suggestions on how to do this? > > - If the previous number is restricted, we would have to accept the > > later untrusted number. But we could also try to convince the > > service that we are authorized to recieve the restricted > > information. > > This is the concept of inter-process _interaction_ - I'm currently working > on getting small, relatively dumb, mobile thingies act more intelligent by > means of _interacting_ with smarter, bigger, stationary thingies. As I have written in a earlier post, I think I know how to do this: in the form of exception resouce objects. In practice this means that there will be two types of responses: the expected and the unexpected. This solves the problem with how a requst for a literal value string can return a counter-request for more information. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Mon Oct 9 20:42:11 2000 Date: 09 Oct 2000 21:42:11 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] The query API This long (disroganized) letter is another step towards finalizing the API and the internal storage of the triples. I have in previous messages used queries in this form $res = $selection->li( type => $Person, name => 'Jonas' ); The wanted properties of the node is specified as arguments. THE INTERNAL STORAGE -------------------- The internal representation of the RDF data is separated from the interfaces storage format. We have to develop a way to quickly access the data retrieved from the interfaces. (Another important property of the internal cache is that it should remember all places there a resource is used, in order to update it then necessary. But that's another story.) The choice of internal storage format is dependent on what queries to support. It's time to flesh out the query API. The current (alpha 1) storage is in the form { Sub -> Pred -> Obj }. That allow us to find all predicates for a resource and all objects given a specific subject and predicate. For only basic statement lookups, we have these combinations: S -> P -> O S -> O -> P P -> S -> O P -> O -> S O -> S -> P O -> P -> S But we want to do much more than these basic lookups. The above example could use { Selection -> Type -> Name } or more generic { Selection -> Type -> Pred -> Arc }. The selection here is a container of subjects. Internally, the contents of selections can be stored as one or more subqueries. The atomic parts of a selection (formely called virtual model) is Interface, Model, Resouce and Subselection. This will (sometimes) save a lot of time and space, because we don't have to know exactly what resources are containd in a selection until the agent actualy wants to iterate through the members or determine an exact size. An example of piling selections: $interface->select( type=>$Person )->select( memberOf=>$Group )->select( livesIn=>$Country )->name; Would be the same as: $service->select( interface=>$interface, type=>$Person, memberOf=>$Group, livesIn=>$Country )->name; The selection could use any combination of properties. There are many little things that can be done to make efficient selections. There will be the same types of considerations as in the optimizations of a database SQL query optimization. There are more types of queries than the above cases. (We haven't mentioned 'OR' or 'NOT' yet.) But the important thing is that the data storage is general enough to allow for more advanced implementations in a later stage. COMPARSION WITH ALPHA 1 API --------------------------- Let us now list some of the basic queries implemented in the alpha 1, and make a few additions for the simplest cases of versioning and trust. (The digital signatures part is a question of authentication (and integrity) and can be separated from the trust question.) $preds = $node->get_preds_list() $arcs = $node->get_arcs_list() These should maby be replaced with { $node->arc->list } to get all the arcs there $node is subj, and { $node->rev_arc->list } for arcs there $node is obj. Maby a construction like { $node->arc->pred->list } to get all the arcs predicates. $objs = $node->get_objects_list($pred) This is to get all objects for all arcs with a specified subject and predicate. This should be changed to { $node->arc($pred)->obj->list } for the case of a variable predicate, as a equivalent to { $node->thePred->list }. Maby we could use { $node->arc_obj( rev_arc => { pred => $pred } )->list } as an alternative, or { $node->arc_obj( $pred )->list } as a shorter version. $nodes = $class->objects_list() This is a realy bad name. how do we distinguish getting all objects of a specific class with all objects in a nodes property arcs? This should change to { $class->rev_arc($Type)->list }. All the implicit types will be expanded. Maby we could use a shortcut here { $class->rev_type->list } and use { $node->type->list } to get a nodes types. Maby 'rev_...' could be used for any property? VERSIONING ---------- We want to get statements that are 1. correct and 2. current. A statement (or all statements in a model) can be withdrawn. TBL suggests the property truth for a model [1]. To get true properties of a node we could say { $node->arc( truth => 1 )->list } or maby, if we doesn't distribute the model truthness, { $node->arc( model => {truth => 1} )->list }. To get the true english name of a thing, we could say { $thing->arc( pred => $name, truth => 1 )->obj( lang => $english )->value }. The preference for true statements will probably be default. So we could say { $thing->name( lang => $english )->value } instead. And with a prespecified preference for english versions, we could say { $thing->name->value }. The second type of versioning says that some statement is true during a specific time period. So let us specify that we want to know the properties of a thing, as it was in 1999. { $thing->arc( valid_during => $date_range )->list }. All this is dependent on that we decide on how to describe dates, and more. The 'valid_during' talks about the arc and not the object. The valid_during can be dynamicly calculated from other properties; for example from the model. TRUST ----- Sometimes we only want trusted data. Other times, we want to see all data and decide for ourself. We cold then just get all data and order on trust. We can also specify a orderd list of prefered sources. (As with the desired language.) The details of inerited trust will be datailed later. For now, we just look at the agent behind a model containing a statement. We could check it agains the list of trusted agents by saying { $node->arc( model => { agent => [ $agent1, $agent2, $agent3 ] } ) }. But the default preference will be to only get true statements, and that will imply that they are trusted and current. The handling of trust must be efficient even with a large amount of trusted sources. Let's say we have a third party service saying what models, agents or namespaces we can trust. This would be done by a interface defining the trust() method/property and could be used by saying { $node->arc( trusted => 1 ) }. That will call the trusted() method once for every arc of the node. It's up to the interface implementing the method to do what it have to do to be fast. The property trusted() are an example of properties that have diffrent values depending on the context. The defining context must be clear. In this case, the property will probably be based on the agent of the session. This means that the session agent will be used in the caching. This problem is related to the implementation of inferenced properties. For now, we will just let the methods do their job on returning the right value, without caching the result. SYNTAX SUMMARY -------------- Properties can be used in the place of predicates either as criterions or as method names. For a property to be used in this way, they have to be declared as the abbrevation of their full URI. Return a selection of all arcs with $node as subj: $node->arc() Return a selection of all arcs with $node as subj and $pred as pred: $node->arc($pred) Return a selection of all arcs with $node as subj and one of $pred1, pred2 or $pred3 as pred $node->arc([$pred1, $pred2, $pred3]) Return a selection of all arcs with $node as subj, $pred as pred and that has a property with the key $x and value $y. All the criterions must be matched: $node->arc( pred => $pred, $x => $y ) The property $x must have the value of *either* $y or $z: $node->arc( $x => [ $y, $z ] ); I hope that this is much more pover than actualy needed in practical use. This would be the same as "for each arc that has node as subject, return all arcs for which the following is true; ( ( (P(a)==b) OR ( (P(c)==d) AND (P(e)==f) ) ) AND ( (P(g)==h) ) )". $node->arc( [{ $a=>$b },{ $c=>$d, $e=>$f }],[ $g=>$h ] ) Return all arcs that has a property $a those value is a resource that has the property $b with the value $c: $node->arc( $a => { $b => $c } ) The same, but create the section as the union of the result from each nodes in the parent selection: $selection->arc(...) The same, but substitute the subj with the obj: $selection->rev_arc(...) Return object (and *not* a selection) (matching the criterions) of an arc: $arc->obj(...) Return all objects of all arcs that has $node as subj: $node->arc_obj() Return all objects that has a reverse arc with $pred as predicate and $node as subj. That is the same as "all the values of the $node property $pred": $node->arc_obj( $pred ) Same as arc_obj, but substitute obj with subj: $node->arc_subj( $pred ) Return the only match from a container (or selection), or die: $container->li() Return element 8 (counting from 1) in the container: $container->li( 8 ) Return the only resource from a container matching the citerions, or die if there was many matches: $container->li( ... ) Return a selection of containers (including models and selections) matching the specified criterions and including this $node: $node->rev_li( ... ) The same as li() but returns a selection instead of a single resource: $container->select( ... ) Return all objects of the arcs that has $node as subj and XXX as pred, matching the specified criterions. XXX here is any predicate registred as an abbrevation: $node->XXX( ... ) The same as XXX() but substitute subj with obj: $node->rev_XXXX( ... ) [1] http://www.w3.org/DesignIssues/Toolbox.html#Assertion -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Mon Oct 9 20:52:26 2000 Date: 09 Oct 2000 21:52:26 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] The query API And now for the first revision. D'oh! > I hope that this is much more pover than actualy needed in practical > use. This would be the same as "for each arc that has node as > subject, return all arcs for which the following is true; ( ( > (P(a)==b) OR ( (P(c)==d) AND (P(e)==f) ) ) AND ( (P(g)==h) ) )". > > $node->arc( [{ $a=>$b },{ $c=>$d, $e=>$f }],[ $g=>$h ] ) Well. The above stands (for now). But I want to make a note on how to say that, for example, the selection must be of two types: $selection->select( [ type => $a ], [ type => $b ] ) The [] must be there because hashes in perl have unique keys. The other thing is the note about priorritized alternatives. How to say that you want only the best matches, given a plain prioritized list. But more on that later. -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@liljegren.org Tue Oct 10 13:03:10 2000 Date: 10 Oct 2000 14:03:10 +0200 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Revised project plan Prototype case one: Address register DONE - Add properties DONE - View all properties for person DONE - Create a web HTML interface to register DONE - Remove/change statements --- (alpha 1) - Context wrappers for objects - Selections for searches - minimal arc(), arc_obj() and rev_type() - list() and li() --- (alpha 2) - c/s architecture - callbacks to updated cache on changes in the source --- (alpha 3) - multipple criterions - sub criterions - alternative lists --- (alpha 4) - criterions in context - Session metadata - User identification --- (alpha 5) - Model authority - authenticated change/delete - distributive properties --- (alpha 6) - minimal SDL general presentation framework - minimal inference/translation rules --- (alpha 7) - Generalize prototyp application - Set official schema URIs --- (beta 1) Post 1.0: - Adaptive internal data storage - Query optimization engine - HTTP interface - XML import/export interface - translation rules - Complete SDL - DSIG - Function / property equality - Advanced cache control - Inter-service communication - ... -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From jonas@rit.se Tue Oct 17 10:34:58 2000 Date: 17 Oct 2000 11:34:58 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Property dependencies for dynamic cache control Welcome to a new confusing post from the idealistic dreamer. :-) Writing to the list helps me organize my thoughts. And it feels like sombody cares about what i think. But I would still be glad to here more comments from you, the subscribers. This is an open list. Maby write about what about Wraf intrests you? I would also appreciate help with the terminology. (translation, callback, inference, dependencies, implicit properties, dynamic properties, questions, invalidation, and more...) (... The CVS version now have the context wrapper. Next on the list is the selection containers used in the API.) Ok. I didn't expect to run into this so soon. But I have to work out the details for this now. DYNAMIC PROPERTIES ------------------ If a property is calculated from another property, we will have to recalculate the property if the property it depends on is changed. So far, I have treated types as a special case. Not because they are fundamentally diffrent, but because I believe the implementation will be faster. It includes the creation of dynamic properties for indirect types. Every resource is implicitly of type Resource, even if the model doesn't say so. More implicit types comes as an effect of subClassOf properties. Introductory example: #A --fullname--> 'J L' #A --firstname--> 'J' #A --lastname--> 'L' The fullname of #A could be said to be dependent on firstname and lastname. Are they dependent on the literals, the statements or maby on some way the properties? The main example: #1: #A --subClassOf--> #B #2: #B --subClassOf--> #C #3: #A --subClassOf--> #C Statement #3 follows from #1 and #2. This means that #3 is dependent on #1 and #2. But that is not enough to answer { $myclass->subClassOf->list }. The question depends not only on all the curent subClassOf properties, but on *all* subClassOf properties for the resource. CREATION TRIGGERS ----------------- This calls for some sort of statement creation callback... (The discussion here is about all properties. subClassOf is only used as an illustration / testcase.) Each interface can contribute with part of the answer to the question. This is presently done by a call to init_props() for the subject. This will be generalized to allow initialization for just some properties and/or one by one. This will eventually be done by the individual calls to, for example, subClassOf(). After each interface has returned their part of the list of subClassOf statements, the callback must be activated in order to complement this list with the subClassOf statements inferenced from the other statements. The subClassOf will infer the value from each objects subClassOf properties, which will recursively call the higher level up to the top. But what should be done if two diffrent interfaces both hook up to subClassOf statements creations? The callback should only add subClassOf statements and not statements with other properties. I guess that the correct thing to do is to call both callbacks and do it one more time if any of the callbacks added another statement for the subject. Both the callbacks will register register dependencies in each of the statements used for each of the inferred statements. This will insure that a deletion of a source statemnt will invalidate the dependent statement. DEPTH OF SEARCH ---------------- On top on this; we will have things like "depth of search". Some questions will be pursued in greate depth and other questions will be taken lightly. Some dependencies will be forced in realtime while other will be resolved in batches oncen in a while. Just take foreign models as an example. They reside on other servers and, if not closed, could change at any time. The http cache directives tells us then to time out the cache and make a new retrieval. Another example is the translation rules. You can apply all known translation rules and get a whole lot of new properties. These could serve as input for another run of the translation rules. This could go on in the same manner as a chess computer examines the question about what the winning move is. We have to draw the line somewhere. I will keep a nesting counter as a safegaurd for cyclic dependencies in the program. It can act as a simple "depth of search". Looping class inheritance should be catched by the "nothig new here" rule. But other problems could be catched by the nesting counter. THE MODEL OF INFERED STATEMENTS ------------------------------- What will be the model of the inferenced statements? The translation rule belongs to a schma/model. The source statements belongs to their respective models. None of the models actualy says that the infered statement is true. The schema can only say that "this is true provided that the dependent statements are also true". The inferenced subClassOf statements will be owned/stated by the RDFS schema, not as "facts" but as reified statemnts. But that means that the actual statement doesn't have a model at all. Hmm. Let's introduce the Anonymous model. Since these inferenced statements will be mind-bogglingly common, it would be bad to have to represent the dependencies explicitly. They will be stored for efficient handling in the internal cache and be represented outwardly as statements by the schema. It could be done by setting a flag for the statement, marking it as a inferenced statement from the schema model. Or we could create a new model with the said relationship with the schema model. DEEP DEPENDENCIES ----------------- A statement dependent on a statement involving a literal is also dependent on the actual value of the literal. This dependency is of the same type as a dependency on a part of a tree. Say for example that one statement is dependent on the contact information and that the contact information is made up of several substatements. A change in any of the substatements could invalidate the dependent statement. This will be solved by having two types of dependencies. You can depend either on specific statements or on all statements of a selection, including models. A removed or added statement (including changed literal) will check for dependent statements hooked to the statement, the statements subject, all the subjects selections including its model. And this brings us back to the { $myclass->subClassOf->list } question. The answer is dependent on the selection { $myclass->subClassOf }. This is dependent on all subClassOf statements for the subject. A new statement invalidates the cached response. (But that's not the same as the construction trigger discussed in 'the solution' section.) And now back to some real Wraf hacking. ;-) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Fri Oct 20 09:27:50 2000 Date: 20 Oct 2000 10:27:50 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] CVS update Hello! :-) I have started to implement the API I have described. I start with minimal implementations, without any support for expanded criterions. The API text has been updated to be more general. In summary: Elements in [] are ORed together and pairs in {} are ANDed together. The special props { and => [...] } and { or => {} } changes that behaviour. { not => [...] } and { not => {...} } negates the effect of [] and {}. The current CVS version has implemented rev_type(), arc_subj() and list() with the background support of init_rev_types(), init_rev_props(), declare_selection() and declare_add_rev_types(). The other methods will be replaced shortly. I have realy only replaced the first row in the template code below. I have updated the debug output. It's now easier to follow what's happens internally. This is what happens if you, in the test program, lists the two persons. This is the TT code: [% persons = s.get("${NS_L}/Class#Person").rev_type.list %] [% FOREACH person = persons %] [% END %]
[% person.get_objects_list("${NS_L}/Property#first_name").0.value %] [% person.get_objects_list("${NS_L}/Property#last_name").0.value %]
The program starts by connecting to the interfaces. We are using two DBI interfaces in order to see how well it works with information distributed over several sources: our $s = new RDF::Service( NS_L."/service/R1" ); $s->connect("RDF::Service::Interface::Schema::RDFS_200001"); our $ia = $s->connect("RDF::Service::Interface::DBI::V01", { connect => "dbi:Pg:dbname=wraf_v01a", name => "wwwdata", }); our $ib = $s->connect("RDF::Service::Interface::DBI::V01", { connect => "dbi:Pg:dbname=wraf_v01b", name => "wwwdata", }); And here is the debug output (using verbose level 1). The '0' and '1' numbers to the left of the method name indicates which interface is being called. The number a bit to the right of the method name is a counter to see how many times a certan method is called. The first row under the method name row states the resource making the call. Additional rows will indicate the parameters to the method. /~~ new RDF::Service 1 | /~~ declare_model 1 | | http://uxn.nu/rdf/2000/09/19/local/service/R1 | | /~~ declare_add_types 1 | | | http://uxn.nu/rdf/2000/09/19/local/service/R1/20001020T100827-001 | | \__ declare_add_types | \__ declare_model | Bootstrap | Registring RDF/Service/Interface/Base/V01.pm \__ new RDF::Service Conneting to the schema /~~ 0 connect 1 | http://uxn.nu/rdf/2000/09/19/local/service/R1 | Registring RDF/Service/Interface/Schema/RDFS_200001.pm \__ 0 connect /~~ 0 connect 2 | http://uxn.nu/rdf/2000/09/19/local/service/R1 | Registring RDF/Service/Interface/DBI/V01.pm \__ 0 connect /~~ 0 connect 3 | http://uxn.nu/rdf/2000/09/19/local/service/R1 | Registring RDF/Service/Interface/DBI/V01.pm \__ 0 connect /~~ rev_type 1 | http://uxn.nu/rdf/2000/09/19/local/Class#Person | /~~ 0 init_types 1 | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | Types for http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 0 init_types | /~~ 1 init_types 2 | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | /~~ declare_add_types 2 | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/Class#Person: --no value-- | | \__ declare_add_types | | Types for http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Class | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 1 init_types | /~~ 0 init_rev_types 1 | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | /~~ declare_add_rev_types 1 | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | Adding http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | | ..Finding implicit rev_types | | | /~~ arc_subj 1 | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | ( http://www.w3.org/2000/01/rdf-schema#subClassOf ) | | | | /~~ 0 init_rev_props 1 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | Fetching rev_props | | | | \__ 0 init_rev_props | | | | /~~ 1 init_rev_props 2 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | Fetching rev_props | | | | \__ 1 init_rev_props | | | | /~~ declare_selection 1 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | ( ) | | | | | /~~ declare_add_types 3 | | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-001 | | | | | | /~~ get_objects_list 1 | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) | | | | | | | /~~ 0 init_types 3 | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | Types for http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | ..http://www.w3.org/2000/01/rdf-schema#Resource | | | | | | | \__ 0 init_types | | | | | | | /~~ 1 init_types 4 | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | Types for http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | ..http://www.w3.org/2000/01/rdf-schema#Resource | | | | | | | \__ 1 init_types | | | | | | | /~~ 0 init_props 1 | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | Fetching props | | | | | | | \__ 0 init_props | | | | | | | /~~ 1 init_props 2 | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | | Fetching props | | | | | | | \__ 1 init_props | | | | | | \__ get_objects_list | | | | | \__ declare_add_types | | | | \__ declare_selection | | | \__ arc_subj | | | Returning a list of 0 resources | | | ..Finding done | | \__ declare_add_rev_types | | /~~ declare_add_rev_types 2 | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | Adding http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | | ..Finding implicit rev_types | | | /~~ arc_subj 2 | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | ( http://www.w3.org/2000/01/rdf-schema#subClassOf ) | | | | /~~ declare_selection 2 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | ( ) | | | | | /~~ declare_add_types 4 | | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-002 | | | | | | /~~ get_objects_list 2 | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) | | | | | | \__ get_objects_list | | | | | \__ declare_add_types | | | | \__ declare_selection | | | \__ arc_subj | | | Returning a list of 0 resources | | | ..Finding done | | \__ declare_add_rev_types | \__ 0 init_rev_types | /~~ 1 init_rev_types 2 | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | \__ 1 init_rev_types | /~~ declare_selection 3 | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ( http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 ) | | /~~ declare_add_types 5 | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-003 | | | /~~ get_objects_list 3 | | | | http://uxn.nu/rdf/2000/09/19/local#Selection | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) | | | \__ get_objects_list | | \__ declare_add_types | \__ declare_selection \__ rev_type Returning a list of 2 resources /~~ get_objects_list 4 | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | (http://uxn.nu/rdf/2000/09/19/local/Property#first_name) | /~~ 0 init_types 5 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | /~~ declare_add_types 6 | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | | /~~ get_objects_list 5 | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) | | | | /~~ 0 init_props 3 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | RDFS init_props_class RDF::Service::Resource=ARRAY(0x85fa31c) | | | | \__ 0 init_props | | | | /~~ 1 init_props 4 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | Fetching props | | | | \__ 1 init_props | | | | /~~ 2 init_props 5 | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | | Fetching props | | | | \__ 2 init_props | | | \__ get_objects_list | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003: --no value-- | | \__ declare_add_types | | Types for http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 0 init_types | /~~ 1 init_types 6 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | Types for http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 1 init_types | /~~ 0 init_props 6 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | Fetching props | | ..Found a RDF::Service::Resource=ARRAY(0x85d7ce0) | | /~~ declare_arc 1 | | | http://uxn.nu/rdf/2000/09/19/local#M1 | | | P http://uxn.nu/rdf/2000/09/19/local/Property#first_name | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | | | /~~ declare_add_types 7 | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-003 | | | \__ declare_add_types | | \__ declare_arc | | ..Found a RDF::Service::Resource=ARRAY(0x85d2890) | | /~~ declare_arc 2 | | | http://uxn.nu/rdf/2000/09/19/local#M1 | | | P http://uxn.nu/rdf/2000/09/19/local/Property#last_name | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | | | /~~ declare_add_types 8 | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-004 | | | \__ declare_add_types | | \__ declare_arc | \__ 0 init_props | /~~ 1 init_props 7 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | | Fetching props | \__ 1 init_props | /~~ 0 obj 1 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-003 | \__ 0 obj \__ get_objects_list /~~ 0 init_types 7 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | /~~ declare_add_types 9 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004: --no value-- | \__ declare_add_types | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 0 init_types /~~ 1 init_types 8 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 1 init_types /~~ 0 value 1 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | /~~ 0 init_props 8 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | | Fetching props | \__ 0 init_props | /~~ 1 init_props 9 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 | | Fetching props | \__ 1 init_props \__ 0 value /~~ get_objects_list 6 | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 | (http://uxn.nu/rdf/2000/09/19/local/Property#last_name) | /~~ 0 obj 2 | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-004 | \__ 0 obj \__ get_objects_list /~~ 0 init_types 9 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | /~~ declare_add_types 10 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005: --no value-- | \__ declare_add_types | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 0 init_types /~~ 1 init_types 10 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 1 init_types /~~ 0 value 2 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | /~~ 0 init_props 10 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | | Fetching props | \__ 0 init_props | /~~ 1 init_props 11 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 | | Fetching props | \__ 1 init_props \__ 0 value /~~ get_objects_list 7 | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | (http://uxn.nu/rdf/2000/09/19/local/Property#first_name) | /~~ 0 init_types 11 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | /~~ declare_add_types 11 | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | | /~~ get_objects_list 8 | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) | | | \__ get_objects_list | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003: --no value-- | | \__ declare_add_types | | Types for http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 0 init_types | /~~ 1 init_types 12 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | Types for http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person | | ..http://www.w3.org/2000/01/rdf-schema#Resource | \__ 1 init_types | /~~ 0 init_props 12 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | Fetching props | | ..Found a RDF::Service::Resource=ARRAY(0x85d7ce0) | | /~~ declare_arc 3 | | | http://uxn.nu/rdf/2000/09/19/local#M1 | | | P http://uxn.nu/rdf/2000/09/19/local/Property#first_name | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | | | /~~ declare_add_types 12 | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-003 | | | \__ declare_add_types | | \__ declare_arc | | ..Found a RDF::Service::Resource=ARRAY(0x85d2890) | | /~~ declare_arc 4 | | | http://uxn.nu/rdf/2000/09/19/local#M1 | | | P http://uxn.nu/rdf/2000/09/19/local/Property#last_name | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | | | /~~ declare_add_types 13 | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-004 | | | \__ declare_add_types | | \__ declare_arc | \__ 0 init_props | /~~ 1 init_props 13 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | | Fetching props | \__ 1 init_props | /~~ 0 obj 3 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-003 | \__ 0 obj \__ get_objects_list /~~ 0 init_types 13 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | /~~ declare_add_types 14 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004: --no value-- | \__ declare_add_types | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 0 init_types /~~ 1 init_types 14 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 1 init_types /~~ 0 value 3 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | /~~ 0 init_props 14 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | | Fetching props | \__ 0 init_props | /~~ 1 init_props 15 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 | | Fetching props | \__ 1 init_props \__ 0 value /~~ get_objects_list 9 | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 | (http://uxn.nu/rdf/2000/09/19/local/Property#last_name) | /~~ 0 obj 4 | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-004 | \__ 0 obj \__ get_objects_list /~~ 0 init_types 15 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | /~~ declare_add_types 15 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005: --no value-- | \__ declare_add_types | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 0 init_types /~~ 1 init_types 16 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | ..http://www.w3.org/2000/01/rdf-schema#Literal | ..http://www.w3.org/2000/01/rdf-schema#Resource \__ 1 init_types /~~ 0 value 4 | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | /~~ 0 init_props 16 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | | Fetching props | \__ 0 init_props | /~~ 1 init_props 17 | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 | | Fetching props | \__ 1 init_props \__ 0 value -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From Stefan.Andersson@ullmans.com Fri Oct 20 09:51:30 2000 Date: Fri, 20 Oct 2000 10:51:30 +0200 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: SV: [RDF] CVS update And now we can only wait for the first RDF modelling of this perl-based pseudo-schema as a base for the QDS... :-D /Stefan > -----Ursprungligt meddelande----- > Fr=E5n: Jonas Liljegren [SMTP:jonas@rit.se] > Skickat: den 20 oktober 2000 10:28 > Till: rdf@uxn.nu > =C4mne: [RDF] CVS update >=20 > Hello! :-) I have started to implement the API I have described. >=20 > I start with minimal implementations, without any support for = expanded > criterions. The API text has been updated to be more general. In > summary: >=20 > Elements in [] are ORed together and pairs in {} are ANDed together. > The special props { and =3D> [...] } and { or =3D> {} } changes that > behaviour. { not =3D> [...] } and { not =3D> {...} } negates the = effect > of [] and {}. >=20 >=20 > The current CVS version has implemented rev_type(), arc_subj() and > list() with the background support of init_rev_types(), > init_rev_props(), declare_selection() and declare_add_rev_types(). >=20 > The other methods will be replaced shortly. I have realy only = replaced > the first row in the template code below. >=20 >=20 > I have updated the debug output. It's now easier to follow what's > happens internally. This is what happens if you, in the test = program, > lists the two persons. This is the TT code: >=20 >=20 > [% persons =3D s.get("${NS_L}/Class#Person").rev_type.list %] > > [% FOREACH person =3D persons %] > > =20 > [% END %] >
[% = person.get_objects_list("${NS_L}/Property#first_name").0.value %] > [% = person.get_objects_list("${NS_L}/Property#last_name").0.value %] > > > >
>=20 >=20 > The program starts by connecting to the interfaces. We are using two > DBI interfaces in order to see how well it works with information > distributed over several sources: >=20 > our $s =3D new RDF::Service( NS_L."/service/R1" ); >=20 > $s->connect("RDF::Service::Interface::Schema::RDFS_200001"); >=20 > our $ia =3D $s->connect("RDF::Service::Interface::DBI::V01", > { > connect =3D> "dbi:Pg:dbname=3Dwraf_v01a", > name =3D> "wwwdata", > }); >=20 > our $ib =3D $s->connect("RDF::Service::Interface::DBI::V01", > { > connect =3D> "dbi:Pg:dbname=3Dwraf_v01b", > name =3D> "wwwdata", > }); >=20 >=20 >=20 > And here is the debug output (using verbose level 1). The '0' and = '1' > numbers to the left of the method name indicates which interface is > being called. The number a bit to the right of the method name is a > counter to see how many times a certan method is called. The first > row under the method name row states the resource making the call. > Additional rows will indicate the parameters to the method. >=20 >=20 >=20 > /~~ new RDF::Service 1 > | /~~ declare_model 1 > | | http://uxn.nu/rdf/2000/09/19/local/service/R1 > | | /~~ declare_add_types 1 > | | | = http://uxn.nu/rdf/2000/09/19/local/service/R1/20001020T100827-001 > | | \__ declare_add_types > | \__ declare_model > | Bootstrap > | Registring RDF/Service/Interface/Base/V01.pm > \__ new RDF::Service > Conneting to the schema > /~~ 0 connect 1 > | http://uxn.nu/rdf/2000/09/19/local/service/R1 > | Registring RDF/Service/Interface/Schema/RDFS_200001.pm > \__ 0 connect > /~~ 0 connect 2 > | http://uxn.nu/rdf/2000/09/19/local/service/R1 > | Registring RDF/Service/Interface/DBI/V01.pm > \__ 0 connect > /~~ 0 connect 3 > | http://uxn.nu/rdf/2000/09/19/local/service/R1 > | Registring RDF/Service/Interface/DBI/V01.pm > \__ 0 connect > /~~ rev_type 1 > | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | /~~ 0 init_types 1 > | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | Types for http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 0 init_types > | /~~ 1 init_types 2 > | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | /~~ declare_add_types 2 > | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/Class#Person: --no value-- > | | \__ declare_add_types > | | Types for http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Class > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 1 init_types > | /~~ 0 init_rev_types 1 > | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | /~~ declare_add_rev_types 1 > | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | Adding = http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | | ..Finding implicit rev_types > | | | /~~ arc_subj 1 > | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | ( http://www.w3.org/2000/01/rdf-schema#subClassOf ) > | | | | /~~ 0 init_rev_props 1 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | Fetching rev_props > | | | | \__ 0 init_rev_props > | | | | /~~ 1 init_rev_props 2 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | Fetching rev_props > | | | | \__ 1 init_rev_props > | | | | /~~ declare_selection 1 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | ( ) > | | | | | /~~ declare_add_types 3 > | | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-001 > | | | | | | /~~ get_objects_list 1 > | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | = (http://www.w3.org/2000/01/rdf-schema#subClassOf) > | | | | | | | /~~ 0 init_types 3 > | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | Types for http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | = ..http://www.w3.org/2000/01/rdf-schema#Resource > | | | | | | | \__ 0 init_types > | | | | | | | /~~ 1 init_types 4 > | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | Types for http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | = ..http://www.w3.org/2000/01/rdf-schema#Resource > | | | | | | | \__ 1 init_types > | | | | | | | /~~ 0 init_props 1 > | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | Fetching props > | | | | | | | \__ 0 init_props > | | | | | | | /~~ 1 init_props 2 > | | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | | Fetching props > | | | | | | | \__ 1 init_props > | | | | | | \__ get_objects_list > | | | | | \__ declare_add_types > | | | | \__ declare_selection > | | | \__ arc_subj > | | | Returning a list of 0 resources > | | | ..Finding done > | | \__ declare_add_rev_types > | | /~~ declare_add_rev_types 2 > | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | Adding = http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | | ..Finding implicit rev_types > | | | /~~ arc_subj 2 > | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | ( http://www.w3.org/2000/01/rdf-schema#subClassOf ) > | | | | /~~ declare_selection 2 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | ( ) > | | | | | /~~ declare_add_types 4 > | | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-002 > | | | | | | /~~ get_objects_list 2 > | | | | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | | | | = (http://www.w3.org/2000/01/rdf-schema#subClassOf) > | | | | | | \__ get_objects_list > | | | | | \__ declare_add_types > | | | | \__ declare_selection > | | | \__ arc_subj > | | | Returning a list of 0 resources > | | | ..Finding done > | | \__ declare_add_rev_types > | \__ 0 init_rev_types > | /~~ 1 init_rev_types 2 > | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | \__ 1 init_rev_types > | /~~ declare_selection 3 > | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ( http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 ) > | | /~~ declare_add_types 5 > | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person/20001020T100830-003 > | | | /~~ get_objects_list 3 > | | | | http://uxn.nu/rdf/2000/09/19/local#Selection > | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) > | | | \__ get_objects_list > | | \__ declare_add_types > | \__ declare_selection > \__ rev_type > Returning a list of 2 resources > /~~ get_objects_list 4 > | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | (http://uxn.nu/rdf/2000/09/19/local/Property#first_name) > | /~~ 0 init_types 5 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | /~~ declare_add_types 6 > | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | | /~~ get_objects_list 5 > | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) > | | | | /~~ 0 init_props 3 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | RDFS init_props_class RDF::Service::Resource=3DARRAY(0x85fa31c) > | | | | \__ 0 init_props > | | | | /~~ 1 init_props 4 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | Fetching props > | | | | \__ 1 init_props > | | | | /~~ 2 init_props 5 > | | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | | Fetching props > | | | | \__ 2 init_props > | | | \__ get_objects_list > | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003: --no value-- > | | \__ declare_add_types > | | Types for = http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 0 init_types > | /~~ 1 init_types 6 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | Types for = http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 1 init_types > | /~~ 0 init_props 6 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | Fetching props > | | ..Found a RDF::Service::Resource=3DARRAY(0x85d7ce0) > | | /~~ declare_arc 1 > | | | http://uxn.nu/rdf/2000/09/19/local#M1 > | | | P http://uxn.nu/rdf/2000/09/19/local/Property#first_name > | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | | | /~~ declare_add_types 7 > | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-0= 03 > | | | \__ declare_add_types > | | \__ declare_arc > | | ..Found a RDF::Service::Resource=3DARRAY(0x85d2890) > | | /~~ declare_arc 2 > | | | http://uxn.nu/rdf/2000/09/19/local#M1 > | | | P http://uxn.nu/rdf/2000/09/19/local/Property#last_name > | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | | | /~~ declare_add_types 8 > | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-0= 04 > | | | \__ declare_add_types > | | \__ declare_arc > | \__ 0 init_props > | /~~ 1 init_props 7 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | | Fetching props > | \__ 1 init_props > | /~~ 0 obj 1 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-0= 03 > | \__ 0 obj > \__ get_objects_list > /~~ 0 init_types 7 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | /~~ declare_add_types 9 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004: --no = value-- > | \__ declare_add_types > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 0 init_types > /~~ 1 init_types 8 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 1 init_types > /~~ 0 value 1 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | /~~ 0 init_props 8 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | | Fetching props > | \__ 0 init_props > | /~~ 1 init_props 9 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-004 > | | Fetching props > | \__ 1 init_props > \__ 0 value > /~~ get_objects_list 6 > | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003 > | (http://uxn.nu/rdf/2000/09/19/local/Property#last_name) > | /~~ 0 obj 2 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T103316-003#20001013T103317-0= 04 > | \__ 0 obj > \__ get_objects_list > /~~ 0 init_types 9 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | /~~ declare_add_types 10 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005: --no = value-- > | \__ declare_add_types > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 0 init_types > /~~ 1 init_types 10 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 1 init_types > /~~ 0 value 2 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | /~~ 0 init_props 10 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | | Fetching props > | \__ 0 init_props > | /~~ 1 init_props 11 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T103316-005 > | | Fetching props > | \__ 1 init_props > \__ 0 value > /~~ get_objects_list 7 > | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | (http://uxn.nu/rdf/2000/09/19/local/Property#first_name) > | /~~ 0 init_types 11 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | /~~ declare_add_types 11 > | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | | /~~ get_objects_list 8 > | | | | http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | | | (http://www.w3.org/2000/01/rdf-schema#subClassOf) > | | | \__ get_objects_list > | | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003: --no value-- > | | \__ declare_add_types > | | Types for = http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 0 init_types > | /~~ 1 init_types 12 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | Types for = http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | ..http://uxn.nu/rdf/2000/09/19/local/Class#Person > | | ..http://www.w3.org/2000/01/rdf-schema#Resource > | \__ 1 init_types > | /~~ 0 init_props 12 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | Fetching props > | | ..Found a RDF::Service::Resource=3DARRAY(0x85d7ce0) > | | /~~ declare_arc 3 > | | | http://uxn.nu/rdf/2000/09/19/local#M1 > | | | P http://uxn.nu/rdf/2000/09/19/local/Property#first_name > | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | | | /~~ declare_add_types 12 > | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-0= 03 > | | | \__ declare_add_types > | | \__ declare_arc > | | ..Found a RDF::Service::Resource=3DARRAY(0x85d2890) > | | /~~ declare_arc 4 > | | | http://uxn.nu/rdf/2000/09/19/local#M1 > | | | P http://uxn.nu/rdf/2000/09/19/local/Property#last_name > | | | S http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | | O http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | | | /~~ declare_add_types 13 > | | | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-0= 04 > | | | \__ declare_add_types > | | \__ declare_arc > | \__ 0 init_props > | /~~ 1 init_props 13 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | | Fetching props > | \__ 1 init_props > | /~~ 0 obj 3 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-0= 03 > | \__ 0 obj > \__ get_objects_list > /~~ 0 init_types 13 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | /~~ declare_add_types 14 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004: --no = value-- > | \__ declare_add_types > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 0 init_types > /~~ 1 init_types 14 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 1 init_types > /~~ 0 value 3 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | /~~ 0 init_props 14 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | | Fetching props > | \__ 0 init_props > | /~~ 1 init_props 15 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-004 > | | Fetching props > | \__ 1 init_props > \__ 0 value > /~~ get_objects_list 9 > | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003 > | (http://uxn.nu/rdf/2000/09/19/local/Property#last_name) > | /~~ 0 obj 4 > | | http://uxn.nu/rdf/2000/09/19/local#20001013T102942-003#20001013T102943-0= 04 > | \__ 0 obj > \__ get_objects_list > /~~ 0 init_types 15 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | /~~ declare_add_types 15 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | | Resetting the jumptable for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005: --no = value-- > | \__ declare_add_types > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 0 init_types > /~~ 1 init_types 16 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | Types for http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | ..http://www.w3.org/2000/01/rdf-schema#Literal > | ..http://www.w3.org/2000/01/rdf-schema#Resource > \__ 1 init_types > /~~ 0 value 4 > | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | /~~ 0 init_props 16 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | | Fetching props > | \__ 0 init_props > | /~~ 1 init_props 17 > | | http://uxn.nu/rdf/2000/09/19/local/literal/20001013T102942-005 > | | Fetching props > | \__ 1 init_props > \__ 0 value >=20 >=20 >=20 >=20 >=20 > --=20 > / Jonas Liljegren >=20 > The Wraf project http://www.uxn.nu/wraf/ > Sponsored by http://www.rit.se/ >=20 > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf Stefan Andersson Ullman Communications Johannebergsgatan 30 412 55 G=F6teborg Tel: +46-31-708 26 13 Mail: stefan.andersson@ullmans.com From jonas@rit.se Fri Oct 20 10:57:20 2000 Date: 20 Oct 2000 11:57:20 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] QDS Stefan Andersson writes: > And now we can only wait for the first RDF modelling of this perl-based > pseudo-schema as a base for the QDS... :-D The query syntax is built upon selection criterions. This is an example on how to get all the locations of a thing during a time period: $thing->arc( pred => location, valid_during => $date_range )->obj It can be represented in RDF by using a variable namespace. Those resources could/will also be of type "use all matching alternatives". It cold look like this: X -- rdf:type --> rdf:Statement X -- rdf:type --> L:Variable X -- rdf:predicate --> L:location X -- L:validDuring --> L:dateRang52 X -- rdf:subject --> L:myThing42 X -- rdf:object --> Y Y -- rdf:type --> L:Variable And then you will say that you are intrested of all the possible Y. That could be part of the question metadata. Let's say that the above is grouped as the model L:question1. Then we could say: L:question1 -- rdf:type --> L:Request L:question1 -- L:searchDeapth --> '100' L:question1 -- L:retrieve --> Y L:question1 -- L:agent --> L:registredUserNo18 L:question1 -- L:session --> L:session985 Something like that... -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Fri Oct 20 18:59:09 2000 Date: 20 Oct 2000 19:59:09 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Is "Model" part of the RDF model? "McBride, Brian" writes: > A good question. I think the current situation is as you say > that model is not part of the the RDF Model. I think of the RDF as building blocks for creating new concepts. The RDFS schema is an important extension to RDF and itself described in RDF. But that is only the beginning. There will (hopefully) be countless more schemas, adding new concepts in every conceivable domain. I have mentioned (in the Wraf mailinglist) the areas of modelling trust, preferences, versioning, presentation, queries and more. Each of them introduce new concepts. Every statement exists in a context. You want to know who the stater is and when it was stated. A document with RDF in XML serialization can be viewd as a unity with a common source and created in the same time. We only have to create the class Model and make it a subClassOf Container. Nothing strange about that. The Model class should be placed in a schema that we all can use in the intrest of higher operability. But there is no need to extend the existing schemas. RDF was built to grow. And grow it will, with lots and lots of new schemas. The new classes currently used in Wraf are: wraf:Service - Holds data about _your_ session with the server wraf:Interface - The gateway to accessing models, used by the service wraf:Model - A collection of statements wraf:Selection - A collection of resources, returned from a query More to come later... The Second alpha will be announced within a few days. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From stefan@c64.org Fri Oct 20 20:36:48 2000 Date: Fri, 20 Oct 2000 21:36:48 +0200 From: Stefan Andersson stefan@c64.org Subject: [RDF] QDS Naah. I meant the [] and {} niftiness. Maybe something like AndBag -- subClassOf --> Bag OrBag -- subClassOf --> Bag MyQuery -- Criterion --> Criterion1 Criterion1 -- type --> AndBag Criterion1 -- _1 --> Criterion1a Criterion1 -- _2 --> Criterion1b Criterion1a -- type --> Negated Criterion1a -- type --> OrBag Criterion1a -- _1 --> Criterion1a1 Criterion1a -- _2 --> Criterion1a2 Criterion1b -- rdf:type --> partial_statement_query Criterion1b -- rdf:predicate --> phone_number Criterion1b -- rdf:object --> SomeNumber Ummm... not very clear example, but maybe I got the point thru? /Stefan Jonas Liljegren wrote: > > Stefan Andersson writes: > > > And now we can only wait for the first RDF modelling of this perl-based > > pseudo-schema as a base for the QDS... :-D > > The query syntax is built upon selection criterions. > > This is an example on how to get all the locations of a thing during a > time period: > > $thing->arc( pred => location, valid_during => $date_range )->obj > > It can be represented in RDF by using a variable namespace. Those > resources could/will also be of type "use all matching alternatives". > It cold look like this: > > X -- rdf:type --> rdf:Statement > X -- rdf:type --> L:Variable > X -- rdf:predicate --> L:location > X -- L:validDuring --> L:dateRang52 > X -- rdf:subject --> L:myThing42 > X -- rdf:object --> Y > Y -- rdf:type --> L:Variable > > And then you will say that you are intrested of all the possible Y. > That could be part of the question metadata. Let's say that the above > is grouped as the model L:question1. Then we could say: > > L:question1 -- rdf:type --> L:Request > L:question1 -- L:searchDeapth --> '100' > L:question1 -- L:retrieve --> Y > L:question1 -- L:agent --> L:registredUserNo18 > L:question1 -- L:session --> L:session985 > > Something like that... > > -- > / Jonas Liljegren > > The Wraf project http://www.uxn.nu/wraf/ > Sponsored by http://www.rit.se/ > > _______________________________________________ > RDF mailing list > RDF@uxn.nu > http://www.uxn.nu/cgi-bin/mailman/listinfo/rdf From jonas@rit.se Fri Oct 20 20:53:20 2000 Date: 20 Oct 2000 21:53:20 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] QDS Stefan Andersson writes: > Naah. I meant the [] and {} niftiness. > > Maybe something like > > AndBag -- subClassOf --> Bag > OrBag -- subClassOf --> Bag > > MyQuery -- Criterion --> Criterion1 > Criterion1 -- type --> AndBag > Criterion1 -- _1 --> Criterion1a > Criterion1 -- _2 --> Criterion1b > > Criterion1a -- type --> Negated > Criterion1a -- type --> OrBag > Criterion1a -- _1 --> Criterion1a1 > Criterion1a -- _2 --> Criterion1a2 > > Criterion1b -- rdf:type --> partial_statement_query > Criterion1b -- rdf:predicate --> phone_number > Criterion1b -- rdf:object --> SomeNumber > > Ummm... not very clear example, but maybe I got the point thru? Yes. Something like that... But I would probably subclass Container. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From bwm@hplb.hpl.hp.com Sat Oct 21 10:05:54 2000 Date: Sat, 21 Oct 2000 10:05:54 +0100 From: McBride, Brian bwm@hplb.hpl.hp.com Subject: [RDF] RE: Is "Model" part of the RDF model? > > wraf:Model - A collection of statements Is that a collection of statements or a collection of reified statements? Brian From jonas@rit.se Sat Oct 21 18:47:46 2000 Date: 21 Oct 2000 19:47:46 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Is "Model" part of the RDF model? "McBride, Brian" writes: > > wraf:Model - A collection of statements > > Is that a collection of statements or a collection of > reified statements? All statements can be viewed as reified statements. I recently came to insight that fact and non-fact statements can be handled by the model. Since all statements belongs to one (or more) models, we can have trusted and nontrusted models. A reified statement with a unknown stater will be placed in a 'empty' model. Things can be said about a model in the same manner that they can be said about separate statements. Some of the statements about the model could be made distributed over the statements. Wraf uses a lot of 'dynamic' properties. They can be inferred from schemas, calculated, providing extra metadata, be translations or alternative representations, or anything returned from a method call. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Sun Oct 22 10:40:58 2000 Date: 22 Oct 2000 11:40:58 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Is "Model" part of the RDF model? "McBride, Brian" writes: > > We only have to create the class Model and make it a subClassOf > > Container. Nothing strange about that. >=20 > Yup - this is similar to what Graham is doing with contexts and > the bag of statements idea. >=20 > The difference between this and the model idea used in SiRPAC > and Jena is that the API style model contains statements. > Contexts, bags and I presume the 'model' container Jonas > proposed contains reified statements. >=20 > I'm struggling to understand whether this matters. As I understand it: Statements are not resources. They do not exist (as resources) in the RDF diagram. Reified statements was invented as a way to make statements resources, so that we can say things about them. The RDF M&S explains that you can have the statement resource without having the actual statement. This is why many DB implementations of RDF uses the 'fact' boolean as an indication if the statement is stated in the model, or only just exists there as a resource. Wraf and other RDF implementations automaticly creates a resource for every statement. This is safe because it doesn't add any information, except that it gives the statement an URI. I have no intention to actually write out the reified statements of a model as a RDF/XML serialization. They just exist there implicitly to let you know what the subject, predicate and object of a specific statement are. Neither does the container (with it's _1, _2, ...) actually exist. It's just a way to represent the model in RDF. --=20 jonas@rit.se RIT AB http://www.rit.se Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36 Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609 From jonas@rit.se Sun Oct 22 13:59:42 2000 Date: 22 Oct 2000 14:59:42 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] ANNOUNCE: RDF::Service 0.02 The second alpha release of RDF::Service from the Wraf project http://www.uxn.nu/wraf/ has entered CPAN as file: $CPAN/authors/id/J/JO/JONAS/RDF-Service-0.02.tar.gz size: 56195 bytes md5: a46ee084f2b13ea84a88b659e6043dcf DESCRIPTION Wraf implements a RDF API that hopes to realize the Semantic Web. The framework uses RDF for data, user interface, modules and object methods. It uses interfaces to other sources in order to integrate all data in one enviroment, regardless of storage form. The homepage for Wraf is http://www.uxn.nu/wraf/ there you can find the developers mailinglist and more background information. Please send any comments to the developer mailinglist. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Sun Oct 22 14:00:32 2000 Date: 22 Oct 2000 15:00:32 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] The Wraf API This is a sort of tutorial introduction to Wraf, alpha 2. The website http://www.uxn.nu/wraf/ will soon have a (silly) online demo of the module. Next on the list are the server functionality, so that the program doesn't have to start up for every call. ----------------------------------------------------- # The RDF::Service library requires perl v5.6 # use 5.006; # Set the path to the library # use FindBin; use lib "$FindBin::Bin/../lib"; # Load the library # use RDF::Service; # Constants used # use RDF::Service::Constants qw( NS_L ); # Create the session object. # # There is a diffrence between # # 1) the RDF::Service module, # # 2) the RDF::Service distribution package, # # 3) the RDF::Service installation, # # 4) the running (server) instance of RDF::Service and # # 5) the connection to the RDF::Service server. # # Our $s is a resouce object representing our *connection* to the # RDF::Service server. That's why I call it a session resource. our $s = new RDF::Service( NS_L."/session/S1" ); # The URI will be diffrent between diffrent clients and times. A # continued session should use the same session URI. The parameter to # the constructor holds our session URI. # # The URI string used as parameter for the constructor are here # constructed by concatenating the constant NS_L with a string. NS_L # stands for "Namespace local" and is here the namespace owned by the # running instance ot the RDF::Service server. # # The $s object holds information about the connected interfaces. # The interfaces are the modules that provides read and write access # to RDF statements. # # The constructor starts out by connecting to the base interface - # RDF::Service::Interface::Base::V01 - implementing the most basic # functions. # We continue by connecting to the RDFS interface. # # The interface gives you access to the RDF, RDFS and L (local) # schemas. (This interface will probably be devided into three # separate interfaces in a later version.) # # The statements in the schema are hard coded into the module. # Nothing can be stored here. This interface implements the class # inheritance that belongs to the RDFS schema. It says that if a # resource is of type A and A is a subClassOf B, then it will add that # the resource also is of type B. $s->connect("RDF::Service::Interface::Schema::RDFS_200001"); # The module embeds the schema version date in its name. (We will be # using the URI of the interface in later versions.) Each session # can connect to diffrent interfaces and diffrent versions of # interfaces. This means that the same question will give diffrent # answers, depending on what interfaces the session has connected to. # # The $s object is not actually a resource object, but a *context* # object. All objects from the client perspective are context # objects. They in turn holds the actual resource object and the # context. The context will be used to refere to the session and the # local context in which the object was retrieved. # We will now connect to a database, used to store our localy created # statements. Statements private to the session are not stored # anywhere and will dissapere then the program ends. our $db = $s->connect("RDF::Service::Interface::DBI::V01", { connect => "dbi:Pg:dbname=wraf_v01a", name => "wwwdata", password => "secret", }); # The named parameters here represents the properties of the # database. The same interface can be used to connect to several # diffrent databases (or even the same databse, but with diffrent # authorizations). # # The interface object returned represents the *connection* to the # interface. The URI of the interface connection will be constructed # from the interface module URI and all the parameters except the # password. If another session uses the same interface module and the # same parameters, they will get the same interface connection resouce # object. (But placed in their own context.) # And now create a model in which our statements will be placed. (The # session statements is placed in a server meta-model.) my $model = $s->get_model(NS_L.'/model/M1'); # get_model() is a combination of a couple of other methods. It will # find the resource with the specified URI. If that resource is not a # model, it will fail. If the resource doesn't exist, it will be # created as a model. # # Statements (arcs) will be saved in the first interface that accepts # them. In this case, it would be the DB interface. Later version # could use $db->get_model() in order to explicitly state the # interface used for saving the arcs. # Define a new class. $c_person stands for "the class named Person". my $c_person = $s->get(NS_L.'/Class/Person')->set($model, [NS_RDFS,'Class']); # get() retrieves the existing resource. If non can be find, it # creates a new one. On the other hand; find() will fail no arc # mentioning the resource can be found. (Will use the current # selection (calling object), rather than allways look in all # connected interfaces. # # The set() can be called with $node->set($model, $types, $props). # $types i a list of types for the $node and $props holds any # properties (in the form name/vale pairs) to set. All the created # arcs will be placed in $model. (Later versions will take $model # from the calling context instead.) # # The set() method sets *all* properties for the $node in the $model. # Any existing statements about the node in the same model will be # removed. # # (Future versions will check that you (the session agent) own the # model you are using and that the model is open. Closed models can # never be changed.) # Create a person with first and last name. $s->get()->set($model, [$c_person], { NS_L.'/Property/first_name' => ["Jonas"], NS_L.'/Property/last_name' => ["Liljegren"], } ); # The empty get() generates a unique URI. The types list consists of # the person class and the property list defines the first and last # name. Each value in the name/value list is a reference to a list of # resource objects. If a element is a string (as in this example), a # literal resouce will be created with a unique URI. All this will be # placed in the provided $model and stored in the $db interface. # Get a list of all resources of type Person. my @persons = $c_person->rev_type->list; # rev_type() is the reverse of type(). type() returns a # selection of all the types for a node. rev_type() returns all nodes # that has type of the calling node. # # A selection is a special type of resource that represents all # resources matching the specified criterions. Those criterions can # (in later versions) be arbitrary complex. New criterions can # (later) be added to existing selections. Some criterions can be set # up for the session and get inherited to the context of the calling # node. # # The criterions doesn't have to be resolved until you actually want # to iterate through the members of the selection. Later versions # will dynamicly create indexes for common criterions and optimize the # retrieval. # Get the first name of the first person. my $first_name = $persons[0]->arc_obj(NS_L.'/Property/first_name')->li; print ${ $first_name->value }; # arc_obj($pred) is a shorthand for arc($pred)->obj() which in turn is # a shorthand for arc({ pred => $pred })->obj(). They return a # selection of matched resources. # # The li() method assumes that the selection only has one resource. # Any more or less and the method throws an exception. li() will also # be used to retrieve a specified from a selection, based on the list # number or extra criterions. # # value() expects the calling node to be a literal and returns a # reference to the literal value. References are used to prevent # copying in case of very large (maby binary) literals. # Change the name of the person. $first_name->set_literal($model, \"James"); # Remove the person (recurseivly). $person[0]->delete( $model ); # This deletes all statements with person 0 as subject, and does the # same for each object of those statements. But only statements # beloning to the $model. # That's all. There are other moethods/properties. But you have to # read the source to find them. ;-) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Sun Oct 22 17:47:05 2000 Date: 22 Oct 2000 18:47:05 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Trading perfection for practicality "McBride, Brian" writes: > Hi Jonas, > > > Statements are not resources. They do not exist (as resources) in the > > RDF diagram. Reified statements was invented as a way to make > > statements resources, so that we can say things about them. > > Yes. So in RDF Model terms I presume then that your model container > contains the resource that represents the statement, not the statement > itself. So we might have for example a set of statements: > > { > ([anon:model], [rdf:type], [wraf:model]) > ([anon:model], [rdf:_1], [(s, p, o)] ) > } > > which represents a model containing a single statement (s,p,o). > This set of statements does not contain the statement (s,p,o). Yes? Yes. > > Wraf and other RDF implementations automaticly creates a resource for > > every statement. This is safe because it doesn't add any information, > > except that it gives the statement an URI. > > Certainly both my implementations treated statements as resources. I'm > curious what URI you generate for your statements. Just a unique URI in the local namespace. > > I have no intention to actually write out the reified statements of a > > model as a RDF/XML serialization. They just exist there implicitly to > > let you know what the subject, predicate and object of a specific > > statement are. Neither does the container (with it's _1, _2, ...) > > actually exist. It's just a way to represent the model in RDF. > > Interesting. Sounds like you have done the same as I in that I'm > happy to have the resource which represents a statement without > explicitly attaching the type, subject, predicate and object > properties to it, i.e. an incomplete reification. > Presumably, if the extra reification statements type, > subject, predicate and object were explicity part of the model, > you would write them out and they would show up in query results. > > If I do a query to list all statements with a predicate rdf:_1, what > answers will I get from WRAF? I have traded perfection for practicality. There will be many generated properties for every resource. Reified statements are not the exception. Transformation rules and other inference rules could potentially give thousands of properties for a resource. There are a couple of important points here: 1. The original format of some sort of data are just one of many ways to encode the information. If you look at the information for a specific entity, it is encoded as a tree. The data is stored as person.contact_information.home.email.alt._3 but you just ask for person.email! Transformation rules will give you the answer. But the important thing is that they find the answer then you ask for it specifically. The email will not show if you just ask for a list of properties. 2. You will have many levels of search. There are no limit of what can be infered about a specific resource. Most of the time, you will do fine with a shallow scan. But sometimes you want more details and will instruct for scans. 3. The same interface providing the implicit (dynamic) properties should also set up hooks to answer wuestions on those implicit properties. That include questions about list items. 4. But most important. I think that we have to give up the demand for infallibility. Computers should be able to make misstakes. They can't instantly keep up with changes all around the web. They can't know if the answer is around the next corner. We can accept reasonable correct answers with a reasonable depth. -- 100% correct answers can be reached within a limited domain with a full search. But that could still easily be wrong because we don't know if the input is right to begin with. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From tom.van_eetvelde@alcatel.be Mon Oct 23 11:41:49 2000 Date: Mon, 23 Oct 2000 12:41:49 +0200 From: Tom Van Eetvelde tom.van_eetvelde@alcatel.be Subject: [RDF] Re: Is "Model" part of the RDF model? This is a multi-part message in MIME format. --------------04EEE0130C1F4CE19F222AB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RDF people, Recently I read something on Conceptual Graphs. Looks like RDF extended with logic. Anyway, they also handle contexts. Could this be related to this discussion? I hope some people in this mailing list know about Conceptual Graphs, otherwise, the question has no target audience of course. Greetings, Tom. --------------04EEE0130C1F4CE19F222AB5 Content-Type: text/x-vcard; charset=us-ascii; name="tom.van_eetvelde.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Van Eetvelde Content-Disposition: attachment; filename="tom.van_eetvelde.vcf" begin:vcard n:Van Eetvelde;Tom x-mozilla-html:FALSE org:Alcatel Bell adr:;;Francis Wellesplein 1;2018 Antwerp;;;Belgium version:2.1 email;internet:tom.van_eetvelde@alcatel.be title:Research Engineer x-mozilla-cpt:;0 tel;work:32 (0) 3 240 4181 fn:Tom Van Eetvelde end:vcard --------------04EEE0130C1F4CE19F222AB5-- From jonas@rit.se Tue Oct 24 16:29:39 2000 Date: 24 Oct 2000 17:29:39 +0200 From: Jonas Liljegren jonas@rit.se Subject: [RDF] First c/s version The latest CVS version includes the files ./cgi-bin/serv1.pl ./cgi-bin/client.cgi This speeds up the response time many times. The server resolves one request at the time. Time-sharing will be implemented later, then needed. We will have to use fork or similar for retrieving RDF documents with http. About the choise of the server implementation: I looked at the CPAN modules EventServer and NetServer::Generic, but they didn't seem to fit the needs. SysV IPC isn't practical since the central cache is used everywhere and the objects consist of small perl objects. I did a benchmark, and it was slow. The forking capabilities of Perl is still unstable. I don't want Wraf to be unstable. The server is ussing the lov level IO::Socket and IO::Select modules. The algorithms was adpoted from Joey Hess perlmoo, a Perl mud server. :-) Ok. Now starts the real job: to implement the callbacks to timeout values upon change. Doesn't feel that hard. Maby we will reach alpha 3 within this week. :-) Here is the TODO list: DONE - Add properties DONE - View all properties for person DONE - Create a web HTML interface to register DONE - Remove/change statements DONE --- (alpha 1) DONE - Context wrappers for objects DONE - Selections for searches DONE - minimal arc(), arc_obj() and rev_type() DONE - list() and li() DONE --- (alpha 2) DONE - c/s architecture - callbacks to updated cache on changes in the source --- (alpha 3) - multipple criterions - sub criterions - alternative lists --- (alpha 4) - criterions in context - Session metadata - User identification --- (alpha 5) - Model authority - authenticated change/delete - distributive properties --- (alpha 6) - minimal SDL general presentation framework - minimal inference/translation rules --- (alpha 7) - Generalize prototyp application - Set official schema URIs - Test suite --- (beta 1) But this will probably change after alpha 3. Alpha 4 was set up to finish most of the selection (query) API. But that will not happen if the prototype doesn't actually need it. Hmm.. I guess I will just remove the stage 4 and extend the API as needed... Ok. Changing the TODO to: DONE - Add properties DONE - View all properties for person DONE - Create a web HTML interface to register DONE - Remove/change statements DONE --- (alpha 1) DONE - Context wrappers for objects DONE - Selections for searches DONE - minimal arc(), arc_obj() and rev_type() DONE - list() and li() DONE --- (alpha 2) DONE - c/s architecture - callbacks to updated cache on changes in the source --- (alpha 3) - Session metadata - User identification --- (alpha 4) - Model authority - authenticated change/delete - distributive properties --- (alpha 5) - minimal SDL general presentation framework - minimal inference/translation rules --- (alpha 6) - Generalize prototyp application - Set official schema URIs - Test suite --- (beta 1) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 2 20:52:02 2000 Date: 02 Nov 2000 21:52:02 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Current issues Ok. Just want to write a little about the things I trying to do right now. The client-server separation realy speeds things up. But the real job is to keeping the cached data correct while allowing additions and deletions. The cyclic dependencies is still haunting me. Half of the time, the first object will not even initialize because the initialization process require initializations of other objects, that need other objects. I pull the plug on level 20. In the deepest levels, it still tries to initialize things with the help of other objects not yet initialized. My thoughts here is to make special handlings of the basic classes needed by the initialization process itself. This could maby be done by going through a series of bootup stages and let the stages decide what to do. But that can wait. The new wave of cyclic dependencies was a result of new functions introduced. Mainly a function to sort the types of a resource according to its place in the object heiarchy. (The specialized functions should be called before the most general versions.) In the battle to get the classes to initialize, I inserted the whole Schema class in the base class and put the actual schema data in the constant moudule. I have spent a lot of time thinking about the dynamic properties. What should we do if a resource has two properties; prop A depends on the content of prop B and prop B depends on the content of prop A? I was thinking about first initialize B, then A, and then B agian. But that will not do it. I'm not happy with this. I guess I will just make the property initialization fail in the face of this cyclic dependency. The current reason is that I am declaring dynamic subClassOf properties, that depends on the existing subClassOf properties. I have thinked about a couple of diffrent ways to do this. One version is to in the interface registration (the place there the interface tells the server which mathods it has to offer, depending on the namespace and type of resource) add info about what other properties it depends on. The creation of those properties would then trigger the creation of the dynamic property. Another way is to let the creation function call the properties it depends on. It would registrer itself in the context. The dispatcher could check the context before it dispatched a call, to avoid loops. This would result in that the dynamic subClassOf would call the static version, if it was not yet called. I think this is what I will do. The other thing to do is to remember the dependency of the properties in such a way that the removal of a statement will remove/update all the dependent statements. I started twith DEPEND data, but have changed my mind now. TYPE and REV_TYPE can be used both as the source for answering queries and to remember depends. I thinking that if the selection objects is used to store other types of query responses, they will use this system too. This got me to (internally) rename PROP and REV_PROP to REV_SUBJ and REV_OBJ respectively, and add REV_PRED just for completeness. And talking about completeness. Each of these base data string will be able to handle partial answers and will have an extra flag to say that all data from the connected interfaces has been retreived. I am tempted to store all sort of metametadata (used in the program) as regular props and even to convert the TYPE data to real type PROPS, but I'm afraid that that will make the cyclic dependency problem even worse. And You have to stop at some point. The internal description of itself could generate an infinity of statements. Some of them have to be implicit. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Sat Nov 4 20:26:02 2000 Date: 04 Nov 2000 21:26:02 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: WRAF site (was Chainsaw?) Graham Klyne writes: > OK, I see it now (though the server/ice is noticeably sluggish). That's because it's not yet a server. The c/s comes with alpha 3, aproximately in about a week. > Is there any documentation there on the protoyping/inferencing > mechanisms you mentioned? The documentation just consists of source code comments, mailinglist posts and collected notes. The mentioned distributed properties was developed as a way to implement aboutEachPrefix and to give all members of a container a specific property. But that has not been implemented yet. The plan is to have it in alpha 4. (See [1] ) A little is described about DBI storage of distributed properties (in [2] ). Inferencing and other things can be read in the mailinglist archive. The focus lies on dynamic properties, multiple interfaces, selection contexts and the presentation of RDF data. [1] http://www.uxn.nu/wraf/RDF-Service/doc/TODO [2] http://www.uxn.nu/wraf/RDF-Service/doc/rdf.sql From jonas@rit.se Mon Nov 13 00:31:06 2000 Date: 13 Nov 2000 01:31:06 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] ANNOUNCE: RDF::Service 0.03 This is the third alpha release of RDF::Service from the Wraf project http://www.uxn.nu/wraf/ This alpha introduces the persistant server. Requested data is cached in memory for later requests. Changes in data updates both the cache and the involved interfaces. The online demo has been updated: http://www.uxn.nu/wraf/RDF-Service/cgi-bin/demo.html Yes. It's still slow. But this is a early alpha. I'm aiming at handling about 10 requests per second in the 1.0 release. Next thing on the ToDo list is the implementation of session metadata. Each session will have a session resouce object that will be used in all server requests. User identification will be introduced. DESCRIPTION Wraf implements a RDF API that hopes to realize the Semantic Web. The framework uses RDF for data, user interface, modules and object methods. It uses interfaces to other sources in order to integrate all data in one enviroment, regardless of storage form. The homepage for Wraf is http://www.uxn.nu/wraf/ there you can find the developers mailinglist and more background information. Please send any comments to the developer mailinglist. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Mon Nov 13 21:56:24 2000 Date: 13 Nov 2000 22:56:24 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Resource consumption I notice that the Wraf server connects to more and more database handlers and never lets go of them. The server shut down with the message "Sorry, too many clients already". This is because every requests starts a new session and gets it's own DB connection. Alpha 4 will reuse the session object within the session. But it should probably also reuse the DB connections from other sessions. There will also be a system for expireing old resources from the cache. But that can wait until it becomes a real problem. ;-) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Mon Nov 13 22:24:38 2000 Date: 13 Nov 2000 23:24:38 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: RDF API convergence? was Re: ANNOUNCE: RDF.NET Alberto Reggiori writes: > In RDFStore, I am on the way to implement a Perl TIE interface over > an local or remote RDF storage. > I think Jonas Liljegren is aiming to do something similar with WRAF, > and using the Perl TIE approach it would let the user dive into it > much more quickly :-) The interface is largely (resource) object oriented. The connected interfaces calculates the resource properties requested. It could forward the request to another interface or calculate with some rule. But I am thinking about using TIE as an interface to collections, as a way to iterate through a large data set without having to prefetch the whole thing. I may use RDFStore as a backend. :-) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Tue Nov 14 12:39:05 2000 Date: 14 Nov 2000 13:39:05 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: En tanke Stefan Andersson wrote to me about an idea about binding the predicate to a parser: > a -- type --> b > b -- subClassOf --> Terrier > Terrier -- subClassOf --> Dog > type -- WRAFParser --> typeparser And that would result in that the call a.type will result in typeparser(a). And my response: Ok... There are many possible implementations. I have tried to make simplifications by accepting some limitations. At least for now. :-) The current solutions lets each interface implement it's own interpretation of a specific predicate, based on the subjects type and namespace. I can agree on that that seems a little strange then compared with Stefans suggestion about letting the predicate declare it's own implementation. Aaarghhh... Must i now start again? :-I Ok. Let's think about this..: Each predicate has a owner; the owner of the namespace used in the resource URI. The official meaning of a predicate should be that specified by it's owner. But there can still be many implementations of the property. The present system of choosing implementation is by connecting to the interfaces implementing the wanted implementations. That will later be extended by general interfaces with the ability to add new functions dynamicly and choose function by other means (ie trust). Ok. We can model the implementation of a predicate by a 'implementing' property. And we can still use the existing solution, because it includes the property. It includes three things: 1) The propety 2) The resource type: diffrent implementations for the designation of a resource. Literal will be designated by their value rather than their URI. 3) The namespace: A implementation can state that it only can answer questions about it's own resources. No point in sending each question to all connected interfaces. The plan is to include the interface declaration in the RDF model. It could be done like this ( using the predicate rdf:type as an example): s1: rdf:type -- wraf:implementedBy --> cpan:RDF/Service/Interface/Base/V01#type s2: s1 -- wraf:model --> cpan:RDF/Service/Interface/Base/V01 s3: s1 -- wraf:prefix --> "" s4: s1 -- wraf:subjectTye --> RDFS:Resource Or we could insert another step by separate the implementation declaration from the actual function: rdf:type -- wraf:implementedBy --> a1 a1 -- wraf:function --> cpan:RDF/Service/Interface/Base/V01#type a1 -- wraf:model --> cpan:RDF/Service/Interface/Base/V01 a1 -- wraf:prefix --> "" a1 -- wraf:subjectTye --> RDFS:Resource -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 16 10:20:02 2000 Date: 16 Nov 2000 11:20:02 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Multiple models Fixed some bugs with deleting resources, and with the working model. Sessions is in place. DB-connections is reused. The server seems stable. I am thinking about how I am storing the statements in memory and in the database. There is now three "layers" of object storage: 1. Each IDS has it's own objects (for the same resource). 2. The resorce bundles some data, not stored as statements, combining multipple models. 3. The DBI stores one record for a specific resource for each model. The method of storage for 2 and 3 shouldn't interfere with eachother. The simplest model would be to just store each statement as a statement. But my thoughts here was to optimize for the common case. It's possible that two models define the same statement with the same URI but with diffrent {p,s,o}. That would be unusual, but possible. We could also have the content of a literal diffrent in diffrent models. The resouce object has data that defines a number of implicit statements. It includes the statement triple, model, literal value, lable and some other things. There is a list of models coupled with the resource object. The implicit statements is thought to be contained in all those modles. If any of the modles differ for those statements, those statements should be extracted from the object and stored explicitely as extra statements. The consequence is that almost everything will have to handle the list of models and check that new statements match the old statements. We can't ad one statement at a time because that would force them to be made explicit. And we can't change the content of a literal if the existing literal is bound to another model. (On top of that, every change will have to expire the same resorce object in all other IDS. ... And it get's more complicated to update the DBI.) There is an assumption here that it's common to have identical statements in many diffrent models. I'm starting to doubt that all the work is worth it. Maby it would be better to just allow one model for a statement, and to have som sort of warning flag to say that one or more statements has been made explicit. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 16 18:42:26 2000 Date: 16 Nov 2000 19:42:26 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] That trust thing The plan for 1.0 is to have a tool for adding new data and new fields of data, using a few supplied basic elements. But more on that later. One thing i plan to use wraf for is to filter information. It can be filtering of intresting posts in a messageboard (like slashdot) or filtering of searchresults. One main example of filtering is that everybody can add any information, but that the viewer will filter out untrusted information and reviewer can sign/accept information from untrusted sources. The endorsement can be made about diffrent type of statement groups: 1) individual statements 2) all statements in a model 3) all statements in a namespace 4) all statements in a interface Or in general: either individual statements or all statements in a selection/container. Many statements will be infered from other statements. These are the dynamic properties. We have: a) Statement S1 in model M1 b) Inference rule R1 in model M2 c) Statement S2 infered from S1 and R1, placed in model M3 d) M2 is owned by agent A1 e) A1 is endoresed with statement S3 in the model M4 f) M4 is owned by agent A2 g) Visitor user A3 has declared it's trust in A2 The visitor ask's for a list of items that include S2, but only want's to see the trusted items. (He caould alternatively want to se the untrusted items marked as untrusted.) So what can we say about M3? We trust R1 since we trust M2 since we trust A1 since we trust M4 since we trust A2. But R1 only says that S2 is true *if* S1 is true. We have endoresements and we have ... conditional endoresments. S2 is trusted if R1 *and* S1 is trusted. So how can we aproximate this effectively within Wraf? We have simplified the handling by the introduction of models. They let's us reason about statements in groups rather than considering every individual statement. The goal is to find the items of the list with as few steps as possible. We can possible use the same infrastructure here as the one planned for all dynamic properties and containers; cache them. The problem here is that we doen't know the path to go for finding the answer. (Monospace diagram) .. / / .. A3 / \ / \ A2 -- .. \ \ A1 R1 -- M2 -- A1 A common model would be to have a large number of agents parallel with A3 using a few parallel A2, that in turn points to a large number of agents parallel A1. Trust statements can be about statements/rules (R1) models (M2) or agents (A1). We have to check all of these. Trust statements could also be about other things. M2 and A1 could be viewed as two specific types of selections of trusted statements. The trust statment of a container can be distributed to all its members. It could be a lot of distribution. But I'm planning to use distributed properties in a lot of situations, so it could be used for this as well. The ideal path would be to have the A2 (ie S3 in M4) trust statement distributed to R1. We could then iterate through all of A3 trust statements and look for them in R1. But that feels like too much. We don't want to iterate through too many nodes. On the other hand; we don't want to store to many trust statements in every little statement. Could we find a reasonable aproximation? Maby give out specific roles to the staters in the path? -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Fri Nov 17 16:30:49 2000 Date: 17 Nov 2000 17:30:49 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Deapth of search Much of what I do is a result from discussions with Stefan Andersson. He writes to me privately in Swedish, and I try to answer in english in order to document the thoughts. We have had the general idea for a long time now. The continuing discussion is aimed at resolving all the details. Each statement is coupled to a model. This is a base for a dynamic property with the name #model. You could maby also use the property #statedBy, and that could stand both for the model and the person / agent behind the model. You can infer that if the statement is #statedBy the modelm it's also #statedBy the person. If you want to know who has stated a statement; should you calculate both the answers and deliver them? ... Eventually, this will be determined by the context in the forms of criterions for the desired answer. If you ask *who* stated the statement, you indicate that you want a person. This is a question of deapth of search. If you find a teriffic answer, you will stop the search earlier. But as long as you don't find an answer of the desired form, you will continue searching until you give up. That is: first you get to know that it's the model that stated the statement. But if that answer doesn't satisfy you, you will also know that it's the person behind the model that did it. #statedBy is here just used as an example for the general concept. It was choosen because of the discussion about trust. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From Stefan.Andersson@ullmans.com Mon Nov 20 09:43:39 2000 Date: Mon, 20 Nov 2000 10:43:39 +0100 From: Stefan Andersson Stefan.Andersson@ullmans.com Subject: [RDF] =?ISO-8859-1?Q?Trust_=28long=29_=5BWas=3A_M=F6te=3F=5D?= > Men varf=F6r kan vi inte skriva p=E5 engelska f=F6r? Sorry, I'll switch to english. > Hur infererar man implicita staters? 'Implicit staters' have to be inferenced from some given logics, f.ex: = 'All documents, and hence all contained knowledge, transferred via HTTP is transferred to me by a HTTP daemon, and recieved by an HTTP agent. Hence, I have placed implicit trust in the daemon and the agent by implicitly trusting the interface by using it. So, if I (A Perl language application) trust a certain statement, the implicitly trusted instances are * The Perl language (and implicitly the perl coder community) * The application (trusting other parts of itself, and the ability to function as a whole) * The WRAF core module (and implicitly the coder of the module) * The WRAF HTTP Interface support module (and implicitly the coder of = the module) * The HTTP support module et.c. * The HTTP protocol * The web server daemon (What is its URI, by the way?) * The web server file system * The document (and the author(s) of the document) * The model contained in the document * In the case the document is a front-end for another database, there's = the database, the server application et.c. And finally, * The statements in the document itself. So, OK, this look rather nit-pickingly silly, but actually, in some applications, you will want to make _sure_ that these implicit trusts = are made explicit - and that all the instances are secured and monitored by = an authority. But most of the times, you optimize by 'faith'. Why should I doubt the Apache web server implementation of the HTTP protocol? Why should I = doubt wheter a server presenting itself as an Apache really is one? So, I make implicit trust - a web server/HTTP daemon is trustworthy. = End of discussion. But this implicit trust could be stated, thus making it explicit. 'All resources of class 'HTTP daemon' are trusted'.=20 > > Det intressanta blir ju d=E5 i en 'omv=E4nd' situation, d.v.s. = n=E4r det g=E4ller > > 'uppdatering' att det _egentligen_ g=F6rs ett antal nya statements, = som > > antingen kommer att ing=E5 i 'trust-m=E4ngden', eller inte kommer = att g=F6ra det, > > d.v.s. man kan se p=E5 det som att vad man g=F6r, =E4r att man = lokalt cachar > > (eller etablerar lokala resurser) ett antal statements som kommer = fr=E5n en > > anv=E4ndare, genom att man ser det som att anv=E4ndaren =E4r en = 'resurs' (som > > lagras lokalt och f=E5r ett internt id) och att allt som kommer = blir 'stated > > by' denna resurs. >=20 > Fick l=E4sa flera g=E5nger... Men jo. S=E5klart. Varje statement = kopplas > till vem som sagt det. Svarar p=E5 engelska i separat brev... The main point, which I'm uncertain if you got, is that the incoming = data from a POST form update, should be seen as a temporary resource, = existing only in the recieving parts temporary memory, until a decision is made = to store (cache) the content (because you can be _certain_ it will never = be available again). And that content could never be seen as an = 'replacement', only as yet another bunch of statements about things. Even if it is the = same source saying something new about something, you couldn't _replace_ it. = Only add it to your ever-growing database of statements. (a.k.a. = 'knowledge') But: The reconciliation process could use statement meta-data, see Jos example [1], to 'weed out' statements that are in conflict, untrue as = for current knowledge, seldom accessed, trivial, or explicitly outdated. So, for each statement, you would need to state=20 * Source * Wheter the statement nullifies another statement * When it was made * Wheter it will be available ever agin * Wheter the statement is seen as critical and/or authoritative. = (priority) To optimize the amount of refences, you could connect a model (bunch of statements) to a 'session' (everything stated by an agent at a certain time). Actually, a statement could both make a data statement, about a thing, = and at the same time make a schema statement. Come to think of it, this is critical. You should be able to say: M1: { Schema Model, stated 1999-05-01 by Stefan } S1: Persons can only have one cellular phone number M2: { Temporary Model, stated 1999-05-01 by Stefan } S1: Stefans cellular phone number is 555-123456 M3: { Temporary Model, stated 1999-09-01 by Stefan } S1: Stefans cellular phone number is 555-674534 [ Inferred S2: M3.S1 nullifies M2.S1 ] M4: { Temporary Model, stated 2000-06-02 by Jonas } S1: Stefans cellular phone number is 555-123457 [ Inferred S2: M4.S1 nullifies M2.S1 ] S3: Persons can have many cellular phone numbers S4: M2.S3 nullifies M1.S1 S5: Stefans cellular phone number is 555-123458 This will end with Stefan, after reconciliation, having two cellphone numbers: 555-123457 and 555-123458, and that the schema now accepts = multiple phone numbers. A completely different question is _how_ the agent should know that it = has to explicitly update the schema - but of cource the agent has to check = the schema to see how many numbers it should expect, so it should know. And, the temporal _ordering_ suddenly becomes critical. Hmm. This is no good. Obviously, the statements M4.S1-S4 and the statement M4.S5 would = have to be treated as stated at different moments in time. But: The reconciliation should be _private_ - it's MY truth model that = is being reconciled. If I trust Stefan, but not Jonas, I will still think Stefans number is 555-674534, and I will still think Persons can have = only one cellphone number. Which, of cource leads to interesting effects = when I get a new phone number... ... aaaand: What happens if I come to trust Jonas some time after the statements have been made? :-D (yep, this is why it is wise to 'remember' things even if you don't = trust them. And maybe the things Jonas says make you come to trust him...) Further on: The 'reconciliation' is not only about after-processing, = it's about reconciling viewpoints. Therefore I have MY Schema model. And = when I interact with another entity, we will have to synchronize our schemas = before interacting. > > 'Tempor=E4ra statements' som beskriver ett icke-tempor=E4rt >=20 > Huh? Ah, 'temporary statements', my word for statements that only exists as = a transaction. Web Form POST:s f.ex. > > Dock =E4r det ju helt ointressant f=F6r systemet att beh=E5lla = information, > > statements, som ingen anv=E4ndare av systemet litar p=E5. Hmmm... = jag tror jag > > snubblade p=E5 n=E5got h=E4r... men f=E5r fundera djupare p=E5 det = vid tillf=E4lle. >=20 > Jo. Visst =E4r det intressant. Man tror ju fortfarande kanske p=E5 > aspekter av det, =E4ven om man inte tror p=E5 allt. Exempelvis s=E5 = =E4ven om > man inte tror p=E5 ett uttalande s=E5 kan det vara intressant att = veta att > personen i fr=E5ga har gjort uttalandet. T=E4nk dig exempelvis en > diskussionsgrupp. Inte tar man bort inl=E4ggen bara f=F6r att de = inte =E4r > troliga. Man =E4r intresserad av det =E4nd=E5. >=20 > Bortfiltrering =E4r inte det enda svaret p=E5 untrusted statements. > Uppm=E4rkning =E4r ocks=E5 intressant, s=E5 kan de presenteras p=E5 = ett annat > vis. Och h=E4r kan man ha m=E5nga olika sorter av untrusted = statements. > Det kan vara gamla, overifierade, anonyma, eller massa annat. Yep. I think we've got a very interesting path going. I'm convinced = that 'private reconciliation' is the way to go. But I also think that this = means a distribution of the data model to the end-client. A server = reconciling thousands of viewpoints... no way. /Stefan [1] = http://lists.w3.org/Archives/Public/www-rdf-interest/2000Nov/0232.html _____________________________________________________________________ Stefan Andersson Senior Systems Developer Ullman Communications Johannebergsgatan 30 412 55 Gothenburg E-mail: stefan.andersson@ullmans.com Tel: +46-31-7082600 Fax: +46-31-205056 Cell: +46-733-404152 From jonas@rit.se Wed Nov 22 17:45:32 2000 Date: 22 Nov 2000 18:45:32 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Authority The work on Wraf, alpha 4, has come to the point there we will start question who is saying what. We plan support version handling by letting agents give new statements about things, surpassing old statements. But before that, I would like to support the plain raw deletion of statements (and literals). The question is who is allowd to do what? The present implementation only deletes statements if they belong to the working model. The working model is, in this case, the session. This means that created persons can be removed only within the same session. The next assumption was that the owner of the session ought to be able to remove statements (from open models) in following sessions. This colud be modeld by checking the agent of the session. But it strikes me now that that is too limited. The traditional way is to let the owner set up permissons for the updating and deletions of the resources, based on group or individual entity. It could also be set up by some superuser or similar. Those permission settings seems similar to the trust declaration on whos changes we trust. For a open versioning system, it would be the same as letting anybode do anything. The displayed information would be based on the changes done by the persons / groups trusted by the owner of the entity / area and maby also those trusted explicitly by the viewer. I would welcome suggestions on actual RDF schemas for modelling those owner-centric permissions. The super-owner would be the owner of the grouping, for example "all persons in the Wraf namespace". We can't forbid anyone to make statements, but we can control which statements to accept. For now, I will just let the deletion question rest until later. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 23 10:38:36 2000 Date: 23 Nov 2000 11:38:36 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Klyne Contexts: 5.2 Contexts as statements Hi! I'm finaly started reading your page [1]. There seems to be an error in section 5.2.1.1: I believe C36 and C37 should point at S9 and S10 respectively. Further. If I understand correctly: The context can be used for inferencing statements. If all the rdfc:assumes statements are asserted, all the rdfc:asserted statements will also be asserted. But that means that you can't mix two inference rules as done in the example: C31: [LAO] --rdf:type------> [rdfc:Context] C32: [LAO] --rdfc:assumes--> [S5] C33: [LAO] --rdfc:assumes--> [S6] C34: [LAO] --rdfc:asserts--> [S7] C35: [LAO] --rdfc:assumes--> [S8] C36: [LAO] --rdfc:assumes--> [S9] C37: [LAO] --rdfc:asserts--> [S10] It should rather be two separate contexts: C31: [LAO1] --rdf:type------> [rdfc:Context] C32: [LAO1] --rdfc:assumes--> [S5] C33: [LAO1] --rdfc:assumes--> [S6] C34: [LAO1] --rdfc:asserts--> [S7] C35: [LAO2] --rdf:type------> [rdfc:Context] C36: [LAO2] --rdfc:assumes--> [S8] C37: [LAO2] --rdfc:assumes--> [S9] C38: [LAO2] --rdfc:asserts--> [S10] But that usage doesn't seem to be consistent with the use of rdfc:assuems for inclusion of subcontexts: C21: [USL] --rdf:type------> [rdfc:Context] C22: [USL] --rdfc:asserts--> [S1] C23: [USL] --rdfc:asserts--> [S2] C24: [USL] --rdfc:asserts--> [S4] C25: [USL] --rdfc:assumes--> [LAO] I think that it should use asserts also for subcontext inclusion: C21: [USL] --rdf:type------> [rdfc:Context] C22: [USL] --rdfc:asserts--> [S1] C23: [USL] --rdfc:asserts--> [S2] C24: [USL] --rdfc:asserts--> [S4] C25: [USL] --rdfc:asserts--> [LAO] And to make it complete: C39: [LAO] --rdf:type------> [rdfc:Context] C40: [LAO] --rdfc:asserts--> [LAO1] C41: [LAO] --rdfc:asserts--> [LAO2] And it's importent to note that an inference can't be done in a context unless you have explicitly stated that you believe that the inference rules are true. That's what's done in C25. If you say [Context1] --rdfc:assuems--> [Context2], that should be interpreted as that we test the truth of Context2 to determine if the assertions of Context1 is to be taken as true. [1] http://public.research.mimesweeper.com/RDF/RDFContexts.html -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 23 12:06:41 2000 Date: 23 Nov 2000 13:06:41 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Klyne Contexts: 5.3-5.5 resources, languages and frames I don't understand why we must have contexts in place of resources. Why doesn't normal resources work? (I hadn't read the MEMO the last time this was discussed.) One example says, in part: [MyCar] --isa--> [FordEscort] [ ] --rdfc:asserts--> { [TheBody] ----color-----> "red" [TheEngine] --capacity--> "1600cc" } The normal way to do this would be: S1: [my:Car] --type--> [FordEscort] S2: [my:Car] --body--> [my:Body] S3: [my:Body] --color--> [red] S4: [my:Car] --engine--> [my:Engine] S5: [my:Engine] --capacity--> [my:Capacity] S6: [my:Capacity] --unit--> [cc] S7: [my:Capacity] --value--> "1600" No need for special constructions. Plain RDF works fine. The "my" things above are placed in a local namespace. Your example above makes a context out of MyCar. I don't think that is a meaningful context. It's not the car who asserts it's properties. I will discuss the basic use of contexts later (in its relation to models). But let us use it for this example: S8: [my:Klyne] --asserts--> [S1] S9: [my:Klyne] --asserts--> [S2] S10: [my:Klyne] --asserts--> [S3] S11: [my:Klyne] --asserts--> [S4] S12: [my:Klyne] --asserts--> [S5] S13: [my:Klyne] --asserts--> [S6] S14: [my:Klyne] --asserts--> [S7] The example continues: [FordEscort] --asserts--> { [TheBody] ----material---> "steel" : [TheEngine] --cylinders--> "4" [ ] --valves-----> "8" : (etc.) } The inference rules (my interpretation of rdfc:assumes and rdfc:asserts) could then be used to find the other properties of the car. S15: [my:Klyne] --asserts--> [GeneralCarContext] S16: [GeneralCarContext] --asserts--> [GCC1] S17: [GCC1] --assumes--> [S18] S18: [var:1] --type--> [FordEscort] S19: [GCC1] --asserts--> [S20] S20: [var:1] --body--> [var:2] S21: [var:2] --material--> [steel] S22: [GCC1] --asserts--> [S23] S23: [var:1] --engine--> [var:3] S24: [var:3] --cylinders--> "4" S25: [var:3] --valves--> "8" This is how I would do "forward" inferencing. Maby should continue this discussion in rdf-logic? Haven't compared this to DAML yet... -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From GK@Dial.pipex.com Thu Nov 23 13:23:46 2000 Date: Thu, 23 Nov 2000 13:23:46 +0000 From: Graham Klyne GK@Dial.pipex.com Subject: [RDF] Re: Klyne Contexts: 5.2 Contexts as statements At 11:38 AM 11/23/00 +0100, Jonas Liljegren wrote: >Hi! I'm finaly started reading your page [1]. > >There seems to be an error in section 5.2.1.1: > >I believe C36 and C37 should point at S9 and S10 respectively. Yes, you're right. Thanks. >Further. If I understand correctly: The context can be used for >inferencing statements. If all the rdfc:assumes statements are >asserted, all the rdfc:asserted statements will also be asserted. I am finding this is a difficult area. Some days it is clearer than others. Let me draw out a few points: - The focus here is on description rather than inference (though with an eye to limited inference that allows descriptions to be simplified). - the statements about context [LAO] are not inferences, but a set of premises that are referenced by [USL] and [SHS]. - The particular point I am trying to make is that if context [C1] assumes [C2] one cannot infer from that alone that statements true in [C2] are also true in [C1]. I am defining "assumes" applied to a context in such a way that it incorporates the _explicit_ assumptions of the referenced context, but says nothing about any implicit assumptions. Thus, assertions that may depend on the implicit assumptions are not necessarily true. This is in contrast to the definition of "asserts" applied to a context (see below). I think it's fair to question whether there is any point in defining the 'assumes' property as I have, or indeed at all. At the time I felt it captured something that is not otherwise expressed by assertion, and also captured an aspect of John McCarthy's description of contexts. For me, this whole area remains under review. I'll address your specific points... > But >that means that you can't mix two inference rules as done in the >example: > > C31: [LAO] --rdf:type------> [rdfc:Context] > C32: [LAO] --rdfc:assumes--> [S5] > C33: [LAO] --rdfc:assumes--> [S6] > C34: [LAO] --rdfc:asserts--> [S7] > C35: [LAO] --rdfc:assumes--> [S8] > C36: [LAO] --rdfc:assumes--> [S9] > C37: [LAO] --rdfc:asserts--> [S10] These aren't inferences or inference rules. They're just statements. I am defining a context that contains all these statements. >It should rather be two separate contexts: > > C31: [LAO1] --rdf:type------> [rdfc:Context] > C32: [LAO1] --rdfc:assumes--> [S5] > C33: [LAO1] --rdfc:assumes--> [S6] > C34: [LAO1] --rdfc:asserts--> [S7] > > C35: [LAO2] --rdf:type------> [rdfc:Context] > C36: [LAO2] --rdfc:assumes--> [S8] > C37: [LAO2] --rdfc:assumes--> [S9] > C38: [LAO2] --rdfc:asserts--> [S10] In my view that's a legitimate, but different, description. >But that usage doesn't seem to be consistent with the use of >rdfc:assuems for inclusion of subcontexts: > > C21: [USL] --rdf:type------> [rdfc:Context] > C22: [USL] --rdfc:asserts--> [S1] > C23: [USL] --rdfc:asserts--> [S2] > C24: [USL] --rdfc:asserts--> [S4] > C25: [USL] --rdfc:assumes--> [LAO] > >I think that it should use asserts also for subcontext inclusion: > > C21: [USL] --rdf:type------> [rdfc:Context] > C22: [USL] --rdfc:asserts--> [S1] > C23: [USL] --rdfc:asserts--> [S2] > C24: [USL] --rdfc:asserts--> [S4] > C25: [USL] --rdfc:asserts--> [LAO] In my approach, this is a different statement covered in section 5.2.2 That is, 'asserts' is a stronger statement than 'assumes' because it incorporates implicit as well as explicit assumptions, hence the truth of all asserted statements. >And to make it complete: > > C39: [LAO] --rdf:type------> [rdfc:Context] > C40: [LAO] --rdfc:asserts--> [LAO1] > C41: [LAO] --rdfc:asserts--> [LAO2] > > >And it's importent to note that an inference can't be done in a >context unless you have explicitly stated that you believe that the >inference rules are true. That's what's done in C25. Yes. This effectively establishes one simple form of "lifting rule" for deducing the truth of statements in one context from some statement(s) in another context. >If you say [Context1] --rdfc:assuems--> [Context2], that should be >interpreted as that we test the truth of Context2 to determine if the >assertions of Context1 is to be taken as true. In my approach, 'assumes' is weaker than that: I have defined it to mean simply that the _explicit_ assumptions of [Context2] (i.e. those stated by 'assumes' properties) are also taken as explicit assumptions of [Context1]. I think 'asserts' has the properties you are expecting. (And I think that 'asserts' is probably a more useful relationship between contexts.) >[1] http://public.research.mimesweeper.com/RDF/RDFContexts.html #g ------------ Graham Klyne (GK@ACM.ORG) From GK@Dial.pipex.com Thu Nov 23 14:22:09 2000 Date: Thu, 23 Nov 2000 14:22:09 +0000 From: Graham Klyne GK@Dial.pipex.com Subject: [RDF] Why contexts? (was: Klyne Contexts: 5.3-5.5 resources, languages and frames) At 01:06 PM 11/23/00 +0100, Jonas Liljegren wrote: >I don't understand why we must have contexts in place of resources. >Why doesn't normal resources work? (I hadn't read the MEMO the last >time this was discussed.) That's a good question, and one which I had to ask myself several times before I started to see why. (Historically, it felt like the right thing to do, and some empirical trials with RDF seemed to bear out the intuition.) To try and answer your question: it has to do with constructing models for complex (real-world) objects and systems. I believe that resources are too low-level a concept for describing complex systems. My intuition, which I am planning to demonstrate through examples built over the coming months, is that construction of complex models requires more flexible, higher-level constructs than resources and statements. I must be clear, I have no reason to believe that resources and statements are not _logically_ sufficient to describe complex systems -- I am not seeking to build a logical framework beyond that supportable by RDF; rather it is the _expressivity_ that concerns me. I am seeking to create structures that do for information modelling what functions and subroutines do for computer programming: allow us to create higher-level constructs from lower level pieces. There is one particular issue I have identified when trying to construct complex system descriptions: it is difficult to construct a description from just nodes and arcs without having an prior knowledge of the complete ontological framework. I contend that when describing complex systems we do not start out with complete knowledge of the ontological structure that will describe that system. Development of the statements and the ontology move forward together. One of my reasons for using contexts is that it gives me a framework for making statements that do not depend on detailed ontological structure. Thus, in the 1st example you cite, I know that my car has an engine and a body without necessarily knowing how they are ontologically related to the car as a whole, and I can make meaningful statements about them. >One example says, in part: > > [MyCar] --isa--> [FordEscort] > [ ] --rdfc:asserts--> > { > [TheBody] ----color-----> "red" > [TheEngine] --capacity--> "1600cc" > } > > >The normal way to do this would be: > > S1: [my:Car] --type--> [FordEscort] > S2: [my:Car] --body--> [my:Body] > S3: [my:Body] --color--> [red] > S4: [my:Car] --engine--> [my:Engine] > S5: [my:Engine] --capacity--> [my:Capacity] > S6: [my:Capacity] --unit--> [cc] > S7: [my:Capacity] --value--> "1600" By comparison, this form of description requires that the ontological relationship between the components is known. >No need for special constructions. Plain RDF works fine. The "my" >things above are placed in a local namespace. [...] >This is how I would do "forward" inferencing. > >Maby should continue this discussion in rdf-logic? > Haven't compared this to DAML yet... My focus here isn't primarily on inferencing, and I'm not trying to define an alternative DAML or similar framework. As far as possible, I'm trying to avoid issues of pure logic, other than how they affect the construction of descriptions. My concern is how to use RDF in the process of constructing models of complex systems. We have tried to construct descriptions of systems of only moderate complexity, and found that strict ontological structures tend to lock us into rigid and inflexible forms of expression, making the task of constructing a description very difficult, and definitely not practical for our purposes. The end goal of this effort is to come up with a practical way to construct RDF descriptions of complex systems and objects. In due course, I would expect this to be related to DAML-O and other ontology work in a consistent way, not to diverge from it. I think here is the appropriate forum, because I'm not trying to define new logical structures. Thanks for your thoughts. #g ------------ Graham Klyne (GK@ACM.ORG) From jonas@rit.se Thu Nov 23 15:47:55 2000 Date: 23 Nov 2000 16:47:55 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Statements/Reified statements Graham Klyne writes: > At 09:51 AM 11/23/00 +0100, Jonas Liljegren wrote: > > >This means that instead of four, we have five: > > > >{ uri, pred, subj, obj, model } >=20 > I considered that approach for [1], but have preferred to use > properties to create the association between statement-resource and > context (model). The above approach allows a given statement to be > associated with only one context/model, where properties allow a > given statement-resource to be incorporated into any number of > contexts/models. That seems very much more in line with the RDF > philosophy of "anyone can say anything about anything". This depends on if you look at it as a statement or a stating. Anybody can state a specific statement but every stating is unique. There are three special cases: 1. Two URIs for the same statement: S1: [A] --B--> [C] (M1) S2: [A] --B--> [C] (M2) 2. The same URI for diffrent statements: S1: [A] --B--> [C] (M1) S1: [D] --E--> [F] (M2) 3. The same URI for the same statement: S1: [A] --B--> [C] (M1) S1: [A] --B--> [C] (M2) This means that neither the triple, nor the URI can be used as the unique key in the storage of RDF. In the Wraf [2] DBI, I uses the kombination of model and URI as the key. What is the most efficiant way of storing data, while still allowing any combinations? I think that the most practical thing is to view the reified statements as statings. Since they are stated in diffrent models, they will probably have diffrent URIs. The common case will therefore be that a statement belongs to just one model. The Wraf is resource centric. A resource has dynamic and static properties. Also the statements are properties. Every resource is said to belong to exactly one model. This means that I will have to represent the special cases 2 and 3 by expanding the statements to their reification. A previous version (alpha 3) allowed multipple models. That solved case 3, but not case 2. In addition: what should I do if one of the models changed and the other didn't? This consideration led me to conclude that it would be more efficient to just have one model and group all the nasty cases together for special handling. (The same thing goes for literals and some other things.) Even if I store statements as {uri, pred, subj, obj, model}, they have an implicit representation in the RDF graph. They are drawn as reified statements contained in a model container. Another representation is to give the statement the property model. (Wraf will infere a lot of properties from other properties.)=20=20 Case 2, above, has to be spelled out to the point there every URI only belongs to one model. Here, we prefix generated URIs with G: G1: [S1] --type--> [Statement] (M1) G2: [S1] --subject--> [A] (M1) G3: [S1] --predicate--> [B] (M1) G4: [S1] --object--> [C] (M1) G5: [S1] --type--> [Statement] (M2) G6: [S1] --subject--> [D] (M2) G7: [S1] --predicate--> [E] (M2) G8: [S1] --object--> [F] (M2) Quoting statements and the question of truth -------------------------------------------- Instead of having a boolean for each statement, indicating if the statement is a fact or just a reified statement, we could use models and selections for denoting truth. The idea is that nonfact statements are placed in another model, or is given a special property saying that the statement is not endorsed. Let's say model M1 has statements serialized as: [S1] --type--> [Statement] [S1] --subject--> [A] [S1] --predicate--> [B] [S1] --object--> [C] [D] --E--> [S1] ( Could be drawn as { D E { A B C } }. ) One thought I had was to store like this: S1: [A] --B--> [C] (G1) G2: [D] --E--> [S1] (M1) G3: [G1] --type--> [Model] (G1) G4: [G1] --quotedIn--> [M1] (G1) Models will have a bunch of metadata about the origin, date and other things. One model could include other models. But the here invented 'quotedIn' can be used to remember that the statement was explicitly included in the model. The 'quotedIn' property is of no importance for the reasoning. But it can be used to recreate the model in serialized XML. What's considered to be true will depend on what model's you trust. Aliases ------- Another question is that of resource aliases. G2 above may be refering to the same statement as another URI. If it's infered that it's indeed the same *stating*, this will be marked up as that it's=A0an alias to the 'real' name. Let's look at an example of one model with the original stating and another model quoting that statement, without knowing the stating URI: S1: [A] --B--> [C] (M1) S2: [A] --B--> [C] (M2) S3: [D] --E--> [S2] (M2) The context of this may let the application infere that S1 and S2 are indeed the same stating, thus adding: S4: [S2] --aliasFor--> [S1] (G1) G1 is here the context depending on the inference rule and the involved models. Am I right in thinking that you probably thinking that I make all this much more complicated than it ought to be? ;-) [1] http://public.research.mimesweeper.com/RDF/RDFContexts.html [2] http://www.uxn.nu/wraf/ --=20 / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 23 16:27:02 2000 Date: 23 Nov 2000 17:27:02 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Statements/Reified statements schwaenzl writes: > Bag <-type- A -rdf_1-> B = Bag <-type- A -rdf_1-> C > -rdf_2-> C -rdf_2-> B > > It makes sense to ask whether some resource is a member of a bag. Does it make sense > to ask a resource, to be the "second" member of a bag? Let's say you are in a highly dynamic enviroment. You are iterating through a hugh list of resources returned to you as the answer to some twisted query. What happens if the answer changes while you are iterating? Maby best to just add new results at the bottom of the list. If _245 dissapears, it could be made to point at nothing. Think about search results returned one page at the time. It would be a waste of time to insert all the objects in the container before they are needed. Maby we just look at the first page? This means that the bag may not even be populated before it's actually accessed. (I have thought about this for implementation in the Wraf.) I think of two basic ways to access the contents of a container: 1. With a next() method for the container object 2. Random access to the specific resource. In the common case, we will access the first (and only) resource in the container. We could minimize confusion by pregenerate the whole bag and make it private for the requestor. For large questions, it would be better to not create the bag but rather provide the method for iteration. For common questions it could be an idea to save the query result and change it then necessary. It's in this latest case there strange things can happen if the content change while we are reading form it. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 23 18:19:23 2000 Date: 23 Nov 2000 19:19:23 +0100 From: Jonas Liljegren jonas@rit.se Subject: [Dave Beckett ] Re: [RDF] Re: Statements/Reified statements --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: dave.beckett@bristol.ac.uk Thu Nov 23 17:29:13 2000 Envelope-to: jonas@localhost Received: from localhost ([127.0.0.1] ident=jonas) by astral.paranormal.se with esmtp (Exim 3.16 #1 (Debian)) id 13yzFI-0006cr-00 for ; Thu, 23 Nov 2000 17:29:12 +0100 Received: from mail.rit.se [213.88.137.21] by localhost with POP3 (fetchmail-5.5.3) for jonas@localhost (single-drop); Thu, 23 Nov 2000 17:29:12 +0100 (CET) Received: from tatooine.ilrt.bris.ac.uk (tatooine.ilrt.bris.ac.uk [137.222.34.230]) by mail.rit.se (8.9.3/8.9.3) with ESMTP id RAA19726 for ; Thu, 23 Nov 2000 17:27:41 +0100 Received: from tatooine.ilrt.bris.ac.uk (localhost [127.0.0.1]) by tatooine.ilrt.bris.ac.uk (8.9.3/8.8.7) with ESMTP id QAA27659 for ; Thu, 23 Nov 2000 16:27:40 GMT To: Jonas Liljegren Subject: Re: [RDF] Re: Statements/Reified statements In-reply-to: jonas's message of 23 Nov 2000 16:47:55 +0100. <87d7fmheqc.fsf@astral.paranormal.se> X-URI: http://www.ilrt.bris.ac.uk/people/cmdjb/ Date: Thu, 23 Nov 2000 16:27:40 +0000 Message-ID: <27657.974996860@tatooine.ilrt.bris.ac.uk> From: Dave Beckett Xref: astral.paranormal.se rdf.wraf:126 Lines: 248 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jonas, you have obviously thought about this stuff a lot but I have a terrible time trying to understand what you are describing. To show what I mean, I'm going to take one of your emails and show your assumptions that I can't follow, but want to! :-) >>>Jonas Liljegren said: >=20 > Graham Klyne writes: >=20 > > At 09:51 AM 11/23/00 +0100, Jonas Liljegren wrote: > > > > >This means that instead of four, we have five: > > > > > >{ uri, pred, subj, obj, model } > >=20 > > I considered that approach for [1], but have preferred to use > > properties to create the association between statement-resource and > > context (model). The above approach allows a given statement to be > > associated with only one context/model, where properties allow a > > given statement-resource to be incorporated into any number of > > contexts/models. That seems very much more in line with the RDF > > philosophy of "anyone can say anything about anything". >=20 > This depends on if you look at it as a statement or a stating. > Anybody can state a specific statement but every stating is unique. statement, stating - what do *you* mean about these things, the word 'statement' is what the problem is about. Other words such as occurrance, fact should also be avoided. >=20 >=20 > There are three special cases: insert here - "of statements in different models ..." Of course that depends on what a model is defined as, see below. >=20 > 1. Two URIs for the same statement: > S1: [A] --B--> [C] (M1) > S2: [A] --B--> [C] (M2) >=20 > 2. The same URI for diffrent statements: > S1: [A] --B--> [C] (M1) > S1: [D] --E--> [F] (M2) >=20 > 3. The same URI for the same statement: > S1: [A] --B--> [C] (M1) > S1: [A] --B--> [C] (M2) You do not say what S1, S2, M1, M2 are or what this form of thing means: ..: [.] --.--> [.] (..) now I *assume* the thing before the : is a URI for the thing that follows (you don't say that). And it is pretty obvious the [.] --.--> [.] are the triples so we get: statement URI: [subject] --predicate--> [object] but what is the the (..) ?? A 'model' containing the statements? What is your definition of model - a set of statements? An RDF collection such as rdf:bag of statements? Is that how you would create it? > This means that neither the triple, nor the URI can be used as the > unique key in the storage of RDF. In the Wraf [2] DBI, I uses the > kombination of model and URI as the key. That's a database way of thinking, not generally relevant. You mean the primary key of a table you use is (statement URI, model URI) > What is the most efficiant way of storing data, while still allowing > any combinations? >=20 > I think that the most practical thing is to view the reified > statements as statings. Since they are stated in diffrent models, > they will probably have diffrent URIs. The common case will therefore > be that a statement belongs to just one model. terms statings, models used again. Introduced a new one 'stated'. When a 'statement' is 'stated' in a 'model' do you get a 'stating' as well as a 'statement' or just a 'stating'? > The Wraf is resource centric. A resource has dynamic and static > properties. Also the statements are properties. Every resource is > said to belong to exactly one model. This means that I will have to > represent the special cases 2 and 3 by expanding the statements to > their reification. you say: "resource is said to belong to exactly one model." RDF says resources are identified by URIs so any model can have any resource in it. How can you justify the above sentence? > A previous version (alpha 3) allowed multipple models. That solved > case 3, but not case 2. In addition: what should I do if one of the > models changed and the other didn't? This consideration led me to > conclude that it would be more efficient to just have one model and > group all the nasty cases together for special handling. (The same > thing goes for literals and some other things.) What do you mean by multiple models? (or model). In your head, everything is one model, but in technology terms, models are scattered around the world, web. You can't get away from the fact that I will have models of RDF content and so will you. > Even if I store statements as {uri, pred, subj, obj, model}, they have > an implicit representation in the RDF graph. They are drawn as > reified statements contained in a model container. Another > representation is to give the statement the property model. (Wraf > will infere a lot of properties from other properties.)=20=20 "give the statement the property model" That's too much shorthand. I suspect you mean attach a property to a statement resource/node, the property/arc is called wraf:model or somesuch but what does it point to?. You need to then say what that means. >=20 >=20 > Case 2, above, has to be spelled out to the point there every URI only > belongs to one model. Here, we prefix generated URIs with G: "every URI only belongs to one model" !!! What? >=20 > G1: [S1] --type--> [Statement] (M1) > G2: [S1] --subject--> [A] (M1) > G3: [S1] --predicate--> [B] (M1) > G4: [S1] --object--> [C] (M1) a break here would be clearer to show they are in different models, or are they? Different models but same storage? > G5: [S1] --type--> [Statement] (M2) > G6: [S1] --subject--> [D] (M2) > G7: [S1] --predicate--> [E] (M2) > G8: [S1] --object--> [F] (M2) > Quoting statements and the question of truth > -------------------------------------------- >=20 > Instead of having a boolean for each statement, indicating if the > statement is a fact or just a reified statement, we could use models > and selections for denoting truth. New term 'selection' - what is that? >=20 > The idea is that nonfact statements are placed in another model, or > is given a special property saying that the statement is not > endorsed. Let's say model M1 has statements serialized as: "nonfact statements" please define. And not by saying 'statements that are not facts' - what kind of thing is that? >=20 > [S1] --type--> [Statement] > [S1] --subject--> [A] > [S1] --predicate--> [B] > [S1] --object--> [C] > [D] --E--> [S1] >=20 > ( Could be drawn as { D E { A B C } }. ) >=20 > One thought I had was to store like this: >=20 > S1: [A] --B--> [C] (G1) > G2: [D] --E--> [S1] (M1) > G3: [G1] --type--> [Model] (G1) > G4: [G1] --quotedIn--> [M1] (G1) >=20 >=20 > Models will have a bunch of metadata about the origin, date and other > things. One model could include other models. But the here invented > 'quotedIn' can be used to remember that the statement was explicitly > included in the model. The 'quotedIn' property is of no importance > for the reasoning. But it can be used to recreate the model in > serialized XML. Now that does make sense; I had already decided for Redland to add extra statements (real statements, not "non-fact" ones) to my storage to describe the model (set of statements) and provide a place for administrative information to go, provenance etc. But these would appear in the model like other statements. > What's considered to be true will depend on what model's you trust. Yes. So I guess I can now work out that you store multiple models in one storage system. Why not just use rdf:bag to enclose models in one storage? > Aliases > ------- >=20 > Another question is that of resource aliases. G2 above may be Which G2? You define 2 of them. What is a resource alias? This sounds like the resource/URI black hole. > refering to the same statement as another URI. If it's infered that > it's indeed the same *stating*, this will be marked up as that it's=A0an > alias to the 'real' name. Let's look at an example of one model with > the original stating and another model quoting that statement, without > knowing the stating URI: >=20 > S1: [A] --B--> [C] (M1) >=20 > S2: [A] --B--> [C] (M2) > S3: [D] --E--> [S2] (M2) >=20 > The context of this may let the application infere that S1 and S2 are > indeed the same stating, thus adding: >=20 > S4: [S2] --aliasFor--> [S1] (G1) >=20 > G1 is here the context depending on the inference rule and the > involved models. >=20 >=20 >=20 >=20 > Am I right in thinking that you probably thinking that I make all this > much more complicated than it ought to be? ;-) Yes, sorry! Dave --=-=-= -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ --=-=-=-- From jonas@rit.se Thu Nov 23 18:20:11 2000 Date: 23 Nov 2000 19:20:11 +0100 From: Jonas Liljegren jonas@rit.se Subject: [Dave Beckett ] Re: [RDF] Re: Statements/Reified statements --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: dave.beckett@bristol.ac.uk Thu Nov 23 19:07:31 2000 Envelope-to: jonas@localhost Received: from localhost ([127.0.0.1] ident=jonas) by astral.paranormal.se with esmtp (Exim 3.16 #1 (Debian)) id 13z0mR-0006nB-00 for ; Thu, 23 Nov 2000 19:07:31 +0100 Received: from mail.rit.se [213.88.137.21] by localhost with POP3 (fetchmail-5.5.3) for jonas@localhost (single-drop); Thu, 23 Nov 2000 19:07:31 +0100 (CET) Received: from tatooine.ilrt.bris.ac.uk (tatooine.ilrt.bris.ac.uk [137.222.34.230]) by mail.rit.se (8.9.3/8.9.3) with ESMTP id TAA21135 for ; Thu, 23 Nov 2000 19:02:37 +0100 Received: from tatooine.ilrt.bris.ac.uk (localhost [127.0.0.1]) by tatooine.ilrt.bris.ac.uk (8.9.3/8.8.7) with ESMTP id SAA28523 for ; Thu, 23 Nov 2000 18:02:37 GMT To: Jonas Liljegren Subject: Re: [RDF] Re: Statements/Reified statements In-reply-to: jonas's message of 23 Nov 2000 18:54:58 +0100. <87u28yd159.fsf@astral.paranormal.se> X-URI: http://www.ilrt.bris.ac.uk/people/cmdjb/ Date: Thu, 23 Nov 2000 18:02:37 +0000 Message-ID: <28521.975002557@tatooine.ilrt.bris.ac.uk> From: Dave Beckett Xref: astral.paranormal.se rdf.wraf:128 Lines: 54 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>Jonas Liljegren said: > The hard thing here is that this is a work in progress. Many things > are only partly thought out. Wraf is *very* big. Wraf is not > finished until the semantic web is done. ;-) Yeah yeah, that means never, right? > Another thing is that the implementations will maby change in order to > acommodate the consensus of the list. It's time consuming to describe > things that will probably be changed. Sure implementations change, but what about where you are now? > One of the things I will use Wraf fore is as a document system. I > would like to write the documentation in Wraf itself. ;-) Beware of catch-22; I had that same problem with describing the parameters to the storage system for models. I nearly described the storage as a model, in which case you could never create one, since then you would have had to store a model in order to use it and ha to use a model in order to create a store. > > But ok... I will take the time to at least insert references. (I > should have done that the the first time.) And I was planning on > write a terminology index anyway... That would be great. How about your answers to these: A resource is .. A statement is .. A model is ... I use this terminology A: [B]-C->[D] (E) to mean ... where A, B, C, D, E are ... Maybe you can then just cite such a document on your RDF-IG postings via a URI and update it incrementally when you change your mind? :-) It also would be more generally useful for the RDF community to see what implementers were actually doing with the stuff the RDF model provides and where they differ. > (Please write to the Wraf list. It feels like I'm talking to a stone wall.) I could ask something like the above questions to you publically on the list if you want? Dave --=-=-= -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ --=-=-=-- From jonas@rit.se Thu Nov 23 19:09:09 2000 Date: 23 Nov 2000 20:09:09 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Klyne Contexts: 3. Statements sets in RDF This is the final part of my comment on the DFD [1]. You are defining a new type of container using rdfc:member instead of _1, _2, etc. I think it's redundant to have both systems. In Wraf [2] I'm planning to store container members in a special way, optimized for compact storage and easy manipulation. With such optimizations, there is no need for another type of rdfs:ContainerMembershipProperty. You write: RDF defines a way to represent collections of statements which suffers from some practical difficulties: 1 The rdf:Bag container class and associated containment properties make it diffcult to add new statements to a collection without knowing about all of the statements already belonging to that collection. 2 It is not possible to represent different containment relations for a single container. 3 The standard container classes have no way to represent distributive referents within an RDF graph. 4 The standard mechanism for collecting reified statements (bagId attribute) is bound to documents containing RDF statements, and cannot be used for collecting statements that are defined across several documents. 5 The standard mechanism does not allow for a given reified statement to belong to more than one collection. [[[The final two points above may not be strictly true, but if not it is not clear how to use standard RDF to obtain the effects described.]]] Let me comment: 1. With special methods for conatiner handling, you will not have to bother about the present content. Wraf will give each container the dynamic property 'size', and methods for adding and quering the container without knowing each propertys number. 2. I would say that you can only be in the container in one way. But besides the content, there can be multipple properties describing other things, like for a normal resource. You could also attach extra information to each membership statement. 3. Distribution functionality can be added to the standard container. Both distribution of properties to each member and distribution of all the members properties to the container or other resource. 4. You're right. This is why Wraf differentiates between Models and Selections. Each model holds the statements from one 'document' but can also be contained in several selections. Wraf's Selections is very close to your Contexts. That's why I'm intrested in them. 5. Well. You could explicitly put a statement in each collection. But that would not be the standard way? :) Anyway. My point here is that Wraf uses the "contexts" but name them selections. And I found some pointes intresting and will maby implemnet them. Maby we could make our schemas more compatible? I would like to keep the standard rdfs:ContainerMembershipProperty. [1] http://public.research.mimesweeper.com/RDF/RDFContexts.html [2] http://www.uxn.nu/wraf/ -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Thu Nov 23 20:18:49 2000 Date: 23 Nov 2000 21:18:49 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: Statements/Reified statements > From: Dave Beckett > I could ask something like the above questions to you publically on > the list if you want? ... Thanks. I have forwarded the mails. > >>>Jonas Liljegren said: > > The hard thing here is that this is a work in progress. Many things > > are only partly thought out. Wraf is *very* big. Wraf is not > > finished until the semantic web is done. ;-) > > Yeah yeah, that means never, right? Wraf will *be* the semantic web. Well. At least it will be a simple website member database... :) > > Another thing is that the implementations will maby change in order to > > acommodate the consensus of the list. It's time consuming to describe > > things that will probably be changed. > > Sure implementations change, but what about where you are now? I't open source. Just read it: http://www.uxn.nu/wraf/RDF-Service/lib/RDF/Service/Dispatcher.pm But yes. I will write about it. After 0.04 is out... > > One of the things I will use Wraf fore is as a document system. I > > would like to write the documentation in Wraf itself. ;-) > > Beware of catch-22; I had that same problem with describing the > parameters to the storage system for models. I nearly described the > storage as a model, in which case you could never create one, since > then you would have had to store a model in order to use it and ha to > use a model in order to create a store. That's not a catch-22. I will tell you what a catch-22 is. My catch-22 is hyperdimensional!!! ;-) It's been rather funny. Everything are resources. The session, the implementation, and most internal functions. It would be intresting to try to explain what happens when the program starts... In order to start it has to use functions. But whose functions are defined as resources. But you can't get those resource whithout the functions. And before you can do anything, you will have to know the type of the resource you start with. But you have to know the type in order to find out the type. I try to perform a controlled bootstrap, but it's rather complex. ;) -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From begeddov@jfinity.com Thu Nov 23 22:12:57 2000 Date: Thu, 23 Nov 2000 14:12:57 -0800 From: Gabe Beged-Dov begeddov@jfinity.com Subject: [RDF] Re: Klyne Contexts: 3. Statements sets in RDF I basically agree with Jonas' points but want to focus on the RDF/XML perspective on the issue of statement sets. The M&S specifies a mechanism for generating and modeling statement sets in section 6. It is the use of Bags that contain the reified statement resources that correspond to the statments that were present in a particular rdf:Description in the syntax. The author of the RDF/XML document can use syntax mechanisms to explicitly label the Bag (using bagId) and the reified statement resources (using property ID). Lets call the Bag the rdf:StatmentBag resource and the reified statement resources, rdf:Statement resources. Although it isn't spelled out, I assume that anonymous rdf:Statement resources and rdf:StatementBag resources will be labeled relative to the document. The explicitly labeled resources are guaranteed to be labeled relative to the document since they are labeled using ID rather than URI. What this means is that all the statements in the document are now unambiguously referenced from rdf:Statement resource that show their stating as being in the source document. In addition, all the statings that occured in a specific rdf:Description are referenced from an rdf:DescriptionBag resource that is also bound to the source document via its URI. You now have a way to track provenance that is already *built in to the M&S*. You can merge the models generated from multiple documents and trace back all the statings to the source documents and further to the particular instances of rdf:Description that generated them. On a separate but related front is the issue of how to implement this efficiently but that shouldn't directly color the discussion of what it means to map the syntax to the model and how to track statings. Gabe -- --------------------------- http://www.jfinity.com/gabe From GK@Dial.pipex.com Thu Nov 23 17:02:05 2000 Date: Thu, 23 Nov 2000 17:02:05 +0000 From: Graham Klyne GK@Dial.pipex.com Subject: [RDF] Re: Statements/Reified statements At 04:47 PM 11/23/00 +0100, Jonas Liljegren wrote: >Graham Klyne writes: > > > At 09:51 AM 11/23/00 +0100, Jonas Liljegren wrote: > > > > >This means that instead of four, we have five: > > > > > >{ uri, pred, subj, obj, model } > > > > I considered that approach for [1], but have preferred to use > > properties to create the association between statement-resource and > > context (model). The above approach allows a given statement to be > > associated with only one context/model, where properties allow a > > given statement-resource to be incorporated into any number of > > contexts/models. That seems very much more in line with the RDF > > philosophy of "anyone can say anything about anything". > >This depends on if you look at it as a statement or a stating. >Anybody can state a specific statement but every stating is unique. Well, I think that's a legitimate view. My view (which I think is also legitimate ;-) is to treat the resource as a _model_ of the statement, and used as _part_ of a stating. The actual stating is represented by the property that links the statement-resource to a context/model. >There are three special cases: > > 1. Two URIs for the same statement: > S1: [A] --B--> [C] (M1) > S2: [A] --B--> [C] (M2) > > 2. The same URI for diffrent statements: > S1: [A] --B--> [C] (M1) > S1: [D] --E--> [F] (M2) > > 3. The same URI for the same statement: > S1: [A] --B--> [C] (M1) > S1: [A] --B--> [C] (M2) > > >This means that neither the triple, nor the URI can be used as the >unique key in the storage of RDF. In the Wraf [2] DBI, I uses the >kombination of model and URI as the key. This is fine, and I think it's a perfectly valid implementation technique. I think in terms of using a model of the statement that links the statement to a context as the primary key. I think its another valid implementation technique. What this debate tells me is that the minimalist RDF M&S approach to statements, triples and reifications is probably right, because a variety of implementation approaches can be mapped to it. A model that dictated a particular implementation approach would probably not be a very good model. [...] >Am I right in thinking that you probably thinking that I make all this >much more complicated than it ought to be? ;-) No... I think you are quite properly considering the details of how you wish to implement an RDF processor, as I am doing. What I do think is that one can and should separate what are "merely" implementation concerns from the fundamental properties of the underlying model. #g ------------ Graham Klyne (GK@ACM.ORG) From champin@bat710.univ-lyon1.fr Fri Nov 24 15:12:32 2000 Date: Fri, 24 Nov 2000 16:12:32 +0100 From: Pierre-Antoine CHAMPIN champin@bat710.univ-lyon1.fr Subject: [RDF] Re: Why contexts? (was: Klyne Contexts: 5.3-5.5 resources, languages and frames) Graham Klyne wrote: > One of my reasons for using contexts is that it gives me a framework for > making statements that do not depend on detailed ontological > structure. Thus, in the 1st example you cite, I know that my car has an > engine and a body without necessarily knowing how they are ontologically > related to the car as a whole, and I can make meaningful statements about them. Interesting point. Actually, I too had problems with the Car example, but that makes sense... I have another idea since a few days, which may be an alternate solution : the use of "anonymous" resources (which mean for me: I know there is a resource here, but I don't know its URI). We can use anonymous resources as subject or object of a statement. Why not as the predicate ?? [my:Car] --[ ]--> [my:Engine] I have a car, I have an engine, I know there is a relation between them, but I have no word for that... what do you RDFers think of that ? Pierre-Antoine > > >One example says, in part: > > > > [MyCar] --isa--> [FordEscort] > > [ ] --rdfc:asserts--> > > { > > [TheBody] ----color-----> "red" > > [TheEngine] --capacity--> "1600cc" > > } > > > > > >The normal way to do this would be: > > > > S1: [my:Car] --type--> [FordEscort] > > S2: [my:Car] --body--> [my:Body] > > S3: [my:Body] --color--> [red] > > S4: [my:Car] --engine--> [my:Engine] > > S5: [my:Engine] --capacity--> [my:Capacity] > > S6: [my:Capacity] --unit--> [cc] > > S7: [my:Capacity] --value--> "1600" > > By comparison, this form of description requires that the ontological > relationship between the components is known. From seth@robustai.net Fri Nov 24 17:58:20 2000 Date: Fri, 24 Nov 2000 09:58:20 -0800 From: Seth Russell seth@robustai.net Subject: [RDF] Re: Why contexts? (was: Klyne Contexts: 5.3-5.5 resources, languages and frames) Pierre-Antoine CHAMPIN wrote: > We can use anonymous resources as subject or object of a statement. > Why not as the predicate ?? > > [my:Car] --[ ]--> [my:Engine] How do you serialize that in RDF ? Seth Russell From jonas@rit.se Mon Nov 27 12:07:42 2000 Date: 27 Nov 2000 13:07:42 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) Gabe Beged-Dov writes: > Ground Statement: > [Bush, wonThe, Election] > > Reified Statement Resource: > [ECResults#id1, type, statement] > [ECResults#id1, subject, Bush] > [ECResults#id1, predicate, wonThe] > [ECResults#id1, predicate, Election] > > Syntactic context for Reified Statement Resource: > [ECResults#bag1, rdf:_1, ECResults#id1] > [ECResults#bag1, type, Bag] > > Comments? Yes. I appreciate that you have repeated it several times now. I had a vague memory of it but had ignored it. But I know see that this is the right way. Can we all be in agreement that this proves that the reified statement can be used as a stating? But we can't use the outmost Description bag as the model. The uri of the model will be the uri of the document. It will have metadata stating things about it's encoding, namespaces used, time of retrieval, authority, and more. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From champin@bat710.univ-lyon1.fr Mon Nov 27 14:13:53 2000 Date: Mon, 27 Nov 2000 15:13:53 +0100 From: Pierre-Antoine CHAMPIN champin@bat710.univ-lyon1.fr Subject: [RDF] Re: Why contexts? (was: Klyne Contexts: 5.3-5.5 resources, languages and frames) Seth Russell wrote: > > Pierre-Antoine CHAMPIN wrote: > > > We can use anonymous resources as subject or object of a statement. > > Why not as the predicate ?? > > > > [my:Car] --[ ]--> [my:Engine] > > How do you serialize that in RDF ? With the current syntax, you just can't :) I was making the proposition from the point of view of the model. Pierre-Antoine -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Bill Watterson -- Calvin & Hobbes) From A.Kassahun@InfoRay.NL Mon Nov 27 16:38:31 2000 Date: Mon, 27 Nov 2000 17:38:31 +0100 From: Ayalew Kassahun A.Kassahun@InfoRay.NL Subject: [RDF] Where can get Template v2, FreezeThaw, DBD::Pg, and PostgreSQL mo dules Hi there, I want to use (experment with) WRAF RDF-Service. But I should first install (it is in the readme file) a number of modules. I did install someof them, but I cannot locate the following modules (listed below). Can you help lease tell me where I can find them? Template v2 FreezeThaw DBD::Pg PostgreSQL Thanks in advance, Ayalew Kassahun From jonas@rit.se Mon Nov 27 16:56:55 2000 Date: 27 Nov 2000 17:56:55 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Where can get Template v2, FreezeThaw, DBD::Pg, and PostgreSQL mo dules Ayalew Kassahun writes: > I want to use (experment with) WRAF RDF-Service. I'm glad you're intrested. You can't expect to do anything useful with it yet. There are many things missing. But I would be glad to hear any suggestions abot what to include next. > But I should first install (it is in the readme file) a number of > modules. I did install someof them, but I cannot locate the > following modules (listed below). Can you help lease tell me where I > can find them? That depends on the OS you use and wheter you have a C compiler. The perl modules can all be found at CPAN, via your local CPAN mirror, or at: http://search.cpan.org/ But a local mirror is probably much faster. See http://www.cpan.org/SITES.html > Template v2 http://search.cpan.org/search?dist=Template-Toolkit > FreezeThaw http://search.cpan.org/search?dist=FreezeThaw > DBD::Pg http://search.cpan.org/search?dist=DBD-Pg > PostgreSQL This is a relational database. Not a perl module. You can use other databases if you modify the SQL queries. The PostgreSQL page is here: http://www.postgresql.org/ I'm developing Wraf on Linux. The next alpha will be released this weak. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Mon Nov 27 17:55:28 2000 Date: 27 Nov 2000 18:55:28 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Where can get Template v2, FreezeThaw, DBD::Pg, and Pos tgreSQL mo dules Ayalew Kassahun writes: > Thanks for the fst reply. I am indeed interested and the fact that it may > not do anything useful is not a problem. I will be working on a c/++ vers= ion > (if i will succeed). I wanted to experment with it. I use WinNT and it is > pitty that the modules are for unix/linux systems. Most perl modules are platform independent. You just have to install them to the right location. Some modules are partly written in C and will need to be compiled. You can set up your Perl enviroment so that you can install any module on CPAN; even those that require C compilation. You can substitute PostgreSQL with another DB, such as MS SQL-server or whatever you have. But you may have to adapt some SQL statements embedded in the source. I have thought about making v2 of Wraf partly in C in order to speed things up. You can install most modules by hind, but should find a 'make' program. I have no experience of this myself. A little searching and I found this page mostly english bu a little swedish. You can probably find better pages.=20=20 http://www.webworks.se/se/perl/guider/installera_perl_moduler/ But in theory: You should be able to follow the instructions in the README file that comes with the module, using your make program. You should be able to unpack the package using a recent version of winzip. --=20 jonas@rit.se RIT AB http://www.rit.se Box 70, 428 21 K=E5llered Bes=F6k: G:a Riksv=E4gen 36 Tel: +46 (0)31 751 8600 Fax: +46 (0)31 751 8609 From begeddov@jfinity.com Tue Nov 28 05:28:10 2000 Date: Mon, 27 Nov 2000 21:28:10 -0800 From: Gabe Beged-Dov begeddov@jfinity.com Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) Jonas Liljegren wrote: > But we can't use the outmost Description bag as the model. What do you mean by the outmost Description bag? My understanding is that reification of rdf:Descriptions will occur to all syntactic instances irrespective of whether they are top-level in the syntax or nested. Below is an explicitly labelled example and the resulting statements that are obtained by applying the StatementBag and Statement reification algorithm. I've included a typedNode shorthand on the first top-level resource for variety. ============================================== http://somedoc.rdf: a value another value ============================================== Ground statements: [http://somedoc.rdf#res1, prop1, http://somedoc.rdf#res2] [http://somedoc.rdf#res1, rdf:type, typedNodeURI] [http://somedoc.rdf#res2, prop2, "a value"] [http://somedoc.rdf#res3, prop2, "another value"] Reified Statement resources: [http://somedoc.rdf#stat1, rdf:type, rdf:Statement] [http://somedoc.rdf#stat1, rdf:subject, http://somedoc.rdf#res1] [http://somedoc.rdf#stat1, rdf:predicate, prop1] [http://somedoc.rdf#stat1, rdf:object, http://somedoc.rdf#res2] I couldn't explicitly label the next statement with a statement ID since it occurred indirectly in the source document. The processor has generated an ID for it, in this case "genid1". [http://somedoc.rdf#genid1, rdf:type, rdf:Statement] [http://somedoc.rdf#genid1, rdf:subject, http://somedoc.rdf#res1] [http://somedoc.rdf#genid1, rdf:predicate, rdf:type] [http://somedoc.rdf#genid1, rdf:object, uriForTypeNode] [ reification for stat2 ] [ reification for stat3 ] Bags representing the Descriptions in the source: [http://somedoc.rdf#stat_bag1, rdf:type, rdf:Bag] [http://somedoc.rdf#stat_bag1, rdf:_1, http://somedoc.rdf#genid1] [http://somedoc.rdf#stat_bag1, rdf:_2, http://somedoc.rdf#stat1 ] [http://somedoc.rdf#stat_bag2, rdf:type, rdf:Bag] [http://somedoc.rdf#stat_bag2, rdf:_1, http://somedoc.rdf#stat2 ] [http://somedoc.rdf#stat_bag3, rdf:type, rdf:Bag] [http://somedoc.rdf#stat_bag3, rdf:_1, http://somedoc.rdf#stat3 ] ======================================================= > The uri of > the model will be the uri of the document. It will have metadata > stating things about it's encoding, namespaces used, time of > retrieval, authority, and more. I've been thinking about this a little. I'm wondering whether we might want another level of indirection between the base URI of the document and the resource from which we hang both metadata (like that which you've described) and the document contents themselves. This indirection allows multiple versions of the document to exist and indicate that we have a representation of the source document that is based on a particular access pattern (kind of like the info that an HTTP proxy maintains). Below is an attempt to capture this in rdf syntax for the example above. The statementBags property would chain the statement Bags to the Model instance. The Bags in turn chain the reified statement resources. We then have a complete tracing from a particular access to a source document down to the statements that occurred in that document. If we didn't have this complete tracing then we wouldn't be able to trace statements and statement bags contained in a document varying over time since the statements and statement bags have the document URI as thier identifer and different versions can't be distinguished without the chaining from the unique resource that represents the particular access to the document. timestamp timestamp timestamp ... ... ModelAccess is outside of anything that the M&S has touched on but I think it is very important for getting the next level of context needed for manipulating RDF on the web where context is everything. We seem to be converging on an interpretation of the spec that provides for statement and description tracing. This is the next level that threads the statements and descriptions to a specific document access. Gabe -- --------------------------- http://www.jfinity.com/gabe From dave.beckett@bristol.ac.uk Tue Nov 28 11:05:49 2000 Date: Tue, 28 Nov 2000 11:05:49 +0000 From: Dave Beckett dave.beckett@bristol.ac.uk Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) [plea: can we keep this RDF model discussion on just one list - the RDF Interest Group list - RDF-IG? I'm getting 2-3 copies of every message in these threads. RDF-IG is the main RDF list.] >>>Gabe Beged-Dov said: There seem to be some slight typos in your example: > Below is an explicitly labelled example and the resulting > statements that are obtained by applying the StatementBag and > Statement reification algorithm. I've included a typedNode shorthand > on the first top-level resource for variety. > > ============================================== > > http://somedoc.rdf: > > > > > a value > > > > > > another value > The last one probably should be another value i.e. introducing stat_bag3 mentioned below and ending prop3 correctly And the resulting file (when given rdf:RDF wrapper) parses OK with Redland+Repat and produces pretty-much the following triples (same count, didn't check they were exactly identical). > > ============================================== > > Ground statements: > > [http://somedoc.rdf#res1, prop1, http://somedoc.rdf#res2] > [http://somedoc.rdf#res1, rdf:type, typedNodeURI] > [http://somedoc.rdf#res2, prop2, "a value"] > [http://somedoc.rdf#res3, prop2, "another value"] > > Reified Statement resources: > > [http://somedoc.rdf#stat1, rdf:type, rdf:Statement] > [http://somedoc.rdf#stat1, rdf:subject, http://somedoc.rdf#res1] > [http://somedoc.rdf#stat1, rdf:predicate, prop1] > [http://somedoc.rdf#stat1, rdf:object, http://somedoc.rdf#res2] > > I couldn't explicitly label the next statement with a statement ID > since it occurred indirectly in the source document. The processor > has > generated an ID for it, in this case "genid1". > > [http://somedoc.rdf#genid1, rdf:type, rdf:Statement] > [http://somedoc.rdf#genid1, rdf:subject, http://somedoc.rdf#res1] > [http://somedoc.rdf#genid1, rdf:predicate, rdf:type] > [http://somedoc.rdf#genid1, rdf:object, uriForTypeNode] > > [ reification for stat2 ] > > [ reification for stat3 ] > > Bags representing the Descriptions in the source: > > [http://somedoc.rdf#stat_bag1, rdf:type, rdf:Bag] > [http://somedoc.rdf#stat_bag1, rdf:_1, http://somedoc.rdf#genid1] > [http://somedoc.rdf#stat_bag1, rdf:_2, http://somedoc.rdf#stat1 ] > > [http://somedoc.rdf#stat_bag2, rdf:type, rdf:Bag] > [http://somedoc.rdf#stat_bag2, rdf:_1, http://somedoc.rdf#stat2 ] > > [http://somedoc.rdf#stat_bag3, rdf:type, rdf:Bag] > [http://somedoc.rdf#stat_bag3, rdf:_1, http://somedoc.rdf#stat3 ] Is the above: Happening because you explicity added bagID attributes to every typedNode / Description (/container?) [True, in existing apps.] Happens anyway with generated IDs anyway when you don't give bagIDs [Not necessarily true in current apps.] or you are proposing that this is the interpretation? I do like these ideas and would support that, as a standard interpretation. Dave From jonas@liljegren.org Tue Nov 28 13:09:55 2000 Date: 28 Nov 2000 14:09:55 +0100 From: Jonas Liljegren jonas@liljegren.org Subject: [RDF] Re: Klyne Contexts: 5.2 Contexts as statements Jonas Liljegren writes: > Graham Klyne writes: > > > I am finding this is a difficult area. Some days it is clearer than > > others. Let me draw out a few points: > > > > - The focus here is on description rather than inference (though with > > an eye to limited inference that allows descriptions to be simplified). Let us drop the discussion specific to the examples, and concentrate on the general issue. My goal is to have containers of statements in order to handle who is saying what and what can be trusted. One person can say S1 and another person can in S2 say that S1 is false. I would like a common model to talk about groups of statements. And those groups can consist of statements from several diffrent models. I have written about it here: http://www.uxn.nu/pipermail/rdf/2000/000135.html http://www.uxn.nu/pipermail/rdf/2000/000168.html -- / Jonas - http://jonas.liljegren.org/myself/en/index.html From begeddov@jfinity.com Tue Nov 28 17:16:12 2000 Date: Tue, 28 Nov 2000 09:16:12 -0800 From: Gabe Beged-Dov begeddov@jfinity.com Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) Dave Beckett wrote: > > [plea: can we keep this RDF model discussion on just one list - the > RDF Interest Group list - RDF-IG? I'm getting 2-3 copies of every > message in these threads. RDF-IG is the main RDF list.] I agree. My previous message had wraf-rdf and rdf-interest as the only lists. I didn't want to remove wraf since Jonas had added it and its his list :-). > There seem to be some slight typos in your example: Sorry about that. The url for the source document was pretty funky too. Hopefully my intent was pretty clear though. > The last one probably should be > > another value > > > i.e. introducing stat_bag3 mentioned below and ending prop3 correctly > > And the resulting file (when given rdf:RDF wrapper) parses OK with > Redland+Repat and produces pretty-much the following triples (same > count, didn't check they were exactly identical). It would be a nice exercise to try this out on the various parsers. Stefan Kokkelink has added an amended version of this syntax example to his online parser demonstration [1] for Cara as example E9. He hasn't added the rdf:bagID to last description (stat_bag3) which as you inferred was my intent. > Is the above: > > Happening because you explicity added bagID attributes to every > typedNode / Description (/container?) [True, in existing apps.] > > Happens anyway with generated IDs anyway when you don't give bagIDs > [Not necessarily true in current apps.] > > or you are proposing that this is the interpretation? I do like > these ideas and would support that, as a standard interpretation. Explicitly adding bagID seems to trigger the reification in most (all?) current parsers. Presence of property ID triggers it in some. In addition, some current parsers provide a configuration setting to cause the riefication and bagification of statements without explicit bagID and property ID ("show bags for each description block" in the Cara demonstration). As you say, I am proposing that we assume that a conformant parser must generate the bags and reified statements. Once we take that step we can then discuss how to provide straightforward and efficient API and implementations based on a standard interpretation. Gabe [1] http://zoe.mathematik.Uni-Osnabrueck.DE/RDF/parser.html From jonas@rit.se Tue Nov 28 19:40:10 2000 Date: 28 Nov 2000 20:40:10 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] 0.04 I thought that I would have it out last week. But I come across a new problem. It's like this. The core representation of the RDF data is spearate from those of the interfaces. Changes in memory has to be followed by changes in the interface. It is the session that connects to the interfaces. That means that the session is created before there is a interface to store the session properties. This means that the session data never gets stored in the DBI interface. I have now added data to track whether a resource has been saved or not. The idea is to differ between static and dynamic properties and types. Statements will be saved if they haven't been saved and if they are used in another statement. Some data is not of a permanent type and should not be saved. This should get the sessin data saved at the point of the storage of other data that referes to the session. Will probably take a couple of more days... -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From jonas@rit.se Tue Nov 28 21:20:39 2000 Date: 28 Nov 2000 22:20:39 +0100 From: Jonas Liljegren jonas@rit.se Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) Gabe Beged-Dov writes: > Jonas Liljegren wrote: > > > But we can't use the outmost Description bag as the model. > > What do you mean by the outmost Description bag? There is no outmost Description bag. That's why we can't use it as the model. :-) > My understanding is that reification of rdf:Descriptions will occur > to all syntactic instances irrespective of whether they are > top-level in the syntax or nested. My first reaction was that we maby could use the bagID as the model id. But we can't do that. > Below is an explicitly labelled example and the resulting statements > that are obtained by applying the StatementBag and Statement > reification algorithm. I've included a typedNode shorthand on the > first top-level resource for variety. Great! It's nice to see some examples. > > The uri of the model will be the uri of the document. It will > > have metadata stating things about it's encoding, namespaces used, > > time of retrieval, authority, and more. > > I've been thinking about this a little. I'm wondering whether we might > want another level of indirection between the base URI of the document > and the resource from which we hang both metadata (like that which > you've described) and the document contents themselves. This > indirection allows multiple versions of the document to exist and > indicate that we have a representation of the source document that is > based on a particular access pattern (kind of like the info that an > HTTP proxy maintains). It's possible to have several readings of the same document by placing the metadata itself in diffrent models (or bags). New version of schemas should have new URIs. We can still save older versions of schemas that changes without changing the URI. But we need a standard way to represent models and I think that the base URI can be simple enough. Your example: > http://somedoc.rdf: > > > > > a value > > > > > > another value > Here is an example of how I was thinking of storing a model (using 'doc:' as namespace) (using [sta, sub, pred, obj]): [doc:stat1, doc:res1, prop1, doc:res2] [doc:genid1, doc:res1, rdf:type, typedNodeURI] [doc:stat2, doc:res2, prop2, "a value"] [doc:stat3, doc:res3, prop2, "another value"] [s1, http://somedoc.rdf, rdf:type, Model] [s2, http://somedoc.rdf, rdf:_1, doc:stat1] [s3, http://somedoc.rdf, rdf:_2, doc:genid1] [s4, http://somedoc.rdf, rdf:_3, doc:stat2] [s5, http://somedoc.rdf, rdf:_4, doc:stat3] Model is subClassOf Collection (or Bag). And to differentiate between diffrent statings about the content of the model, we place the metadata itself in a Selection: [s6, m1, rdf:type, Selection] [s7, m1, rdf:_1, s1] [s8, m1, rdf:_2, s2] [s9, m1, rdf:_3, s3] [s10, m1, rdf:_4, s4] [s11, m1, rdf:_5, s5] And also s6-s11 will be placed in a model. There is no end to it. But in Wraf I implement it by storing a model for each stating and lets a lot of things be implicit. > Below is an attempt to capture this in rdf syntax for the example > above. The statementBags property would chain the statement Bags to > the Model instance. The Bags in turn chain the reified statement > resources. We then have a complete tracing from a particular access to > a source document down to the statements that occurred in that > document. If we didn't have this complete tracing then we wouldn't be > able to trace statements and statement bags contained in a document > varying over time since the statements and statement bags have the > document URI as thier identifer and different versions can't be > distinguished without the chaining from the unique resource that > represents the particular access to the document. It will not help to just have diffrent resources for each access to the document. The statement IDs will be the same but the statement will differ. Consider: [http://somedoc.rdf#stat1, rdf:type, rdf:Statement] [http://somedoc.rdf#stat1, rdf:subject, http://somedoc.rdf#res1] [http://somedoc.rdf#stat1, rdf:predicate, prop1] [http://somedoc.rdf#stat1, rdf:object, http://somedoc.rdf#res2] [http://somedoc.rdf#stat1, rdf:type, rdf:Statement] [http://somedoc.rdf#stat1, rdf:subject, http://somedoc.rdf#SomeThing] [http://somedoc.rdf#stat1, rdf:predicate, completely] [http://somedoc.rdf#stat1, rdf:object, http://somedoc.rdf#Diffrent] My way of handling this is to put these statings in diffrent models. But if the base URI is the same, and it's the base URI that is the model, I can't do it. I guess you're right. We must have local control over the model URI. > > > timestamp > timestamp > timestamp > ... > ... > > > > > > > > > > ModelAccess is outside of anything that the M&S has touched on but I > think it is very important for getting the next level of context > needed for manipulating RDF on the web where context is everything. Absolutly. I take it you will write a proposal of a schema for this. ;-) But I wan't all the basic statements in the model. Not just the statementBags. I could suffice with them. But I would still generate a complete list of statements in the model, because that's what I will use in the application. The uses of the statementBags are not as many. Maby we could have (support for) both: > > > timestamp > timestamp > timestamp > ... > ... > > > > > > > > But I would like to subclass Bag to give it more meaning. -- / Jonas Liljegren The Wraf project http://www.uxn.nu/wraf/ Sponsored by http://www.rit.se/ From begeddov@jfinity.com Wed Nov 29 05:05:38 2000 Date: Tue, 28 Nov 2000 21:05:38 -0800 From: Gabe Beged-Dov begeddov@jfinity.com Subject: [RDF] Re: tracing statement origin (was Re: I have a trouble with The RDF Model) Jonas Liljegren wrote: > > > > > > timestamp > > timestamp > > timestamp > > ... > > ... > > > > > > > > > > > > > > > > > > > > ModelAccess is outside of anything that the M&S has touched on but I > > think it is very important for getting the next level of context > > needed for manipulating RDF on the web where context is everything. > > Absolutly. I take it you will write a proposal of a schema for > this. ;-) I'll add it to the work queue. > But I wan't all the basic statements in the model. Not just the > statementBags. I could suffice with them. But I would still generate > a complete list of statements in the model, because that's what I will > use in the application. The uses of the statementBags are not as > many. > > Maby we could have (support for) both: This is happening in a hierarchical manner in the approach I outlined. I can see that having an additional index of all the statements hanging off of the top-level resource would be useful. I can also see other ways of achieving this in an implementation based on the information that is available. The members of the Bag pointed to by ModelAccess->statementBags a