Ticket #2209 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

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:

  1. ordf.org's Object Description Mapper (which uses OWL)
  1. RDFAlchemy, although this looks like it may result in fixed mappings
  1. A custom scheme with a simple json file
  1. 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:1 Changed 2 years ago by ross

  • Description modified (diff)

comment:2 Changed 2 years ago by ross

  • Description modified (diff)

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

comment:7 Changed 2 years ago by ross

  • Description modified (diff)

comment:8 Changed 2 years ago by ross

  • Keywords [?d][a:1.5d][r:0.5d] added; [?d] removed

comment:9 Changed 2 years ago by ross

  • Keywords [?d][a:2.0d] added; [?d][a:1.5d][r:0.5d] removed
  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.