Ticket #489 (closed story: fixed)

Opened 4 years ago

Last modified 3 years ago

Notify RDF service of model events

Reported by: johnbywater Owned by: wwaites
Priority: awaiting triage Milestone:
Component: ckan Keywords:
Cc: Repository:
Theme:

Description


Change History

comment:1 Changed 3 years ago by thejimmyg

  • Owner set to wwaites
  • Priority set to awaiting triage
  • Component set to ckan

Which RDF service? Why does it need model events? Will, any ideas or shall I close it? Thanks.

comment:2 Changed 3 years ago by wwaites

  • Status changed from new to closed
  • Resolution set to fixed

We still do need something like this. Right now the rdf generation is a cron job that crawls the API. Really we want two things:

  • only generate RDF for those packages that have changed
  • enable multiple client/worker processes, potentially run by third parties, to generate different parts of the RDF description.

For example, it is reasonable that we generate the DCat representation ourselves, however the voiD authors (DCat is generic, voiD is about RDF datasets in particular) want to generate the voiD-specific annotations themselves and contribute it back to augment the catalogue.

Another example: group curators may also want to annotate packages in their group with group-specific metadata.

Yet another example: checks on the coherence, availability, quality, openness, etc. of a package should be done from time to time or when a package changes, which can result in further annotations (see the curate tool).

Because of the "third party" aspect we cannot do this with the internal package representation and the rabbit queue. Most likely it is feasible to do this by looking at the revisions in the API to get all changes since the last time a script was run in which case most likely the answer is, yes, there is nothing to do here and the ticket can be closed.

Note: See TracTickets for help on using tickets.