Hello Jérôme,

[...]
> Now I am wondering why you need the AB output format? It this the output
> format (linked to some custom template, etc) that you expect to be used
> on the cached collection page?

This AB is for authority records.  We are migrating a medium-size
catalog (over 65,000 bibliographic records) and about a thousand
authority and thesauri records from a classical ILS to Invenio.  Those
records have the typical «see» and «see also» entries, and almost none
of htem have a title.  For example, a typical entry would be:

 000065982 001__ 65982
 000065982 008 __010507 ||acznnaabn          |a aaa     d
 000065982 100 1_ $a Coma i Ferrer, Joan M. $c (Pseudònim de Josep Faulí)
 000065982 500 1_ $a Faulí, Josep, $d 1932-2006
 000065982 970 __ $a tracesaut-557
 000065982 980 __ $a TRACESAUT

And the HTML display will be something like that (with links and such):
 
  Coma i Ferrer, Joan M. (Pseudònim de Josep Faulí)
       See also: Faulí, Josep, 1932-2006

Not having a title makes the HB template weird.  So I created the
Authorities brief and detailed templates, and linked the output formats
to the authority and thesauri collections.  Moreover, there are some
conflicts between the meaning of the same tag in a bibliographic record
or in an autority one, ex:

 http://www.loc.gov/marc/bibliographic/bd500.html
 http://www.loc.gov/marc/authority/ad500.html

unless I try to find a combination of indicators that match one case but
not the other.

Yes, we know that, strictly, there cannot be authority records as such
in Invenio, but some of the functionality, like links from the «wrong»
entry to the accepted one, or the «see also» ones can be simulated.  And
although we have taken a quick look at the bibclassify module, we have
the preliminary feeling that, at least now, it is not what we need.

> If so, then as you guessed:
>
>> And, am I wrong or it is just hardcoded this way?
>>  
>> http://cdsware.cern.ch/repo/?p=cds-invenio.git;a=blob;f=modules/websearch/lib/websearch_webcoll.py#l417)
>>
>>     def create_latest_additions_info(self, rg=CFG_WEBSEARCH_INSTANT_BROWSE, 
>> ln=CFG_SITE_LANG):
>>     [...]
>>             for idx in range(total-1, total-to_display-1, -1):
>>                 recid = recIDs[idx]
>>                 self.latest_additions_info.append({'id': recid,
>>                                                    'format': 
>> format_record(recid, "hb", ln=ln),
>>                                                    'date':
>> get_creation_date(recid, fmt="%Y-%m-%d<br />%H:%i")}) 
>
> HB output format is hardcoded to be used in search results list AND
> cached collection pages (HD is hardcoded to be used on /record/xxx
> pages, HS hardcoded to be used on /record/xxx/usage pages, etc.). See
> output formats as generic entry points for some particular type of
> outputs. Then adapt the formatting by linking different types of format
> templates to the output format.
> Do not consider this hardcoded stuff as a limitation of the system:
> after all, there must be an entry point, and you have all the power
> at the level of the output format rules to route to various formattings.

Ok, I understand the reasining behind it.

> Then why would one need to add new output formats, since they are
> hardcoded? Well, they are primarily used to offer alternative outputs
> to the data, such as BibTeX, EndNote, etc (such as proposed through the
> "output format" menu on search results pages and "Export as .." links on
> detailed pages). All output formats except a few core one (XM, HD, HB,
> XR, HS) can be considered as optional, and are not so tied into the
> system.

As you have seen the records I'm working with now are just different,
for good or evil.

>> So should I do some temporary hacks like you do?
>> http://cdsware.cern.ch/repo/?p=cds-invenio.git;a=blob;f=modules/websearch/lib/websearch_webcoll.py#l397
>
> No, unless you want some collections to use AB output format for the
> cached page, and some others to use HB. But even in this scenario you
> should be ok by simply merging AB into HB (there are complex cases where
> this would not be true. Are you in this situation?).

I'm afraid I am.  I was trying to simplify my scenario creating two
independenent templates and output formats.  As I wrote before, maybe I
could merge AB with HB and AD with HD, but we are still playing with the
desired display and funcionality, and I feel it is easier not to add
extra complexity to the HB and HD templates.

Summing up, we have something that works *except* the first cached
page.  So I may have to change the hardcoded 'hb' in line 397 according
to the self.name collection name (out of the loop, that is).

That said, this authority template and format is easier than the next
one we'd like to have for our DDD ;-).  And, as a matter of fact, I was
thinking on both when working on this first one.  We are scanning
several thousands political posters, where the document *is* the image.
Instead of (or besides) having the thumbnail next to the brief
bibliographic record, we like a presentation more gallery-like, such as
this:

 http://pares.mcu.es/cartelesGC/AdminControlServlet?COP=6

In that case, the brief records page would not be a list but a table,
and probably with no text, except maybe the 'title' attribute of the
'img' tag (as we do already, ex: http://ddd.uab.cat/record/27477) .  I
haven't looked very hard at it but, as we are talking about atypical
templates and formats, I thought you may be interested.  Are we dreaming
too much?  Do you have any suggestion or future plans?

Thanks again,

Ferran

Reply via email to