Ticket #2209 (new enhancement) — at Version 7
Object->RDF mapping
| Reported by: | ross | Owned by: | ross |
|---|---|---|---|
| Priority: | awaiting triage | Milestone: | ckan-sprint-2012-03-19 |
| Component: | ckan | Keywords: | [?d][a:2.0d] |
| Cc: | Repository: | ckan | |
| Theme: | none |
Description (last modified by ross) (diff)
Super is [1649]
We need to provide customisable mappings between CKAN models and RDF. This needs to be easily configurable for different clients and should take into account objects related to the model being mapped.
Current contenders for impl are:
- ordf.org's Object Description Mapper (which uses OWL)
- RDFAlchemy, although this looks like it may result in fixed mappings
- A custom scheme with a simple json file
- A template based approach using Genshi templates?
Approach is to get a mapping complete of the attributes directly in the package class, and then provide mappings for related objects (tags/resources etc).
We'll then need to be able to publish the RDF to a triplestore.
See http://ckan.okfnpad.org/rdfmapping for further analysis.
Change History
comment:3 Changed 2 years ago by ross
Option 4 is the most appealing at this point, although you probably should look at #2209
comment:4 Changed 2 years ago by ross
Previous comment should read:
Option 4 is the most appealing at this point, although you probably should look at #1649
comment:5 Changed 2 years ago by ross
Current thinking is that option 4 is a default (as per ckanext-rdf) rdf output that is generated not in code (as currently) but using a genshi xml template to read the package into an RDF format (as if it were HTML). This would then be overrideable so that for ecportal where the format of the RDF is different (change of vocabs etc) we can just point the config to a new template.
Pros:
Easy to implement Easy to use Not hard-coded as currently Fast execution
Cons:
Requires knowledge of required RDF output if default is not useful RDF and not any of the other formats yet. Only works with package/resource/tags unless more work is done
comment:6 Changed 2 years ago by ross
Can't edit comments .. so
Current thinking is that option 4 is a default (as per ckanext-rdf) rdf output that is generated not in code (as currently) but using a genshi xml template to read the package into an RDF format (as if it were HTML). This would then be overrideable so that for ecportal where the format of the RDF is different (change of vocabs etc) we can just point the config to a new template.
Pros:
Easy to implement
Easy to use
Not hard-coded as currently
Fast execution
Cons:
Requires knowledge of required RDF output if default is not useful RDF and not any of the other formats yet. Only works with package/resource/tags unless more work is done
