> > > > > We could, and should make default disseminators, that could provide > the > > > object as a RDF graph in alternative serializations. These are not > > > difficult to make, the code just needs to be done. > > > > Should it be all the per-object triples that go into the RI? That > is, > > the union of (RELS-EXT, RELS-INT, inferred triples from DC, inferred > > triples from the FOXML). > That would be my opinion, yes.
It would be good to be able to configure this to a degree. My main concern is triple store performance. Despite what you read on many web-sites about scaling to 100s of millions of triples, in practice I found this not to be necessarily that straight forward. We currently run Fedora / Mulgara with 30 million triples and query times are not very good, even for simple SPARQL queries. While I have been told that improvements for Mulgara are on the way I think it is still a good idea to be conservative when putting triples in the triple store. How about a filter mechanism where pre-defined or user-defined filter classes can be inserted in the triple storing workflow? Those classes could then decide whether to pass a triple to the store or whether to drop it. Carsten Friedrich Research Team Leader CSIRO ICT Centre M: +61 (0) 2 6216 7019 www.ict.csiro.au ------------------------------------------------------------------------------ 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
