As Scott wisely indicates, you're perhaps asking a question about how your physical data model is going to support your work. Fedora will happily record almost any relationship you want, but different patterns of recordation are going incur varying costs for different patterns of use.
I welcome correction on the following point, but I believe that the SPARQL endpoint supported by Mulgara (assuming you are using Mulgara) will support the querying of "forward" properties as "reverse" properties via entailment outside Fedora: http://docs.mulgara.org/inferencing/entailment.html That's _not_ something supported directly by Fedora Commons: you'd do best to talk to the Mulgara folks about whether it might be a useful tool for you. --- A. Soroka The University of Virginia Library On Apr 25, 2013, at 11:17 AM, Scott Prater wrote: > Graham, > > One of the more useful features of the resource index is that you can > put anything you want into it. Generally, the suggested practice has > been to reserve the RELS-EXT and RELS-INT datastreams for internal > Fedora housekeeping relations and put other, more content-related > relations into a separate datastream, and index that datastream in an > external triple store. However, in this case, the relations you propose > feel to me like useful additions to the standard Fedora object > relations, and do belong in RELS-EXT. > > Our own practice is to put two-way pointer relations into our RELS-EXT: > parents point to children, and children point to parents. The > disadvantage of this approach is that you end maintaining duplicate > relations; the advantage is that it enables you to easily identify > orphaned children or parents unaware that their children have gone > missing, and gives you multiple routes for walking a tree. > > We've also created our own RDF schema and namespace for our home-grown > relations. I can pass that along to you (or post it to the list), if > you're interested, as well as some sample RELS-EXT datastreams we've > created. > > Another potential problem is if you have a parent object with hundreds, > thousands, maybe even millions of direct descendants; the RDF list of > "hasMember" relations can get very unwieldy in that case, and > potentially cause performance problems. There's been some discussion of > that on the forums in the past, and with some of the changes in recent > versions of Fedora, there may be ways to ameliorate those problems > (using an external triple store, storing the RELS-EXT as a managed > datastream, etc.) I'll let others who have dealt with that issue > address it in more detail. > > -- Scott > > > On 04/25/2013 09:27 AM, Graham S Hukill wrote: >> Good morning all, >> >> Perhaps a simple question here, but something that has been throwing us >> for a loop. Is it possible to use inverse predicates for RDF queries? >> >> For example, in our relatively early stages of implementing Fedora >> Commons we have primarily used RDF relationships such as >> "isMemberOfCollection", "isMemberOf", and "hasContentModel". These have >> been incredibly powerful to work with, and served us well so far. But >> as we dig into developing front-ends for managing objects and discovery >> layers, we are interested in leveraging RDF queries as much as possible. >> Is it possible to use predicates such as, "hasMember" or >> "hasMemberOfCollection"? And if it is not baked into FC, is it possible >> to define these inverse relationships in such a way that we can query >> using them? It looks like in some of the Spring XACML configurations >> there are hints of this. >> >> I've also seen some chatter in RDF discussions about whether or not to >> include this kind of inverse predicate logic, vs. adding triples that >> explicitly state those relationships, but am not sure if FC provides >> this functionality. Plus, we have been meaning to start utilizing this >> listserv more, and this seemed like a good time to start; it has already >> been of immense help to us, thanks to everyone for making their >> questions and answers available to the community. >> >> >> -Graham >> >> >> Graham Hukill >> Digital Publishing Librarian >> Wayne State University Libraries >> 313.577.5951 >> [email protected] >> >> >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> >> >> >> _______________________________________________ >> Fedora-commons-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> > > > -- > Scott Prater > Shared Development Group > General Library System > University of Wisconsin - Madison > [email protected] > 5-5415 > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
