Sinzui

Too many discussions have gotten out of hand on a couple of the GNOME lists I subscribe too. I think the arguments could be completed in fewer exchanges if each correspondent could send a code that indicated their position on the hot issues in GNOME. For instance we could save time arguing about spacial vs. hierarchical desktops if each person also state their feelings about desktop=home and just-works vs. configurability. We could have a code like geek code + for, – against, 0 for no position.

1. spacial desktop {+}
2. desktop is home {+}
3. configurability {-}
4. file open dialog {-}
5. notification applet instead of window list {-}
6. close last window quits app {-}
7. desklets {-}
8. copy window make GNOME usable {-}
9. users love splash screens {-}

I've scraped a lot of addresses, lists, and channels off the gnome.org sites. Too much for the contact page. I need to better define it's scope to limit the content so I can settle on how best to present it. We may want to break the contact page into one for users and another for developers. I think we should also include http://www.gnomesupport.org/ since it has a lot of feature users need that are not provided by gnome.org.

I made some small, but import changes to the Medusa GUI app I'm making. The sidebar is near complete. I'll swipe the file list from gnome-search-tool in a few days. After that, I'll create a rules editor like g-s-t and Evolution has to explore another UI option.

I finally closed some Medusa bugs now that the fixes are in HEAD. Hurricane Isabel's distractions delayed me for a few days. I got a reply from Calvin Smith who seemed pleased that his patch was finally applied–two years after he submitted it. I have another set defects almost fixed. I'll close them with the 6.1 release which targets Nautilus. I finally located my sophomoric error in the signal handling of the GUI Medusa search tool I'm making. I think the rest of the changes will go quickly and I hope to have Medusa ready to provide Nautilus with the search functions it needs. The next biggest lot of bug is the indexer, which I hope to close in October.

The application server I work with at Time Life thinks it's god. Well it is not, and when it screws up it really makes a mess of things. The EJB's manage by PowerTier are stored in and Oracle schema without constraints, not unique, not null, or foreign key rules. We have seven malformed products that the app server cannot delete since it cannot instantiate the object. The XML interface cannot retrieve all the parts of the product to make a valid description. This isn't the first time this has happened, but even with all the tools I've put to gather to correct the constraints I've deduced, I take a lot of time to locate what must be manually removed before the tools can be run.

Honestly, if and object or XML system wants to use and relational DB, then it the data must conform to relational rules. If not, then use the filesystem. With a filesystem, I stand a good chance of fixing corrupted data because there are a lot of tools available; there are few tools that can fix malformed data in a configured DB.

I've merged my changes into Medusa HEAD. Medusa now runs as a user indexer and search tool. I haven't committed any of my GUI experiments for a GUI finder, and Nautilus integration. Medusa will index a user's home directory, files and file content, and msearch can query the db.

I added Guile-gtk/Guile-gobject to the GNOME language bindings page. The project decided to develop GNOME2 as a subproject instead of refactoring Guile-gtk. Scheme really hurts my head. Reading it is such a pain. I cannot forgive Gerald Sussman for creating it, though I can forgive Guy Steele since he made contributions to the Java language, and published the Hackers Dictionary (the Jargon File). As for Guile's ambition to be the default scripting language for applications, it shouldn't be. It's might be simple, but it isn't comprehensible to the average programmer, let alone user.

I fixed the make distcheck so tarballs of the working (not HEAD) version can be distributed. I made my changes in a second tree because my tree is very dirty with GUI experiments. I'll need to resolve the conflicts in my gui tree before I can return to my experiments. I'm adding a GUI search tool modeled upon gnome-search-tool. My GUI experiments are for Nautilus, but I'd like to reuse some of the code instead of throwing it away. Providing a desktop tool with Medusa will prove the GUI components are portable, provide an example of how to use them, and make it easier for users/developers to take advantage of Medusa without Nautilus.

The Sutra data model is strongly influenced by Friend of a Friend vocabulary (FOAF), originally proposed by Edd Dumbill. In this draft of Sutra's ontology, the world is made up of two general kinds of objects, Agents and Documents. Noticeably absent from the diagram below are events and a class representing services and software, and they will be addressed in the future. Sutra uses RDF-Schema to define object types, but XML-Schema, and similar mechanism could be used in the future. In most cases, a resource may have many instances of a particular property–a person made (property) many resources, and each will have several topics (properties).

Things that cause change are represented by a resource called an Agent (rdfs:Class). The agent's properties describe it's online identity. The most common form (rdfs:SubClass) of agent is a Person, whose properties may describe real world attributes. Agents may be represented (rdfs:SubClass) as Groups, Projects, or Organizations. Sutra uses Agent because it a crucial resource for establishing relationships between resources. Much of the agent information will be derived from, and interact with, personal information apps like Evolution, and external sources like LDAP and Web sites. See the FOAF documentation for the definition of Agents and their properties.

Documents are things that agents create. Documents are digital artifacts that represent information in Sutra. The properties of the basic Document correspond well with both Nautilus and Web browsers. Nautilus displays document type, thumbnail, icons, and emblems, which compares well to format, thumbnail, logo, and topic respectively. Note that Medusa currently indexes emblems as keywords for searches. Web browsers use content-type, icons, and keywords/classification for bookmarks, which likewise agree with format, thumbnail, logo, and topic.

A Document's properties can be augmented with Posix and DC (Dublin Core) properties from a file system or the Internet. A document may have only one of each property from Posix or DC. There are many subclass of Document that represent basic kinds of data, and their intrinsic properties. Audio files have recording/playback properties, and some like OGG will have ID3 properties about artist and title. Image meta data varies considerably between formats, most have dimension properties, and the EXIF subclass used by digital camera adds additional properties. The Video type is an example of what might be done, more research is needed to understand what technical and creative properties are used. The XML document type only offers encoding and language because little is known about a grammar without a schema. It's feasible to parse XML for known meta data grammars, like Dublin Core. Two common XML (and SGML for many older forms) grammars are HTML (Page) and DocBook. The Office type represents writings, spreadsheets, from office suite software, and PDF/PostScript documents.

In the Sutra data model, a subclasses inherit properties from their super class, so an Office document would have Office properties, plus Document, plus Resource. It may have additional properties from Posix or DC. If an the data model were extended with ad hoc classes or Office was redefined via RDFS to descend from another class, it would gain more properties. For instance, if a Usage class representing frequency, access, and who by were registered as an extension of Resource's properties, Office would acquire them too.

Sutra is a proposed metadata database. It stores and retrieves data about local and remote resources such as files and people. Some properties are intrinsic to the resource, like image size or music artist. Other properties are external, such as filename or creator. Resource properties are discovered through incident, and attributed in an ad hoc fashion. Properties names and purposes are not rigorously defined, nor required, including intrinsic properties. Sutra requires an extensible data model and a flexible database to accomplish its purpose.

The Storage schema is simple: ChildNode where anonymous, numbered resources are linked, three attribute tables where resources keep their named properties, TextRecords where resource content is stored, and two tables to issue and record resource ids to link everything. This schema has some short comings. Some links between resources are named, but cannot be represent, for instance, the author of resource might be represented by an entry in an address book, and that in turn might link to a homepage. In this scenario the link is both an attribute and a ChildNode, but that cannot be easily represented in the database. Named links could be put in the NumberSoup table, but there is no means to indicate that the number isn't a literal value, but a reference to another ChildNode. The operational data about how attributes work can be stored in the attribute tables, mixing with the content data, but this can lead to conflicts between libstorage, and the content it manages. Additionally, there is no namespace facility to prevent attribute name collision between different kinds of resources. There is no means to define attribute names, their use, and to what they belong. The three attribute tables represent only three simple data types, and cannot manage more complex or refined data types like URIs, or bytes, but that is the very type of data it proposes to store.

The Sutra schema is simple and it addresses Storage's problems by moving and consolidating property information, and adding a table to store type information. The Resource table stores resources by unique id and URI, and resource literal and link properties are stored in the Property table. The Type table defines all properties, and is linked to the Property name column. The Content table is identical to Storage's TextRecord table.

The Resource table represent resources in two ways, by a unique numeric id and a unique URI. The uid is used is a foreign key in the Property and Content tables. The URI must be valid, and may be real. Anonymous resources are represent by valid, but meaningless URIs.

The Property table represents the union of Storage's three attribute tables and ChildNode's link responsibility. The resource and type columns are foreign keys representing the Resource and Type tables respectively. The value is a string because it is the most versatile format to represent data types as exemplified in XML-Schema. Most data Storage deals with is string data, so little work will be needed to convert it. In the rare case of numbers and dates, comparison operations can easily and efficiently be accomplished with correct encoding. The isliteral column is a flag indicating that the value is not a foreign key pointing to a resource. The weight column represents a means to order and identify properties that have the same resource and type. It is a mutable id that might be changed by applications to indicate the higher valued properties are more relevant and commonly used. There are scenarios where the value might point to a resource, but the application saving the information chooses to save the literal value. Typing information could be used to declare whether a value is literal or link, but that can lead to problems when there is no resource to link to, or resource table is filled with entities that represent leaf nodes. The property value can be converted from link to literal as needed.

The Type table contains the definition of the types of properties in the Property table. Each type has a unique id. The namespace column is a token indicating to which group the property type belongs. It is synonymous with XML-Namespace and similar to namespace in some programming languages. The property column is the name of the type and used for external representations of the properties. The datatype column indicates the kind of data a property is an how it should stored as defined in XML-Schema data types. The domain column comes from RDF-Scheme where objects can be defined as classes (resources), or properties. Domain is a foreign key linking to another entity in the Type table. In the Sutra model, classes and properties are stored in the same table and used similarly. The super column is a foreign key pointing to the super type of the type. The type table provide a means to define all the kinds of resources and properties in the database. Strong and week queries can be performed by restricting property matching to exactly a property, or to a group constructed from the super relation of properties respectively. Applications can extend and explore the data in the type table to store new kinds of data in the database and query it. The domain is used to distinguish between properties that define major objects (resources) and those that define minor objects (properties). The property concept from RDF-Schema allows properties to be attributed to resources in an ad hoc fashion–classes do not require attribute. A resource acquires properties by context (namespace). For example, an image has intrinsic properties like width and height, plus properties like filename and size because it is stored on a file system.

The Content table contains file data. It represents the body of a resource, when a resource is a digital artifact that has a body, such as an document. Storage does not know the structure of files, so while a file might be a compound document of several kinds of content, it is stored as a single block.