Hi Chris

Thanks for your feedback on this.

> > Mapping between Fedora objects and the resource index
> > =====================================================
> > Currently the specification of what triples get created for 
> Fedora objects,
> > datastreams and properties is embodied in imperative Java code.
> > [...]
> 
> This could get hairy, but I like the idea of going declarative where
> possible, because it means easier extensibility.  Maybe using the
> disseminator pattern could make this more "pluggable" as Asger pointed
> out, but I'm not seeing an obvious way yet.
> 

Yes, this does need some more thought.

If it were truly declarative it should be able to cope with to-triple
mappings for
(1) object properties
(2) datastream properties
(3) "built-in" datastreams such as DC, RELS-EXT, RELS-INT
(4) arbitrary RDF datastreams
(5) arbitrary XML datastreams to be "lifted" to triples
(6) disseminators generating RDF

Asger's suggestion on disseminators is effectively (6) providing a mechanism
to implement (5) - the disseminator would be an XSLT transforming the XML
into RDF.  However an XSLT approach, although simple to implement, is
somewhat arbitrary and one-way; what would be good would be to utilise some
kind of standard XML-triples-XML mapping syntax/language...  

Implementing some "system" disseminators (in the base content model) - and
populating the RI from these - could cover cases (1), (2) and (3), so feels
like a nice approach.  I guess it would be a case of "marking" the
disseminator as resource-index-able.  Then user content model disseminators
would implement (4), (5) and (6), similarly marking the disseminators as
resource-index-able.

And using this disseminator approach means that we could first go for a
basic XSLT XML-to-triples mapping and then later implement various other
XML-to-triples mapping approaches.

On (6) there could be dependency issues, particularly for external content -
Fedora would have no knowledge when external content had changed, and
therefore the resource index needed updating.  I guess this could be a
candidate for utilising Mulgara's resolver architecture (though this could
be a performance nightmare - dynamically generating triples for every RI
query; I can see a case for building in some caching mechanism along the
lines of HTTP's cache control and Last-Modified header).

Steve


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers

Reply via email to