Product | Planning | Teams | Developers | Notes

r6 - 21 Jan 2004 - 11:53:53 - MimiYinYou are here: OSAF > Jungle Web > DataModelJunglePages > DataModelFeatureDetails

Data Model Feature Details

In May/June 2003, a few of us got together for a series of meetings about what features the data model should have. This document started as a distillation of the meeting notes from those meetings. It may also include some new material, or material from other documents.

The goal for this document is to try to reflect our current thinking, and to describe the data model features in a fair amount of detail.

If you'd rather see a summary document, try one of these:

If you want to see the actual meeting notes, they're also available:

Goals

Here are a few of the design goals for the data model:

Meet the needs of parcel programmers -- These are people like the OSAF engineers, who are writing parcels like the OSAF calendar parcel and the OSAF e-mail parcel. Also third-party programmers who are writing their own parcels. Parcel programmers need fixed schemas, strong typing, and guarenteed enforcement of schema restrictions. Parcel programmers are used to thinking about data modeling features from object-oriented programming languages -- inheritance, pointers, etc
Meet the needs of end users -- These are end users who are using Chandlers general purpose info management tools to keep track of unstructured data, and to add structure incrementally. These users need flexible schemas, weak typing, and the ability to easily make ad-hoc changes. These users are used to keeping their records in tools like Excel, or Filemaker Pro, or Access -- which offer slightly different data modeling features.
Design something that can be implemented -- Keep it simple. Don't undertake any research projects.
Avoid creating "made up" requirements

Snakes/Dragons

Sharing data, sharing schema
Schema editing, schema evolution
Query, indexing (we have some rough agreement, still to be worked out)
Versioning. Recommendation: implement this as an application feature, not a general repository feature.
Merge/Sync more than two repositories.

Block Diagram

      +--------------------------+   +---------------------+
      | Chandler PIM Schema      |   | Third-party schemas |
      | ("e-mail message",       |   |                     |
      |  "calendar event",       |   |                     |
      |  "address book contact", |   |                     |
      |  "note", etc.)           |   |                     |
      +====================================================+ <-- Repository API
      | Schema Library                                     |\
      | (generally useful items -- e.g. "Enums"            | \
      +----------------------------------------------------+  > "General Schema Layer"
      | Schema of the Schema                               | / \
      | ("Kind", "Type", "Schema", "Attribute Definition") |/   \ 
      +----------------------------------------------------+     > "The Data Model"
      | Building Blocks Layer                              |    /
      | ("Item", "Container", "Attribute", "Item-Ref")     |   /
      +----------------------------------------------------+__/

Terminology

We settled on the following terminology:

reserved words:
- "Item" -- a bunch of attribute values -- pretty much everything is an item -- e.g. "Lunch with Pat"
- "Attribute Definition" -- e.g. "Start Time"
- "Attribute Value" -- e.g. "2:30 pm"
- "Kind" -- a category of items -- a Kind has a set of Attribute Definitions -- e.g. "Calendar Appointment"
- "Type" -- a type of literal -- "int", "float", "unicode string", etc.
- "Item-Ref" -- a reference from one Item to another -- e.g. "Employees<-->Department"
- "Domain Schema" -- a set of Kinds and global Attribute Definitions -- e.g. the "Baseball Schema" or the "Chandler PIM Schema"

non-reserved words:
- "thing" -- no special meaning in Chandler -- just another fuzzy English langauge word
- "schema" -- no special meaning in Chandler -- just another fuzzy English langauge word

Building Blocks

At the Building Blocks Layer:

Everything is an Item
- Items can have Attributes
  - Items are essentially a dictionary of Attributes
- all Items can be accessed through a UUID
  - this is a globally unique id, unique across all repositories
- all Items can be accessed through a Path
- each Item has a "name"
  - the name may or may not be unique within a Container
  - this is not a user-level display name
Some Items are Containers
- a Container is just an Item and has all the aspects of an Item
- additionally, Containers contain a bunch of other Items
- Containership is purely for "house cleaning"
  - Containership DOES NOT IMPLY ANY SEMANTICS
- Containers are a facility for the developer, not a facility that the end user need be aware of.
- every Item is owned by exactly one Container
- when a Container is deleted, all the contained Items are also deleted
All semantic references are implemented via Item-Refs
- Items never have pointers to each other, except via Item-Refs
- An Item-Ref is an object that is not an Item
- An Item-Ref can point to an Item, or to another Item-Ref
- One Item-Ref connects two Items, via two Attributes, one on each Item
- Item-Refs can have policy definitions that dictate how to handle Item lifecycle events, like what to do when an Item is deleted or cloned. The policy definitions can dictate when to do deep copies and when to do shallow copies, whether to include sub-items in a delete operation, etc.
A Path can be used to identify an Item
- A Path is a system level thing, not an end-user thing
- users would not see Paths or type in Paths
- programmers, doing debugging, might type in Paths
Attributes can have Attribute Values
- some Attribute Values are Literals, like a float or an int or a string
- some Attribute Values are Item-Refs
Conceptually, there are just three things: Items, Containers, and Item-Refs (plus minutia like Attributes, Literals, etc.)

General Schema Layer

Moving up from the Building Blocks Layer, the rest of this document focuses more on the features of the General Schema Layer -- the features that will be available to parcel programmers through the Repository API.

The first source of truth for this stuff is the Data Model Feature List. It gives a high-level summary of which features are in and which are out. You should read that document before you read the rest of this one. The rest of this document only has additional notes about the features -- to avoid creating duplicate sources of truth, this document tries to avoid intentionally including copies of the information from the Data Model Feature List.

Items and Attributes

At the level of the Repository API:

We will only persist Items and their Attributes, not random python objects
Every Item has exactly one UUID
An Item can have attributes, and values for the attributes
Every Item is essentially a dictionary with key-value pairs of attributes and Attribute Values
An Attribute Value can be a literal, like the number 14 or the string "Foo"
An Attribute Value can be an Item-Ref
An Attribute Value can be null
An Attribute Value can be a Collection
- A Collection can contain literals or Item-Refs
- A Collection can be a List, Set, Dictionary, or Hash

Inheritance

four kinds of inheritance
- value: an instance inheriting a value from another instance -- similar to derived values -- Andi has found this to be an extremely useful feature
- attribute: a Kind inheriting an Attribute Definition from a "superclass" Kind
- type: for strongly typed schemas, when type-checking, an instance counts as type Foo either when it is an instance of the Foo Kind, or when it is an instance of a Kind which is a "subclass" of the Foo Kind
- behavior: in Python or Java, classes inherit methods from superclasss -- in a database, records do not have behavior -- in our Python mapping for the data model, we will map Python classes to Kinds in the database
we resolved
- to support attribute inheritance
- to support type inheritance
- to support multiple inheritance (and therefore also single inheritance)
  - but, to try not to use multiple inheritance in the Chandler PIM Schema
- to allow an item to be an instance of two kinds
  - but, in the Chandler parcels, not to offer any kind of general data mixing features, but rather in the Chandler PIM Schema, to handle as the E-mail/Task mix as a special case
  - see the dev list discussions with Micah Dubinko:
    - http://lists.osafoundation.org/pipermail/dev/2003-May/000662.html
    - http://lists.osafoundation.org/pipermail/dev/2003-May/000665.html
- the "Building Blocks" layer will provide the foundation for implementing value inheritance -- we want to talk more about value iinheritance later, when we're also talking about derived values in general -- then we need to decide what support we want to offer for value inheritance up at the level of the "Repository API"

"Emergent" typing for kinds vs. Declarative typing for kinds
- see the dev list discussions with Micah Dubinko:
- resolved to pick declarative typing for kinds
- we won't provide any direct support for "emergent" typing, although a third-party parcel developer could write a parcel that had this feature

Attributes

end user vs. parcel programmer
- The end user wants malleable data, the ability to construct arbitrary views and do interesting searches. The programmer wants objects to use when writing code: some reliance on structure, easy persistence, etc. We've struggled with these two design goals, we've occasionally captured this tension as "item centric" vs "object centric". We could also refer to these two things as the "data model" and the "object system" respectively.
- It may be a good idea to formally separate attributes (on a given item) into end-user-visible-attributes and programmer-housekeeping-attributes, where there are different expectations for the different types.

"domain attributes" vs. "house-keeping attributes"
- any given item will have both domain attributes and house-keeping attributes
- domain attributes
  - domain attributes are things that the end-user cares about, like a baseball player's "name", or "age", or "batting average"
  - domain attributes should always be visible to the user
- house-keeping attributes
  - house-keeping attributes are things that the chandler infrastructure code cares about, like "last-modified" time, or "version" number, or a "logically deleted" flag
  - house-keeping attributes may frequently be invisible to the user, although in some cases the user might want to be able to look at them (e.g. "creation date")
- probably users should never be able to edit house-keeping attributes directly

"display names" and "identifier names"
- an attribute definition can have an optional identifier name -- e.g. "startTime"
  - the identifier name syntax restrictions that would work in Python or Java
  - the identifier names must be unique within a Kind
- an attribute definition can have an optional display name, which is what the end-user sees -- e.g. "Start Time"
  - the display names are not required to be unique within a Kind -- we want to be flexible, even though we can imagine this flexibility will make for some headaches later (e.g. in some future text-based query language)
- an attribute definition might also have a URL that uniquely identified it across namespaces, although this might be unnecessary because an attribute definition can always be uniquely identified by its UUID

"global attributes" vs. "local attributes"
- see also: DataModelIssues#Global_Attributes
- an Attribute Definition can be a "global attribute"
  - a global attribute can be used by more than one Kind
  - a global attribute is defined in a Domain Schema
  - a global attribute can be used by Kinds from other Domain Schemas
- an Attribute Definition can be a "local attribute"
  - a local attribute is defined within a single Kind, and used only by that Kind

"sub-attributes"
- see also: DataModelIssues#Sub_Attributes
- we are not going to support sub-attributes for 1.0
- this should be something that could be added after 1.0 without breaking anything (although we did note that it might be difficult to write database code that would be efficient when processing queries on a super-attribute)

Domain Schema Diagram
- We settled on diagram showing how the schema info is organized. I don't have a good way to reproduce the diagram here, but here's what it shows:
  - A Domain Schema item has a collection of Kind items
  - A Domain Schema item has a collection of Attribute Definition items, representing global attributes
  - A particular data item (e.g. "Lunch with Pat") has a defining Kind item
  - A Kind item has a collection of Attribute Definition items
    - some of those Attribute Definition items may be local to this Kind item
    - some of those Attribute Definition items may be global attributes that are in the collection of Attribute Definition items pointed to by the Domain Schema item that is pointed to by the Kind item
    - some of those Attribute Definition items may be "imported" global attributes that are in the collection of Attribute Definition items pointed to by some unrelated Domain Schema item
  - An Attribute Definition item may be pointed to by more than one Kind item
  - An Attribute Definition item may be pointed to by at most one Domain Schema item

Attribute Definitions vs. Attribute Bindings
- When a Kind item includes an Attribute Definition item, the Kind item uses all the general information defined in the Attribute Definition item, which is shared by all the Kind items that use the Attribute Definition item
- In addition, there may be some specific information particular to the use of the Attribute Definition item in this specific Kind item -- information that not's associated with the Attribute Definition item itself, but with the binding of the Attribute Definition item to the Kind item
- Here's a breakdown of what we decided about what information should be associated with the Attribute Definition item and what should be associated with the binding
  - Attribute Definition info
    - "type"
      - could be something like int, float, string, date...
      - could be a specific sort of Item-Ref
      - could be "Any", meaning any of the above
    - "one vs. many"
      - this is really "cardinality" info -- but we want to be clear that we're only offering the two choices, "one" and "many", rather than more complicated things like "4" or "6 to 8"
      - defaults to "many" when a "baseball fan" creates a new Attribute Definition
    - "identifier name"
      - used as a python token -- e.g. "startTime"
    - "display name"
      - appears in the UI -- e.g. "Start Time"
      - can be a simple ASCII string, or a Unicode string, or a "Polyglot string" (meaning a dictionary of localized string translations, keyed by langauge)
  - Attribute Binding info
    - "required"
      - a boolean value -- means the same as "not null" -- the attribute must be included in every instance, and must always have a value
- There are a few different options for storing Attribute Binding info:
  - We could have separate Attribute Binding items between a Kind item and an Attribute Definition item
  - We could somehow associate it with the Item-Ref that relates a Kind item to an Attribute Definition item
  - We could somehow associate it with the the (attribute of the Kind item) that points to the Item-Ref that points to the Attribute Definition item
    - We might be able to do this just by using our "Compound Attribute" idea
  - We didn't pick which option we want -- we'll cross that bridge when we come to it

attributes on attributes
- example: Spot is a dog. Spot has an attribute called "age". Spot's age is "6". Can "Spot's age is 6" have other attributes, that further describe the "age" of Spot? Maybe attributes like "percent certainty", or "error term" or something?
- resolution: no, we're not going to support this

Relationships

Symmetrical Associations
- (see also: DataModelIssues#Symmetrically_Associated_Attribu)
- we will support Symmetrical Associations within a repository, via Item-Refs

Item-Refs
- we will have Item-Ref instances (between two Items)
- we will not have "Item-Ref Definitions" that the Item-Ref instances point to
- End users can create ad-hoc relationships between Items using Item-Refs

strong references and weak references
- we will offer support for both "strong references" and "weak references"
- "strong references" and "weak references" can be implemented via Item-Ref house-keeping policies like "don't delete on delete"
- "strong references" will be used to do garbage collection using something similar to reference counting

referential integrity
- The repository will ensure referential integrity, but only for Item-Ref relationships
- When you delete the item at one end of an Item-Ref, the Item-Ref always goes away

cycles
- We agreed that its ok to have cycles in the schema, the repository will be able to handle it.
- see the dev list discussions with Micah Dubinko:

one-to-many and many-to-many relationships
- we will have support for
  - one-to-one relationships -- via attributes that point to Item-Refs
  - one-to-many relationships -- via attributes that point to Lists of Item-Refs
  - many-to-many relationships -- via attributes that point to Lists of Item-Refs that point to Lists

unilateral relationships
- use case where you might want this: an item needs to know its kind, but a kind doesn't want to know about every item.
- instead of a full ItemRef, the item could reference the kind via the uuid
- the kind/item is a special case (fundamental because it is so common), but similar desired functionality could be required in other cases
- should a "unilateral relationship" be a first class concept in our data model?
  - pro: would be useful to specify unidirectional relationship and say something about the domain/range of the relationship. Useful for introspection. Useful for debugging. Possibly useful for constraint enforcement. Without it, you can't have a self describing schema of schemas
  - con: proliferation of first class concepts complicates the repository. Also, more difficult to enforce range or other restrictions on a unilateral relationship.
- resolved to leave this as an open issue for now.

remote relationships
- How do we handle strong references across repositories?
- questions:
  - do item-refs work across repositories?
  - does garbage collection work across repositories?
  - how can items in different repositories be related?
- answers:
  - trying to get item-refs and garbage collection to work across repositories constitutes a research problem, which we want to avoid.
  - which should only have simple, low-tech mechanisms for cross-repository relationships
- how do we refer to a repository?
  - we might have local repository items that represent remote repositories
  - items might refer to a repository by the repository items, or by having a url that points to the remote repository
- resolved:
  - we will have a separate data type to represent an "external reference" -- an external reference is a weak reference to an item in a remote repository
  - when you subscribe to an item instance in a remote repository, you get a local copy of the remote item
  - you can view items in other people's repositories, but if you're just viewing (not subscribing) then those items never get stored in your repository

Compound Attributes

a compound attribute will just be a normal Attribute Definition, but one that has a list of other component Attribute Definitions
the compound attribute will have all the features of a normal Attribute Definition, like "identifier name", and "display name", and "one vs. many" cardinality
the component-attributes will each have all the features of a normal Attribute Definition, like "identifier name", and "display name", and "one vs. many" cardinality

Indexing

indexes for queries
- in a Domain Schema, Attribute Definitions can be explicitly marked with a flag to declare that they should be indexed (the Domain Schema is in a layer above the Building Blocks)
- we could imagine having the repository try to observe queries and heuristically index, but that would be a research problem, so we're not going to do that
- full text indexes are a special case. Full text indexes will live with the data. We hope to use an existing 3rd party one, but may run into problems, especially getting it to work well with transactions. John's confident it wouldn't be too hard to roll our own if we needed to.
- when a transaction fails (or on rollback), the index needs to be rolled back
- when an item is deleted, the entries for it need to be removed from the index

Queries

goals
- searches of structured data should be fast
- searches of free-form data should be possible

text-based query langauge
- we need to support some kind of programmatic API for submitting a query -- e.g. using some data structure to represent a query
- we don't want to have a text-based query language that requires parsing

joins
- Unlike SQL, we're not doing "joins"

query sorting
- A query may also need to specify some sort of grouping/sorting behavior. Queries don't just return result sets, they return the result set pre-sorted, so that client code can get just a partial result set and then start interating over the entire result set as needed by the UI.

query contexts
- For a query, we often want specify the set of things to look through, and a filter on that set. The key is to narrow the set to be smaller than the whole repository.
  - Kind-specific queries
    - Most queries/searches are done in some context, and you can usually limit the set based on kinds. For example, a query might look for all the e-mail from a given person, so then we only have to look at items of kind e-mail, not all items. And calendar views generally only look at calendar events.
  - Multi-kind queries
    - In some cases, queries span different kinds. A calendar view might be used to view e-mail messages. And a generic table view might be used to look at lots of different kinds of items side by side.
  - Owners
    - The notion of an "owner" seems important for limiting queries. Many items will be owned by one user -- e.g. I own my e-mail. For lots of common queries a user will just want to search through stuff they own -- e.g. I mostly just want to see my calendar, my e-mail, my tasks.
- Most queries will only need to search over the set of InformationItems. InformationItems are things like Email, contacts, appointments, tasks, notes. The set of Items is more general, and might include "system info" items, like items representing parcels, agents, repositories, queries, etc.

Values

(see also: DataModelIssues#Null_Values)

Default Values

Restrictions

A schema designer can place three types of restrictions on attribute values:
- Cardinality restrictions
- Requried (non-null) restrictions
- Data-type restrictions

Cardinality restrictions
- attributes can have cardinalities of One or Many

Required/optional
- attributes can be either required or optional

Strong typing
- Questions:
  - Can we rely on a "startDate" to always be a date, not just some random text string?
  - Is the user restricted from entering invalid dates? Do we do data entry validation?
  - Does the repository do type checking when it gets a request to store a value?
  - Does some layer of code uniformly do type checking whenever a value is retrieved from the repository?
  - Can a GUI parcel programmer trust that something is what it's supposed to be, or does that person have to do defensive coding everywhere?
  - Should there be some code that does a repository validation sweep, traversing the repository and ensuring that it is valid?
- Answers:
  - A schema can specify that some Attributes are strongly typed
  - A schema can specify that some Attributes are not strongly typed
  - For strongly typed Attributes, we build the plumbing such that the GUI parcel programmer can blindly trust that the Attribute will never get a value of the wrong type
  - For Attributes that are not strongly typed, an end user is free to enter whatever value they want (e.g. via an tool like the SuperWidget^?)
  - For Attributes that are not strongly typed, when the Attribute Value is stored in the repository, we have to also store something telling us what "type" the value is (e.g. if we store xF800, we need to know whether it's a int or a string)

Item Versions

item versions
- this is a snake/dragon
- what would it mean to have garbage collection in a system with change logs and item histories?
- what would it mean to have an explicit delete operation in a system with change logs and item histories?
- supporting item versions in a general way could end up being a research project
- resolution: we recommend that any item version features should be implemented on a case-by-case basis up in the application parcel code, rather than having the repository offer any kind of ubiquitous general-purpose version mechanism for all items

Deletion

explicit delete
- in addition to garbage collection, we will also provide for an explicit delete operation
- it will be possible to associate different deletion semantics with different relationships, by setting the "policy bits" on Item-Refs
- once you delete an item it is gone forever

Strings

strings
- Unicode everywhere at the user level, not ascii
- symbols -- used for python mapping -- ASCII strings with no spaces, etc.
- Polyglot strings, most likely -- (dictionaries of translations, keyed by language)
- any string, possibly -- (an attribute of type any string could have a value that was a unicode string, or a polyglot string, or a rich text string
- more complex types of strings are allowed (all can be represented by ascii), but captured at a higher level (building blocks is unaware of them)
- rich text strings should be represented in some platform independent way, rather than storing the different platform-specific rich text strings that one encounters on Linux and Windows and Mac

Schema Items

attribute definitions
- we will represent attribute definitions as Items
- for example, there will be a "Start Time" Item, of Kind "Attribute Definition"
kinds
- we will represent kinds as Items
- for example, there will be a "Contact" Item, of Kind "Kind"
types
- We will try and represent each Type as an Item
- for example, there will be an "Int" Item, of Kind "Type"
- 3rd parties being able to define their own types is a possible later feature, will not be addressed out of the gate.

Basic Data Types

Can parcel developers define new Literals?
- maybe

RDF

The Chandler data model differs from the RDF model.
We do not aim to be a general triple store, capable of storing arbitrary RDF
We will not be able to import arbitrary RDF -- only RDF that we have exported
We can easily write some code to export data from a Chandler repository to some kind of RDF document, as long as we get to pick our own RDF representation. We want to be able to export to some sort of RDF, but it can be a general Chandler-centric RDF, not an RDF designed for interoperation with other apps in specific application domains.
We haven't yet identified other specific ways that we might want to interoperate with RDF, and we don't know how well-suited the Chandler data model will be for interoperating with RDF tools.
Chandler application level parcels may want to have their own RDF import/export tools, to express their data in a particular rdf schema (calendar, foaf, dublin core)

UUIDS

(see also: DataModelIssues#Unique_IDs)

UUIDS
- UUIDs will be randomly generated 128-bit values
- different types of datastores will not each assign their own flavor of UUID
- the UUID will not be a tuple that includes (or encodes) the "home repository" of an item
- the client be able to assign its own UUIDs, without having to request them from the server?
- the kind item for "Contact" will have the same UUID in every repository

Annotations

Foreign Items

foreign items
- we will definitely want to have local copies of items from foriegn data sources (like IMAP mail), in order to handle indexing and querying from within Chandler, and in order to work when off-line
- we will definitely want to have local copies of items from other Chandler repositories, for example when a user has subscribed to something from somebody else's repository
- resolutions:
  - this problem will probably end up belonging to whoever is doing replication -- we're going to leave it be for now

Enums

there are a couple different options for providing enum support
we resolved:
- the "Building Blocks Layer" should have support for "symbols"
- the mechanisms in the "Building Blocks Layer" will probably be sufficient to support whatever type of enum representation we used in the "General Schema Layer"

Namespaces

(see also: DataModelIssues#Namespaces)

Do we want the repository to have some notion of namespaces, or are namespaces something that should be handled by semantic dictionaries?

namespaces
- we might not need namespaces, because items can always be refered to by UUID rather than by name
- resolution: left this as an open issue for now

Derivation Rules

Can we live with not having derivation rules associated with individual attributes of individual items, and instead just have derivation rules associated with attribute definitions at the class level?
Can we say that derived values always calculated by the client?
Can we say that derived values are stored in the repository?

Repositories

Display Strings

Transactions

Permissions

authorization and permissions
- once we hire a security person then we'll take direction from them about how our overall authorization system should be designed
- in any case, authorization needs to be enforced on the server side -- code on the client never even gets to see any items or attributes that the user doesn't have permission to see
- therefore, the database will need to know about the permissions schema in order to enforce the permissions
- authorization might be handled using "capabilities" or "ACLs"
- resolved: come back to this once we have a security person

Parcels

Notifications

Sharing

Files

Schema Changes

background
- parcel programmers may make changes to the schema, but the changes will be carefully planned, and the new parcel code will be written so that it (a) can do data conversion on existing items, and (b) can deal with running into old-format data
- end users will also change the schema information, by doing things like adding attributes to a kind, or deleting attributes, or changing the names of attributes. Those changes will impact items that already exist. But end users won't write data conversion routines, so Chandler will have to deal gracefully with that.
- in both types of use case, there will be some thorny issues. once we have a data model design that describes what schemas look like, then we need to cycle back and think about what types of changes we will allow people to make to their schemas, and what we need to do to support those schema changes.

merging items
- can you take two items that different UUIDs and merge them so that you end up with only a single item?
- might be desirable from a user's point of view, but implementing this in a general way would be hard

schema editing
- can a user edit the Chandler PIM schema?
  - example: Joe adds a new "hair color" attribute definition to the "Contact" kind
  - resolution: NO, all the PIM Schema instances are read-only -- more generally, any schema instance should be read-only if there's ever python code written against it
- can a user create their own sub-kind of "Contact" and add attributes to that?
  - creates lots of complexity when users start sharing items that come from schemas that were originally related but have been forked

Contributors

BrianDouglasSkinner - 10 Jun 2003

Discussion

(none yet)

chandlerproject.org

VISION
TOUR

Download Desktop
Get a Hub Account
Get Chandler Server

FAQ
Get Started

Blog
Mailing Lists
Chat on IRC

Report a Bug
Get Involved

OSAF Community
About OSAF

Jungle Wiki Changes

Open Source Applications Foundation

Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.