Table of Content

Some thoughts about the design in general

Comparison with existing solutions

All the solutions examined in competition use reflection, which we don't have here. We therefore have to build a solution which builds a static proxy, but allows further modification by the user. Ideally the generation of proxies could be part of the build process, to ensure they're always up to date.

Cayenne works in a similar mode: it generates a set of base classes, with overridable getters and setters. I think I could do something similar.

Different types of association

The cardinal of a predicate can be 1 or more. A univalued predicate has to be mapped to a value, while a multivalued one should be mapped to a set. Yeah, that's sorta obvious :/

Description of the mapping

From a high level point of view

  • State that a rdfs:Class has to be mapped
  • Describe the relation between class members and rdf:Property.
  • Mapping is "transitive": if class A is mapped, and has a a predicate which points to some type B, B has to be mapped too.

From a technical point of view

Mapping could be serialized to either XML or JSON.

Hypothetical example in JSON:

    class: "MusicPiece";
    maps: "nmm:MusicPiece";
    properties: [ { name:"title";  maps:"nie:title"; } ,
                  { name:"artist"; maps:"nmm:performer"; } ];

Created: 6 years 29 days ago
by Adrien Bustany

Updated: 6 years 29 days ago
by Adrien Bustany

Old Revisions