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, <ajs6f@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.tuohy@versi.edu.au> wrote:
On 14/10/11 07:38, ajs6f@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
jonathan@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-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers