jonassmedegaard
commented
2 years ago I think it makes sense
I think it makes sense to distinguish between...:
- mapping to AD from non-AD RDF data
- mapping to AD from non-RDF semantic data (e.g. GraphQL or vfile or exif or LDIF)
- mapping to AD from structured-but-non-semantic data (e.g. CSV or SQL)
- mapping to AD from unstructured data to AD
- mapping from AD to any of the above
- bi-directional mapping between AD and any of the above
While 6) is cool, it is also the most complex to tackle, and also arguably the least important to have tightly integrated with Atomic Data: Projects like Cambria as a stand-alone tool can instead be extended to have AD as one of its supported transformation formats.
How easy it is to convert data to atomic data and vice versa is one of the most important metrics for us to optimise. Users should be able to effortlessly create, maintain and use these mappings to make data conversions.
But how? One solution is to write conversion tools for specific domains, such as Bookmarks, Contacts or Calendar items (see #89). Another is to build a bunch of libraries to facilitate this process. Another is to make publishing data easier, and let the data creators make the mappings #93.
Another way, is to allow users to describe mappings in a declarative language / DSL.
One interesting project that does this is Cambria. It introduces bidirectional lenses that describe data transformations between schemas. A core part of the propisition is to deal with schema changes, and let developers map their model to multiple API versions. (Thanks to @cole for mentioning this)
to be continued
Edit: the JSON-AD publishing protocol #93 takes care of most of this issue. No complex DSL stuff needed if a data source simply maps their concept to AD Properties