headers
Robby Stephenson | 1 May 07:44
Gravatar

Re: IMDB Import

On Wednesday 30 April 2008, Karolina wrote:
> onsdagen den 30 april 2008 skrev Robby Stephenson:
> > Hi Dagmar,
> >
> > On Tuesday 29 April 2008, Dagmar Seide wrote:
> > > There several categories missing with the import from IMDB: Cast,
> > > Original Title, Certification, Film Company, Color, Aspect Ratio,
> > > URL.
> > >
> > > Could you please fix this?. Many thanks.
> >
> > I just fixed the certification, studio, aspect ratio and color. The
> > alternative title and IMDB url link are options in the data source
> > setting.
> >
> > Thanks!
> > Robby
>
> If you have an old database with movies, how do you tell it to import one
> of the new tags, or are they automagically created when doing the next
> update?

Update Entry -> IMDb will update empty values with the new ones.

Robby
Permalink | Reply | 4 comments |
headers
Andrew Bennett | 1 May 07:56
Picon
Gravatar

Re: LoC query for older LCCNs

Hi Robby,

Sorry for not replying sooner.  I was away for a week then spent a lot of time... not catching up on things like this.

On Fri, Apr 11, 2008 at 11:38 AM, Robby Stephenson <robby-9lFPeden07UgsBAKwltoeQ@public.gmane.org> wrote:
> >Can you send me some valid LCCNs with the 0 padding? It'd be good to have
> > some test cases.

> 81-6044 kidder - soul of a new machine (LoC requires 81006044)

Oddly, LoC returns both the kidder book and an 1877 books called "Boletin de
la Real Academia de la Historia"

The 1877 result has the alphabetic prefix 'sf' (that one and more prefixes like that are listed at http://www.loc.gov/marc/lccn_structure.html).  I didn't fully understand the use of the prefixes, and none of my ~200 books with LCCNs contained prefixes, so the patch file I submitted, which wasn't built to handle prefixes (in either the entry field or the returned results) anyway, assumed that the existence of a prefix was proof that the result did not match the query.

My understanding is that "sf 81006044" is a distinct entry from "81006044," "81-6044" is a stylized way of representing "81006044," and "81-6044" is _not_ a match for "sf 81006044."  Short of writing a lot of code to handle prefixes (in both the user-entered query and the returned result), returning both results is probably the easiest thing to do, as well as a good way to allow loose searches (e.g. if someone has that 1877 book and they don't include the 'sf' prefix, just entering '81006044,' they'll get their result).

I would like to point out that an LCCN search through the loc.gov web interface for '81006044' _only_ returns Soul of a New Machine.

Perfect, thanks. I just added the LCCN validator to the 1.3 branch. It'll be
in the next release, or you can check it out and test it now. It works on
both the SRU and z39.50 sources.

cool :)

Okay, I tried checking out the 1.3 branch (to do the testing on that 1877 result) but I don't think I picked up your changes.  I don't really understand Subversion.  I tried:
$ svn ls https://forgesvn1.novell.com/svn/tellico/
and then:
$ svn ls https://forgesvn1.novell.com/svn/tellico/tags/
which told me about both the 1.3 and 1.31 branches.  I checked them both out, to different directories:
$ svn checkout https://forgesvn1.novell.com/svn/tellico/tags/tellico-1.3.1/
wouldn't return results for 81-6044 but did return results for 81006044, implying that it didn't have the new LCCN validator changes, so I tried the 1.3 branch:
$ svn checkout https://forgesvn1.novell.com/svn/tellico/tags/tellico-1.3/
but that didn't allow LCCN searches at all: implying that none of the 1.3.1 changes exist on the 1.3 branch.

Is there something obvious I'm missing, or something else that I need to do to pick up the latest 1.3 changes?

Thanks,

Andrew

--
---
Andrew Bennett
drewbenn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
_______________________________________________
tellico-users mailing list
tellico-users@...
http://forge.novell.com/mailman/listinfo/tellico-users
Permalink | Reply | 1 comment |
headers
Robby Stephenson | 1 May 08:04
Gravatar

Re: LoC query for older LCCNs

On Wednesday 30 April 2008, Andrew Bennett wrote:
> My understanding is that "sf 81006044" is a distinct entry from
> "81006044," "81-6044" is a stylized way of representing "81006044," and
> "81-6044" is _not_ a match for "sf 81006044."  Short of writing a lot of
> code to handle prefixes (in both the user-entered query and the returned
> result), returning both results is probably the easiest thing to do, as
> well as a good way to allow loose searches (e.g. if someone has that 1877
> book and they don't include the 'sf' prefix, just entering '81006044,'
> they'll get their result).

Makes sense.

> $ svn checkout
> https://forgesvn1.novell.com/svn/tellico/tags/tellico-1.3.1/ wouldn't
> return results for 81-6044 but did return results for 81006044, implying
> that it didn't have the new LCCN validator changes

That's the actual 1.3.1 release, which is a frozen "tag", so to speak. It 
doesn't have any of the changes since the 1.3.1 release. The branch is 
https://forgesvn1.novell.com/svn/tellico/branches/tellico-1.3.x/ You can 
switch your checkout without having to redownload most everything by the 
command:

svn switch https://forgesvn1.novell.com/svn/tellico/branches/tellico-1.3.x/

inside your 1.3.1 directory.

Robby
Permalink | Reply | 0 comments |
headers
Karolina | 1 May 14:42
Picon
Favicon
Gravatar

Re: IMDB Import

torsdagen den 1 maj 2008 skrev Robby Stephenson:

> Update Entry -> IMDb will update empty values with the new ones.
>
> Robby

Yes, but will it create the fields too?

How are IMDb entries mapped to fields? It can't be through field names, since 
my field names are all in Swedish and IMDB is in english. So there must be 
some internal field name, or mapping somehow?

So far I have believed that if I delete a field, it is gone forever, since 
that internal mapping is lost, or how is it?
Permalink | Reply | 3 comments |
headers
Robby Stephenson | 1 May 16:01
Gravatar

Re: IMDB Import

On Thursday 01 May 2008, Karolina wrote:
> torsdagen den 1 maj 2008 skrev Robby Stephenson:
> > Update Entry -> IMDb will update empty values with the new ones.
> >
> > Robby
>
> Yes, but will it create the fields too?

Oh right, I see what you're asking. I just tried, and it looks like they get 
created but not filled. So that's something to fix.

> How are IMDb entries mapped to fields? It can't be through field names,
> since my field names are all in Swedish and IMDB is in english. So there
> must be some internal field name, or mapping somehow?

Each field has an unchanging name, all in english, and a changeable title, 
Swedish in your case. AN internal field name, as you say, and that's what 
is mapped.

> So far I have believed that if I delete a field, it is gone forever,
> since that internal mapping is lost, or how is it?

If you create a new field, the internal name is taken from the title, but 
once it's set, it's never changed. So for a new field given a title of 
Location, the name is location, even if you later change the title to 
something else.

The search dialog will automatically create new fields if those options are 
turned on in the source configuration. Even if you later delete them.

Thanks for illustrating the problem with the updating. I'll get that fixed.

Robby
Permalink | Reply | 2 comments |
headers
Derek Broughton | 1 May 16:46
X-Face
Picon

Re: IMDB Import

Robby Stephenson wrote:

> On Thursday 01 May 2008, Karolina wrote:
>> torsdagen den 1 maj 2008 skrev Robby Stephenson:
>> > Update Entry -> IMDb will update empty values with the new ones.
>> >
>> > Robby
>>
>> Yes, but will it create the fields too?
> 
> Oh right, I see what you're asking. I just tried, and it looks like they
> get created but not filled. So that's something to fix.

Wouldn't that mean that if you just ran Update Entry twice, the fields would
be filled?  Not ideal, but at least a work-around.
--

-- 
derek
Permalink | Reply | 1 comment |
headers
Robby Stephenson | 2 May 05:17
Gravatar

Re: IMDB Import

On Thursday 01 May 2008, Derek Broughton wrote:
> Robby Stephenson wrote:
> > On Thursday 01 May 2008, Karolina wrote:
> >> torsdagen den 1 maj 2008 skrev Robby Stephenson:
> >> > Update Entry -> IMDb will update empty values with the new ones.
> >> >
> >> > Robby
> >>
> >> Yes, but will it create the fields too?
> >
> > Oh right, I see what you're asking. I just tried, and it looks like
> > they get created but not filled. So that's something to fix.
>
> Wouldn't that mean that if you just ran Update Entry twice, the fields
> would be filled?  Not ideal, but at least a work-around.

True, that does indeed work.

Robby
Permalink | Reply | 0 comments |
headers
Peter and Jesse | 5 May 19:31

Canadian Library of Congress Call Numbers

First of all, thanks for a great program.
The patch you put in for adding the call numbers is really
helpful
(http://www.periapsis.org/archives/2004/12/09/importing_additional_mods_info_to_tellico.html),
although it can't be patched anymore, since the code has changed. But it's easy enough to add it by hand. I
encourage you to put it directly in the code in future versions!
I just wanted to post for interested folks a patch for all the Canadians
out there. It just searches for Canadian LoC call numbers first, and if
it doesn't find any, then it will display the American ones. It works
well with the AMICUS database (info at
http://www.collectionscanada.gc.ca/amicus/006002-400-e.html), but you
have to register first.
Thanks again!
This is for tellico version 1.3

*** MARC21slim2MODS3.xsl	2008-05-04 16:46:38.000000000 -0700
--- MARC21slim2MODS3.xsl	2008-05-04 16:48:24.000000000 -0700
***************
*** 1095,1100 ****
--- 1095,1114 ----
  				</xsl:choose>
  			</subject>
  		</xsl:for-each>
+ 		<xsl:for-each select="marc:datafield[@tag=055]">
+ 			<xsl:for-each select="marc:subfield[@code='b']">
+ 				<classification authority="lcc">
+ 					<xsl:value-of
select="preceding-sibling::marc:subfield[@code='a'][1]"/>
+ 					<xsl:text> </xsl:text>
+ 					<xsl:value-of select="text()"/>
+ 				</classification>
+ 			</xsl:for-each>
+ 			<xsl:for-each
select="marc:subfield[@code='a'][not(following-sibling::marc:subfield[@code='b'])]">
+ 				<classification authority="lcc">
+ 					<xsl:value-of select="text()"/>
+ 				</classification>
+ 			</xsl:for-each>
+ 		</xsl:for-each>
  		<xsl:for-each select="marc:datafield[@tag=050]">
  			<xsl:for-each select="marc:subfield[@code='b']">
  				<classification authority="lcc">
Permalink | Reply | 1 comment |
headers
HED | 5 May 20:36
Picon

Spanish Ministery of Culture


Hi all,

The URL for the Spanish Ministery of Culture has changed again. The new URL
for searching is 

http://www.mcu.es/webISBN/tituloSimpleFilter.do

I've no idea of Python so I can't make a patch, but I report the change.

Greetings.
--

-- 
View this message in context: http://www.nabble.com/Spanish-Ministery-of-Culture-tp17067994p17067994.html
Sent from the Tellico mailing list archive at Nabble.com.
Permalink | Reply | 13 comments |
headers
Carles Pina i Estany | 6 May 00:20

Re: Spanish Ministery of Culture


Hi,

On May/05/2008, HED wrote:

> The URL for the Spanish Ministery of Culture has changed again. The
> new URL
> for searching is
>
> http://www.mcu.es/webISBN/tituloSimpleFilter.do
>
> I've no idea of Python so I can't make a patch, but I report the
> change.

I will take a look this week (or on weekend). If somebody could do it
before, fantastic (i have just arrived from some small holidays...)
(I don't know if they changed the URL or the searching system, I hope
that it's not the second)

Thanks for the report,

--

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona
Permalink | Reply | 0 comments |

Gmane