Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I am having an import problem that I can't find a work-around for. I was hoping someone could help me. I also need some explanation regarding the Year field import.
In the import.inc.php file (RIS to refbase section) it states: "PY" => "year", // Date Primary (date must be in the following format: "YYYY/MM/DD/other_info"; the year, month and day fields are all numeric; the other info field can be any string of letters, spaces and hyphens; note that each specific date information is optional, however the slashes ("/") are not)
"Y1" => "year", // Date Primary (same syntax rules as for "PY")
I thought when I read this that since the format included YYYY/MM/DD/other_info that it would import this into the record. But refbase only imports the year. (Note: I know we've been over this road before but I read through our last Year thread and it didn't enlighten me at all.)
So the bibliographer that I'm working with didn't input some of the items (25 to be exact) correctly - in the correct format - so they imported into refbase as 3267 instead of the data that was actually there. I can explain that to her - no problem. Most of the time Y1 imports correctly because it is date formatted; but if she doesn't have anything in the Y1, then the data she has in Y2 is moved to Y1. Y2 is usually the /other_info data from the example above.
I can't use the Issue field (as we did for the newspaper publication database) to accommodate the fields and I'm out of creative ideas to make this work for her. Would you mind enlightening me regarding this part of the import script? Some of the Y2's are conference dates (if type = conference) but in the /other_info instance, it is usually not formatted like a date at all.
I've been dealing with fields that are not importing like she wants them to(right or wrong, I have to answer to her) by importing that field into the Notes field - this allows the data to mport correctly and the bibilographer can add it in the field of her choice, if she wants (my version of throwing up my hands in frustration!).
If any of you have other ideas (or my writing isn't clear - which would be a total surprise to me (have been moving all weekend & feeling it) - LOL -
I hope I described this problem sufficiently and with enough detail - if not, please feel free to ask for details. Thanks in advance for any help you can provide.
I am not clear what you are asking for. Please give at least one minimum example that contains Y1 and/or Y2, describe how it is being imported now & why you are not happy with that. If possible, describe what existing fields you want to be populated with what data. If not possible, please explain the limitations.
I've already answered one of my own questions about Y2 being put into Y1 if Y1 was initiall empty. That is done in the Reference Manager export process (have no idea why).
But let's start with one question at a time - maybe that will be helpful for us both:
#1 - Asking for explanation of how the Y1 field is imported into refbase. (I understand the use of import.inc.php file; however, what I'm looking for is where & why the import into refbase only brings the year date as long as it's formatted correctly (YYYY/MM/DD/other_info[aka Y2]).
Thx - C
> where & why the import into refbase only brings the year date as long as it's
> formatted correctly (YYYY/MM/DD/other_info[aka Y2]).
"Where" is also in import.inc.php. The postprocessor actions array extracts the four-digit year. "Why" is because refbase only has a field for the year.
I have figured out how to stop the postprocessing action so it doesn't extract the Year at all. Then if I could figured out where I want the entire Y1 field to live, I could use import.inc.php to designate that, right? My biggest problem right now is with Reference Manager exporting Y2 field correctly even if Y1 is empty (not your problem of course). I'll be back when I have a definite plan if I need some additional assistance. Thanks.
Okay, here's an example of a record that has no date information but the other_info part has data (all is alpha):
TY - JOUR
ID - 2651
T1 - Coyote
A1 - Murie,Adolph
Y1 - ///Yellowstone Special Issue
KW - NRBIB_YELL
KW - animal studies
KW - management
KW - natural resource management
KW - mammals
KW - coyote (Canis latrans)
KW - predation
KW - population
KW - population control
RP - NOT IN FILE
SP - 44
EP - 45
JF - Naturalist
VL - 10
IS - 2
N2 - brief history of the coyote populations and management practices inside Yellowstone National Park.
When it is imported (individually), it comes in correctly into the record (Year field contains ///Yellowstone Special Issue); however, once it is saved, the Year field converts to 0. If I did a batch import, it would be seen as 3267 in the year instead of 0.
How do I get the other_info data into a record field so it is useable? This happens consistently and the importing data can have the 3 forward slashes in front of it or not - has no effect on the outcome. Can this "other_info" data be placed somewhere else? The "other_info" is part of the date formatting - why isn't it put somewhere when it is imported?
> When it is imported (individually), it comes in correctly into the record (Year
> field contains ///Yellowstone Special Issue); however, once it is saved, the
> Year field converts to 0. If I did a batch import, it would be seen as 3267
> in the year instead of 0.
In the database, year is a small integer field & it can not be used to store generic text. This is why we have the formatting code that you chose to remove.
> How do I get the other_info data into a record field so it is useable? This
> happens consistently and the importing data can have the 3 forward slashes in
> front of it or not - has no effect on the outcome.
You must put it in some field other than "year."
> The "other_info" is part of the date formatting -
> why isn't it put somewhere when it is imported?
It reflects our bias: that fourth bit of information is used even more rarely than month/day in common RIS exports. Many other reference managers either ignore it or treat the whole field as a "dumb" string & have problems w/ citation, etc.
I'm not saying we shouldn't ever handle it, of course.