Certainly, Gert. I'll package up some objects (since by the nature of the problem, any example must consist of at least several objects) and send them to you.
I agree that FCREPO-1009 may well help provide an answer on the query side, but it's not clear to me how it will help on the indexing side, or how folks who use Solr, with its particular query language (or for that matter, Zebra) will be able to accomplish something similar. --- A. Soroka Online Library Environment the University of Virginia Library On Oct 17, 2011, at 3:31 AM, Gert Schmeltz Pedersen wrote: > I think that the needs you both describe here are very relevant. I think that > the issue https://jira.duraspace.org/browse/FCREPO-1009 "Interaction with the > Resource Index" may very well be an answer, because it has the power to > combine the strengths of the bibliographical query language of Lucene/Solr > and the triple languages of Mulgara. I am not ready to explain it in more > detail now than given in the issue description, but in the meantime I would > very much like to see some example test objects relevant to these needs. Can > you provide such examples? > > Gert > > > On 17/10/2011, at 02.48, <aj...@virginia.edu> wrote: > >> Heartily seconded! >> >> In the architecture we're exploring at UVa, we use RELS-INT to define >> relationships between datastreams and indexing transforms. The relevance to >> this issue lies in RELS-EXT. By indexing RELS-EXT as a datastream (and >> assuming that the molecular "para-object" that is responsible for a given >> index record is constructed via RELS-EXT relationships) we can obtain >> information about the other objects that may be involved in any index record >> to which a given object is associated. I'm in agreement that keeping the >> analysis of object relationships for indexing purposes in indexing XSLT is >> _not_ the best way, and instead we look to combine this technique with the >> use of Enhanced Content Model Views to create the kind of multiobject >> records to which Jonathan is pointing by hiding the explicit structure of >> the "para-object" from the indexing XSLT. This may or may not be the best >> possible solution for the problem, so I'm just offering it as a place to >> begin discussion. >> >> >> --- >> A. Soroka >> Online Library Environment >> the University of Virginia Library >> >> >> >> >> On Oct 16, 2011, at 8:15 PM, Jonathan Green wrote: >> >>> Something that I think needs to be considered when moving forward with >>> gsearch is that the index may not always share a 1 to 1 relationship with >>> objects in fedora. In a very atomistic content model perhaps the solr >>> document is actually composed of parts from many related objects. These >>> types of decisions are currently very hard to make in XSLTs. While I think >>> XSLTs have a place in transforming metadata, there needs to be something >>> more. >>> >>> On Thu, Oct 13, 2011 at 8:10 PM, Conal Tuohy <conal.tu...@versi.edu.au> >>> wrote: >>> On 14/10/11 07:38, aj...@virginia.edu wrote: >>>> I can't but point out that a very popular and well-supported XML language >>>> for describing mappings from XML metadata to the Solr (XML) document >>>> format already exists: XSLT. >>> Absolutely! In my opinion XSLT is an ideal language for crosswalks: >>> >>> 1) it's very widely known and used (far more so than any "custom" >>> mapping XML rules would be) >>> 2) in particular it's already used in other parts of both Fedora and Solr >>> 3) simple mapping rules can be expressed very concisely >>> 4) since it's a Turing-complete programming language, mappings of >>> arbitrary complexity are also possible (even involving transclusion of >>> external resources) >>> >>> In a project I've been working on this year at La Trobe University, we >>> have used XSLT to perform a crosswalk from FOXML to Solr's update >>> schema: >>> http://code.google.com/p/ands-la-trobe/source/browse/trunk/xslt/foxml-to-solr.xsl >>> >>> The above XSLT is called by an XProc pipeline invoked by a JMS listener >>> on notification of a change to a Fedora object. >>> >>> Con >>> >>> -- >>> Conal Tuohy >>> eResearch Business Analyst >>> Victorian eResearch Strategic Initiative >>> +61-466324297 >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2d-oct >>> _______________________________________________ >>> Fedora-commons-users mailing list >>> Fedora-commons-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >>> >>> >>> >>> -- >>> Jonathan Green >>> DiscoveryGarden Inc. >>> Sims Office Suites Building, 3rd Floor, 118 Sydney Street >>> Charlottetown, PE C1A 1G4 >>> 902.367.3851 discoverygarden.ca >>> jonat...@discoverygarden.ca >>> skype: jonathan.edwards.green >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ >>> Fedora-commons-users mailing list >>> Fedora-commons-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> Fedora-commons-developers mailing list >> fedora-commons-develop...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ > Fedora-commons-developers mailing list > fedora-commons-develop...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
