On 17/10/11 11: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. In what way hard? Can you expand a little on the difficulties you see?
>> While I think XSLTs have a place in transforming metadata, there needs to be >> something more. One issue to keep to in mind here is the 80/20 rule. If Fedora's indexing system is complex enough to allow for all manner of complex cases, then it may be needlessly complex for many simple cases. A more complex system would make complex indexing easier, but if it also makes simpler cases harder (even just harder to understand a configuration system), then the OVERALL ease-of-use might actually decrease. I don't think it's possible to strike a perfect balance, but a technology like XSLT might be a useful catch-all: it can handle simple cases very simply, but can also be extended arbitrarily (including, for instance, transcluding metadata from related Fedora objects or other XML datasources). In very many cases, the mapping of Fedora objects to Solr documents is very simple and won't, for instance, involve any aggregation. But the mapping from Fedora objects to Solr documents is in principle arbitrary; you might choose to do pretty much anything, quite legitimately. You might have metadata schemas of any type; you might use the RDF store, you might have external authority files, etc. This is where, I think, a system which is sufficiently configurable to be fully general could well end up as complex as an XSLT-based system would be, but without many of the advantages of XSLT (code libraries, books and mail-lists, programmer experience, etc). It might be enough to ship Fedora with a basic set of XSLT transforms, and a few sample transforms showing how to use the resource index, etc. -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
