How would you simulate a shared Schema.org repository

Question

I am looking for the best way to simulate an application around the entire schema.org file. The Schema.org hierarchy now contains about 500 different types that can be used to mark up microdata on the website: http://schema.org/docs/full.html

The goal is to create a common system around all of these Things without modeling more than 500 different tables using default SQL databases.

As an initial example, JobPosting seems like a pretty simple model, as it has only a few fields and only two links to organization objects and places: see http://schema.org/JobPosting

What database system (SQL, MongoDB, Cassandra, neo4J, Sesame, ...) would suggest to model such data? There are even some special Graph or RDF databases that may be another option.

Bonus question: Another problem that is causing my mind at the moment is the multiple inheritance on which some objects are based, for example. http://schema.org/Dentist is a LocalBusiness Organization, but also a Place, so it has fields from several different parents.

So, I am looking for a System with:

• Variable columns as I don't want to model these zillion attributes using SQL-DDL
• Multiple inheritance or something like that (Mixins)
• Useful link betweens Records (e.g. JobPosting points to the organization and the place it belongs to)
• Simple queries (for example, getting all JobPosting for a given organization)

Please let me know what information will help me find the best answer.

Answer 1

I think MongoDB might be good, because its docs make it easier to represent individual schemas. (solves the variable column problem).

To solve the linking problem, it makes sense to store only links. For example, in JobPosting, you probably want to keep OrganizationId and PlaceId , because these are pretty complex documents. It also makes calling a specific JobPostings organization trivial.

Note Sometimes an implementation may be more appropriate, but it depends a lot on the way your documents are updated. In particular, many objects can refer to the same address, so a change in address should be reflected everywhere. Sometimes the opposite is true. This is a key question that can only be answered by you. It depends on how the system is used.

In any case, linking means that one search can cross the link tree. Again, this is highly dependent on the use case:

Suppose you want to display JobPosting. Now you can display a list of properties, and for Organization, all you type is ACME, Inc. citing. This link will send you to the ACME, Inc. details page. In this case, your queries are very simple. The only thing you need to do is copy the organization name into JobPosting (de-normalization), so it’s easier to display.

If, on the other hand, you want to display everything in place, you will have to perform more queries and build the domain model object in code. This does not really matter, but requires extra care in the case of circular links, etc.

I guess the best approach is to use the corresponding most specific type as the name of the collection (so ContactPoint falls into the ContactPoint collection, PostalAddress in the PostalAddress collection, etc.).

The only remaining problem is multiple inheritance or mixins. I have not used ruby ​​before, but I think the mongodb ruby ​​driver supports mixins.

You still have to cope with indexing, etc., but again, it depends a lot on the use cases. You probably want to index most foreign keys, but additional indexes need manual maintenance.