RDF Schema editor 0.04
Date: Mon, 02 Aug 1999 03:45:25 +0200 From: Jonas Liljegren <email@example.com> To: RDF Developers <firstname.lastname@example.org> Subject: Announce: RDF Schema editor 0.04
Experimental test at this URL: http://paranormal.o.se/perl/dist/RDF_0_04/rdf.cgi
Previous versions stopped working because I use mod_perl. The program would use the new incompatible libraries (modules) instead of the older stored at the local directory. For 0.04, the module name was changed, just to avoid that problem. The presence of properties with the range Resource will slow down the edit page in this version. CHANGES (from 0.02): * Support for containers. * Special handling of Literals, Resources and ContainerMembershipProperty TODO: * languages * adding new objects from the edit page * aboutEachPrefix * namespaces * reified statements * optimizations * error handling DESCRIPTION The RDF Schema editor is an experimental prototype for viewing, editing and navigating in RDF data, based on RDF Schemas. The goal is to find out what functions and tools are needed for my project (descibed below). After the completion, I may rewrite the API, based on discussions and the experience. This is a overview of the design: The Schema editor is a program using a couple of general RDF modules. There are nine classes. Three layers and three classes per layer. Schema Model Resource Statement Simple Model Resource Statement Source/x Model Resource Statement The schema editor program is using the Schema::Model class. This class inherits from Simple::Model, and that class inherits from Source::x::Model, there 'x' is specified in the call to the Schema::Model constructor. The Model object will be used to construct Resource and Statement objects. The Schema layer contain all logic and functions specific to the RDF Schema Specification. To only get the functions for the RDF M&S Specification, you would use the constructor in the Simple::Model class. The Schema and Simple layers are programmed to not know anything about the storage of the RDF data. They use the methods in the Source layer, using the specified source class. I am only using the Source::DBI classes, that uses the perl DBI module to access a database. My little project ----------------- My goal is to construct a dynamic website resembling a hypertext lexicon, but with automated links to related topics, based on metadata. These would be groupd by things like * community members intrested in this topic * books about the topic * movies about the topic * articles about the topic * Broader topics that include the topic * Topics that go into detail about the topic * Same topic in diffrent viewpoints * Comments on the topic * News on the topic * Organisations intrested in the topic * Upcoming events regarding the topic This for potential thousends of topics. All data would belong to diffrent classes, like member, book, news, comment, etc. Each class will expect diffrent data. A book could have data about its author ( that could be a single author or a bag of them ), the title, its publisher, etc. Many books will have a limited set of data. But some book pages will include things like "this book contains a foreword by that author". The point is that The data of the book should be dynamic. It should link to whatever comes up. And books is just one of many, many things. It could be a subclass to "media". A community member would be a subclass of a person. Persons could also be authors, or just someone referred from one or more topics. The web will grow by user contribution. -- / Jonas - http://paranormal.o.se/myself/index.html
Prepared by Robin Cover for the The SGML/XML Web Page archive.