Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

developer-workflow.mdwn

Developer Workflow

I haven’t studied the situation in depth, and I probably never will because I don’t work in the industry, but I feel one of the reasons the flexibility and extensibility of semantic databases is not applied everywhere is because people don’t know what they are, how to use them and why. In order to make it easier for me and for others to use, I decided to design a workflow template to follow when designing an application of Razom.

Relational databases have a common workflow already:

1. Create an Entity-Relation diagram of the information
2. Design a relational database schema according to the diagram
3. Write a DDL document
4. Execute it to launch the database
5. Write wrapper API for queries if needed
6. Write application which uses queries or wrappers for data manipulation

But semantic databases have none. All you have is workshops, and if semantic information system engineering is not your job, you probably cannot attend them. Then all you have is the documents online, and unfortunately it’s not much. Here is a suggested skeleton for a workflow:

1. Create an Entity-Relation diagram of the information
2. Design an ontology or extend an existing one
3. Launch a new database and possible pass it the ontology for inference
4. Write wrapper API for queries if needed
5. Write application which uses queries or wrappers for data manipulation

It looks almost obvious, but it’s an illusion: All the complexity is hidden inside step 2. People know how to design a database schema: Choosing primary keys, normalizing tables, defining constraints, choosing data types and so on. Ontologies are very different, but they also have their own difficulties and require good practice guidelines just like SQL databases do.

Here are some suggested guidelines:

• Don’t add classes to abstract composite attributes
• Use classes for traits which describe the nature of the object, otherwise use a boolean property
• Use is-a to describe general type, but specific properties otherwise
• Avoid encoding meta-information in valus as much as possible
• Use meaningless identifiers (UUIDs are a good choice)
• Stop abstracting when you can’t explain the characteristics of the abstraction
• Trust the flexibility of the system to grow in a backward-compatible way
• Determine the cardinality and attributes of properties (function, transitive, etc.)
• Be bold, try new things, suggest improvements! All models are wrong anyway
• Work with a distributed architecture by spreading the data to several small databases, not a single huge one
• Prefer to extend or revise an ontology, even if it’s in wide use and development, to creating duplication
• Try to convert class/property equivalence into merging then into one (i.e. replacing one completely with the other)
• Don’t think about algorithms and inference when designing the data model
• Simulate arbitrary-arity relations using binding objects with a property for each component
• Use the standard way to describe linked lists, sequences and enumerated sets