Open cgueret opened 7 years ago
While a single step via
rule could work for some cases, there are others where we may have to cope with arbitrarily long chains. For example:
:Work ex:hasEditions :Editions .
:Editions ex:hasEdition :Edition .
:Edition ex:hasCover :Cover .
:Cover ex:mediaObject :Media .
:Media ex:hasFormat <http://foo.bar/image.jpg> .
:Media ex:hasFormat <http://foo.bar/image.png> .
What is the target RDF we want from this? Perhaps:
:MediaProxy foaf:topic :WorkProxy .
:MediaProxy mrss:content <http://foo.bar/image.jpg> .
:MediaProxy mrss:content <http://foo.bar/image.png> .
(this would enable someone searching for the work with media=image to get all of the images relating to all of its editions)
NB Deciding what the proxy RDF should look like is also part of the problem, as we have to make a judgement about the data we eventually want in the RES index. Should someone be able to get all the cover images via the work? Because a work is considered a top-level interesting kind of thing by Acropolis, presumably the work should be the thing which gets the mrss:content
statement. Or should a user have to drill down through the editions collection, to an individual edition, then to the cover for that edition, then to the abstract media relating to that cover, and finally to embeddable files for that media? This seems a lot of work to get a book cover, so directly relating the work to its embeddable media seems more useful.
So how do we describe the chain between :MediaProxy
and :WorkProxy
using spindle:via
rules? In this case, I think we need a structure which allows an arbitrarily-long, ordered series of steps between resources.
Do we need to consider rules which use spindle:via
to point to an ordered list of transitions between resources via specific properties? (Though this has its own problems, as the rules may become domain-specific very quickly.)
From a mail conversation:
Implementing this will make it possible to process data modelled with EDM