Hi Asger Thanks for your comments on this
> As far as I can see, you actually assume that the triple store is only a > cache, but you do require that it exist. "Triple store is only a cache" > means somewhat the same as "every triple in the triplestore should be > expressed in one of the objects" Yes, I think you are right here that the triple store is a cache (no direct writes allowed). In terms of requiring it to exist, I can see a scenario where RI is not enabled, the REST API functions as it should, and a new "unified relationships" API method could still work providing the correct "resolution" mechanism was in place to relate a triple pattern back to the "owning" object. >> >> Essentially some kind of hierarchy of graphs and views, for example (please >> ignore the actual model/graph identifiers used below, I've not thought those >> through... this is just for conceptual illustration!). (and note that these >> are not Fedora resource identifiers - they are identifiers for graphs and >> sub-graphs describing Fedora resources, with triples containing URIs that >> resolve to Fedora resources.) >> >> <snip/> >> > And you have thus beautifully solved an old Fedora problem! I think this could work - but the impact on performance would need some investigation. >> >> Mapping between Fedora objects and the resource index >> ===================================================== >> >> <snip/> >> >> For instance the base content model that every object belongs to could >> specify: >> - an XSLT for generating the "system" triples for Fedora object and >> datastream properties, relationships between objects, datastreams and >> disseminators; and which graph the triples should be added to >> - an XSLT for generating triples from RELS-EXT; and which graph the triples >> should be added to >> - an XSLT for generating triples from RELS-INT; and which graph the triples >> should be added to >> >> <snip/> >> > I was actually thinking that this could be expressed as disseminators. > Then the content model would only have to express which disseminator to > call. That could be one way I guess, specifying a disseminator which transforms to RDF, and then index the results >> This needs thinking about more, for instance if an arbitrary triple is to be >> added, what object should it be stored in (that is a triple that does not >> make an assertion about a Fedora object or datastream for example)? Should >> it be possible to add a triple(s) that assert a new datastream or Fedora >> object? (ie having a completely RDF-centric API). > I feel a useful distinction could be statements to create new graphs, > and statements to add triples to a graph. Graphs should only be created > through the "traditional" API, as they create new objects and > datastreams. I think I agree here... though I can see a situation where adding/asserting a new triple that states an object exists results in its creation (and creation of the other triples it implies)... 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
