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<mailto: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<mailto:conal.tu...@versi.edu.au>> wrote:
On 14/10/11 07:38, aj...@virginia.edu<mailto: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<mailto: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<http://discoverygarden.ca>
jonat...@discoverygarden.ca<mailto: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<mailto: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-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
