Building Blocks with a JSON-LD context mapping to a model inherit the limitations of the target model.
Where a general model such as schema.org is used, such a mapping is highly semantically "lossy" because necessarily the target is looking to map many domain concepts to a particular use case, such as paid advertisement relevance, that does not have preserving critical domain semantics as a design goal.
For example consider schema.org "City" model - no notion of population, but has properties like:
Several options exist:
- decouple the schemas from the bindings, allowing multiple JSON-LD bindings to different, more high fidelity models.
- Test , demonstrate and promote an "override" mapping, showing how to override such default mappings to deliver high fidelity semantic mappings.
- Create a "lossless" semantic model matching the schema and use SPARQL transforms [1] to demonstrate how to derive lossy mappings such as schema.org from the high fidelity model.
- Explore desirability and potential of Building Blocks to generate multiple alternative JSON-LD bindings using different context source files.
@avillar to advise on status of option 2 ?
[1] https://ogcincubator.github.io/bblocks-docs/create/transforms
Building Blocks with a JSON-LD context mapping to a model inherit the limitations of the target model.
Where a general model such as schema.org is used, such a mapping is highly semantically "lossy" because necessarily the target is looking to map many domain concepts to a particular use case, such as paid advertisement relevance, that does not have preserving critical domain semantics as a design goal.
For example consider schema.org "City" model - no notion of population, but has properties like:
Several options exist:
@avillar to advise on status of option 2 ?
[1] https://ogcincubator.github.io/bblocks-docs/create/transforms