[rclis] [Fwd: [EP-underground] Ordering the subject table]

Antonella De Robbio rclis@lists.openlib.org
Tue, 12 Nov 2002 20:22:05 +0100


Questo è un messaggio multi-parte scritto in formato MIME.
--------------AAC027E44C33316F151BD5F7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit

Here is the correspondence between Chris and me.
The problems are different... for different aspects...
>From one side we have the browsable Subject tree oriented to users
(search function). On the other hand we have the depositable side
(registered area or user area for deposit). The depositable area is
heavy influenced by structure assigned to Subject tree.
Whereas the structure is based on only depositable one level, the
depositing user can see only the depositable level on the internal side.

Subjects which are children of main subjects appear to the user in the
pop-down list displayed in the  e-prints submission process only if are
children depositable.
This is a problem, because user cannot know or see the contents of the
sections.
A description field is missing.
The Subject tree displayed in the pop-down list  (submission area) is a
flat schema.

Please look the enclosed correspondence.

In this situation I have tried to insert in E-LIS the JITA schema in the
following way.
I have created a  "description" level (for each section) using a
depositable
child, in this way the descriptions are visible (dispayed)  in
submission process.
The Name field is limited to 255 characters, but I have managed it
anyway.
I have used only one field (Thomas hypothesis) for description where I
have put
all subtopics.
But the problem is that the visibility on the user area side is very
bad.
The long field goes out by the screen. I have limited (in the config
file) the
windows dimension (columns), but nothing.
It is not nice.
I am not satisfied of this solution, it is not elegant, but other better
does not come me in mind,
... for the moment...

Moreover the layout has to be better settled up... I am waiting for Imma
files.
Otherwise we can come back to previous version which was not to bad.
I undestand that layout is important, but we cannot lost a lot of time
for aestetic issue. We have to start.

Thank you for attention
Antonella




--------------AAC027E44C33316F151BD5F7
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <owner-eprints-underground@ecs.soton.ac.uk>
Received: from smtp7.cp.tin.it (192.168.70.234) by ims3b.cp.tin.it (6.5.028)
        id 3DCC79530002F6CA for derobbio@tin.it; Sat, 9 Nov 2002 19:32:32 +0100
Received: from raven.ecs.soton.ac.uk (152.78.70.1) by smtp7.cp.tin.it (6.5.029)
        id 3DC1FE5E00942757; Sat, 9 Nov 2002 19:32:32 +0100
Received: from seer.ecs.soton.ac.uk (seer.ecs.soton.ac.uk [152.78.68.160])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA13352;
	Sat, 9 Nov 2002 18:27:33 GMT
Received: (from majordomo@localhost)
	by seer.ecs.soton.ac.uk (8.12.3/8.12.3) id gA9IPvk0013092
	for eprints-underground-outgoing; Sat, 9 Nov 2002 18:25:57 GMT
Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131])
	by seer.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gA9IPuG1013089
	for <eprints-underground@ecs.soton.ac.uk>; Sat, 9 Nov 2002 18:25:56 GMT
Received: from lemur.ecs.soton.ac.uk (lemur [152.78.69.157])
	by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA09585
	for <eprints-underground@ecs.soton.ac.uk>; Sat, 9 Nov 2002 18:25:51 GMT
Received: (from cjg@localhost)
	by lemur.ecs.soton.ac.uk (8.11.6/8.11.6) id gA9JFRP14997
	for eprints-underground@ecs.soton.ac.uk; Sat, 9 Nov 2002 19:15:27 GMT
Date: Sat, 9 Nov 2002 19:15:27 +0000
From: ePrints Support <eprints-support@ecs.soton.ac.uk>
To: EPrints Underground List <eprints-underground@ecs.soton.ac.uk>
Subject: Re: [EP-underground] Ordering the subject table
Message-ID: <20021109191527.A14935@ecs.soton.ac.uk>
References: <3DC940E8.4030306@tin.it> <20021107120621.N10251@ecs.soton.ac.uk> <3DCCD90C.80305@tin.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DCCD90C.80305@tin.it>; from derobbio@tin.it on Sat, Nov 09, 2002 at 10:44:44 +0100
X-ECS-MailScanner: Found to be clean
Sender: owner-eprints-underground@ecs.soton.ac.uk
Precedence: bulk
Reply-To: EPrints Underground List <eprints-underground@ecs.soton.ac.uk>
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7Bit

i'll answer the easy bit first...

when eprints lists subjects to a user it shows ALL subjects which
are CANADD=TRUE.

when eprints lists subjects to a searcher it shows ALL subjects.
Do you want a "comment" feature of some kind? how would it work?

part 2:
phew. in theory this would wok in the config.

{ name=>"subjects", type=>"subject", top=>"subjects", multiple=>1,  
   browse_link => "subjects",
   make_single_value_orderkey=>sub {
	my( $field , $value ) = @_;
	return $value;
   }
}

which skips the whole working out of the subject title thing BUT
there is a little bug so you can either
(a) wait for me to fix it

or 

(b) add a tiny hack to make it work without the configuration option...
in perl_lib/EPrints/Metadata.pm find this bit
---
sub _ordervalue_aux1
{
        my( $self , $value , $session , $langid ) = @_;

        return "" unless( EPrints::Utils::is_set( $value ) );

        if( $self->is_type( "subject", "dataset", "set" ) )
        {
                my $label = $self->get_value_label( $session, $value );
                return EPrints::Utils::tree_to_utf8( $label );
        }
---

and change it to:

---
sub _ordervalue_aux1
{
        my( $self , $value , $session , $langid ) = @_;

        return "" unless( EPrints::Utils::is_set( $value ) );

        if( $self->is_type( "subject" )
        {
                return $value;
        }
        if( $self->is_type( "dataset", "set" ) )
        {
                my $label = $self->get_value_label( $session, $value );
                return EPrints::Utils::tree_to_utf8( $label );
        }
---

ok, it's not easy but it is possible. This just says that
On Sat, Nov 09, 2002 at 10:44:44 +0100, Antonella De Robbio (Casa) wrote:
> 
> Thank you Chris,
> 
> with a more careful analysis of the logical structure of the Eprints 
> database, I am able to formulate
> more exactly the problem.
> As the format of the import text file  is
> KEY:TITLE:PARENTS_KEY(S):CANADD?
> I want the browse by subject view to appear ordered by KEY and not by TITLE.
> Obviously I mean the order calculated on the whole content of the KEY 
> field in a standard manner,
> the issue is not on different ways of sorting one field, but simply on 
> sorting one field instead of another.
> 
> For example:
> 
>    Use and impact of information.
>    Bibliometric methods.
>    Information in society.
>    Information society.
>    Information economics.
>    Information policy.
>    Information dissemination and diffusion.
>    Information needs and information requirements analysis.
>    User interfaces, usability.
> 
> These are the TITLES of the children of the B section of our JITA 
> classification for LIS.
> To preserve the order decided by us, without being compelled to make 
> TITLEs begin with ad
> hoc alphanumerical strings, we could resort to the KEY field, which is 
> internal and not visible by user.
> We don't want to display such initial strings because this is a hinders 
> future enlargment of the
> schema and could be misleading for the user.
> These subjects are intended altogether to be an explanation of the 
> content of the B section an not as
> single depositable subjects.
> About this point we are interested to know whether not depositable 
> subjects which are children of depositable
> subjects appear to the user in the pop-down list displayed in the 
> e-prints submission process.
> If this is not the case, how can we do to make they visible to user?
> 
> Thank you for you support
> Antonella De Robbio
> E-LIS General Manager
> 
> 
> 
> 
> 
> ePrints Support wrote:
> 
> >Each field has a key which is used for ordering it.
> >
> >There is a default way of generating it for each field type.
> >
> >Subjects and sets, for example, use the id by default.
> >
> >You can change it to use the name with a short subroutine
> >linked from order_value in the metadata config (see the docs)
> >
> >There is not an (easy) way to make more than one way of sorting
> >one field. It would be possible, I'll explain if you *really*
> >want...
> >
> >On Wed, Nov 06, 2002 at 05:18:48 +0100, Antonella De Robbio (Casa) wrote:
> >
> >>Dear Chris,
> >>
> >>I am involved in different applications of the Eprints software.
> >>One is a test phase at the University of Padua (institutional 
> >>repository), the other one is working progress
> >>for a data provider on LIS e-papers within rclis service.
> >>In both applications we met with the same necessity of ordering the 
> >>subject table by TITLE and
> >>not by KEY, as is in the current implementation.
> >>Is it possible to have the option of ordering by KEY available with 
> >>config maneuvres?
> >>Or is it other way to obtain a not alphabetical order, but an order 
> >>provided by us.
> >>
> >>Thank you
> >>Antonella De Robbio
> >>E-LIS General Manager
> >>
> >
> 

-- 

 Christopher Gutteridge                   eprints-support@ecs.soton.ac.uk
 ePrints2 Coder, Support and Stuff        +44 23 8059 4833


--------------AAC027E44C33316F151BD5F7--