[D7 port] Entities and fields for the D7 port

This entry will talk about the entity types and fields for Neologism in D7. It will also talk about how we plan to handle the duplicated database storage that arises from using both the Entity/Fields APIs and evoc.

Entity types

For Neologism D7, we'll need four entity types:

1. Project
2. Vocabulary
3. Class
4. Property

This is a bit different from D6, where we had only Vocabulary, Class and Property.

A Project is the top-level entity. A project has one or more users associated with it (the authors).

A Vocabulary is a collection of classes and properties that all share a single namespace. A vocabulary always belongs to one Project. A Project has one "main vocabulary". That main vocabulary contains the classes and properties that are actually being created and edited in the project. The other (non-main) vocabularies in the project are the external vocabularies that are being used in this particular project.

So, the handling of external vocabularies will be a bit different from how we did it in D6. In D6, external vocabularies were independent from the projects. Once an external vocabulary was loaded, it would be visible and usable in all projects. This is a problem, because on a large site with many users, you can have many projects that all want to use different external vocabularies. When each project can see all the external vocabularies loaded by all other users, it just gets too much. Therefore, in D7 we want an external vocabulary to be only part of a single project. This means, if two different projects both need FOAF as an external vocabulary, then they both have to load FOAF, and there will be two copies of FOAF in the database. The schema supports this -- the two copies will have the same namespace URI (http://xmlns.com/foaf/0.1/) and smae prefix (foaf), but different associated projects.

The remaining entity types are class and property. They are associated with a vocabulary. They basically work the same in D7 as in D6.

Nodes vs. custom entities

For now, we want all these four entity types to be Drupal node types. Later on, we probably want to keep only Project as Drupal nodes, and we want the other three types to be their own custom entity types. This is because they don't really behave like nodes. For example, they can't exist on their own, but always have to be part of a project. But as I said, let's worry about that later, and for now we'll just make them all nodes, and use node_references when we need to refer from one entity to another.

Database storage and evoc

In D6, we had the problem that we stored everything twice in the database: once in CCK fields, and a second time in the evoc database schema. This was a major source of complexity and bugs, and we definitely don't want to repeat this. We thought long and hard about the best way of avoiding this duplication in D7, and after some back and forth think that the following is the best way forward:

We will not use evoc at all. We will just use the Entity API and Fields API and the database schema that is automatically created for the entities and fields.

The only thing that we want to use from evoc is the code for importing vocabularies. It's best to just copy-paste that code into the Neologism project and remove the evoc dependency. This means that new code has to be written to *store* the loaded vocabulary into the entity/fields tables.

Fields

Some details about the fields we think we need for each entity type (cardinality in brackets):

project

• main_vocab: a node reference to vocabulary (1)
• authors: a user reference to the users associated with the project. Later, we want to add access control, so only these users can make any changes in the project. When a project is first created, then the user doing the creation is the initial value of this field. (1 or more)
• layout: the XML layout information stored by the diagram widget. A text field. (1)

vocabulary

• project: a node reference to project entity (1)
• prefix: the vocabulary prefix, such as foaf (1)
• uri: the vocabulary URI, such as http://xmlns.com/foaf/0.1/ (1)
• label: the title of the vocabulary ("The FOAF Vocabulary" or something like that) (1)
• description: the short description of the vocabulary (0-1)
• body: the full, long description (0-1)
• additional_rdf: additional triples in Turtle syntax (0-1)
• date_created: date when vocabulary was created/imported/loaded
• date_updated: last time when anything on that vocabulary was changed

class

• vocabulary: a node reference to the vocabulary (1)
• local_name: term ID, such as "Person" (1)
• label: the rdfs:label (1)
• comment: the rdfs:comment (0-1)
• body: the full, long description (0-1)
• superclasses: node references to superclasses (0 or more)
• disjoints: node references to disjoint classes (0 or more)

property

• vocabulary: same as for class
• local_name: same as for class
• label: same as for class
• comment: same as for class
• body: same as for class
• functional: boolean property: is this an owl:FunctionalProperty? (1)
• inverse_functional: boolean property: is this an owl:InverseFunctionalProperty? (1)
• superproperties: node references to superprops (0 or more)
• domains: node references to domain classes (0 or more)
• ranges: node references to range classes (0 or more)
• inverses: node references to inverse properties (0 or more)