No separate xslt, gsearch uses the same indexing xslt, whether triggered by an
ingest/update of the Fedora object, or by an updateIndex fromPid operation, or
by an updateIndex fromFoxmlFiles operation. If you get different indexing
documents in these three cases, then the way to find out why, is
Even indexing on the pid doesn't force it to index anything other than DC. I
checked the foxml file in the objectStore and the DCTERMS namespace
declarations are identical to the sample used to generate and successfully
index new documents from scratch. Seems it doesn't want to index when upload
Nup , not that. Even uploading the DCTERMS first it doesn't index them. Is
there a separate xslt it uses for updating a resource? The symptoms are
identical to when the main xslt was lacking the dcterms namespace.
Alistair
---
Alistair Young
Àrd Innleadair air Bathair-bog
UHI@Sa
I think the problem is down to the multi part commit technique being used when
uploading to Fedora:
1 – new object pid is generated by a POST
2 – the DC datastream is then PUT
3 - the DCTERMS datastream is then PUT
4 - the content datastream is then POST
so I suspect 3 (or 4) is not getting to s
I think I must be missing a file mod or something. Indexing from scratch, using
from foxml files works fine and dcterms in all resources are indexed as the
namespaces are in the xslt. When uploading a new resource to fedora it gets
indexed but only on dc, not dcterms. Does gsearch use a differen
Hi JJ,
You may want to take a look at:
http://sesame.library.yale.edu
and browse down the hierarchies under "Avaliable Materials"
>From the fedora end for the most part there is a hierearchy of title, volume,
>issue, and page expressed by RELS-EXT isMemberOf relationships in the childr
Hi Folks,
This may be a dumb question but I'm sure some of you must be doing Local
newspapers and perhaps you have some good ideas on how to set this up and some
warnings on pitfalls we might try to avoid.
At Queens we are using VITAL, the VTLS front-ended Fedora product. We are
digitizing so
Julie,
A Jisc project carried out by a student at our Scarborough campus last year
looked at this. It produced the CAPRI (CAmpus-based Publishing Repository
Integrator) add-on to OJS for adding publication artefacts to the repository.
Not so much Fedora powering the publication, maybe, as ens
