-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data model: full support for references #430
Comments
cc: @jalavik, @annetteholtkamp |
We would also need an object for “reportnr, page” in case a report contains several contributions - see e.g. CERN Yellow Reports.
On 20 Oct 2015, at 14:30, Samuele Kaplun notifications@github.com wrote:
|
Well, if we split up $s into its components then we would naturally have separate page and reportnumber supporting your above Yellow report use case. Regarding Conf acronym, do we have some today in 999C5? |
Not yet, but we’ve already some in 773. As soon as we’re exposing that in our bibliographic data we should be able to recognise the corresponding references as well.
On 20 Oct 2015, at 14:53, Samuele Kaplun notifications@github.com wrote:
|
Just to ask:
Thus, isn't the link(tm) enough probably drawing in some display and get expansions for indexing? Ie for me references sound a bit like "just the same as the gigantic workflow, except it's children live in HEP space". The exception are references that are not in inspire, ie. records that usually do not get a curation etc. Thus they will end up in some free form text anyway. I wonder if such an approach would not simplify the model a lot. |
@aw-bib we have to store the whole reference (possibly already structured) because we don't know if:
So the link is not enough. But indeed it is a good point that the reference could basically be structured almost as whole record. That open up quite some reflection points... In fact it all boils down to how much information we are able to match from publishers or guess from PDFs via refextract/Grobid. |
I see your point, but wouldn't in this case storage of the raw string be enough? If not, why not use the data extracted and create a (stub) record and use this for linking. Then you are sure you can map every needs. If the real record comes in later, just brush up the stub by usual merging. I think this simplifies the overall data structure. So the question is it worth the efford to add a nested record structure, with all its complications. |
Moving discussion to dedicated issue #1099 |
@bittirousku can you take care of the above points:
|
Sure, I can do that. |
List of dicts is always better. Otherwise one has to iterate over all items On Tue, 19 Jul 2016, 10:45 Jacopo Notarstefano, notifications@github.com
|
Uh! @eamonnmag what are you referring to? |
Unless I've misunderstood what you're storing in the references block and it's different from say, holdingpen, then if they are lists of lists you have this:
Now to display the references, I will have to loop over the array and get the 'correct' type in this case. If instead we have this:
I can just iterate over each reference and get 'correct'. Obviously the keys are rubbish in this case. But something like this. This would be especially convenient when you have perhaps even more than two. |
Currently |
The correct / erratum use-case should always happen when adding info between various versions and has to do with the way versioning is done. It will aways be The problem with list of lists was with references that share the same number. @kaplun You had a pdf example. So far, refextract did a mess in legacy references. List of lists are generally bad for versioning and merging since you have to match a list of reference-like things denoting a single reference with another list of reference-like things. The goal is to always keep |
Everything that had to be decided about this has already been decided in inspirehep/inspire-schemas#130. |
The text was updated successfully, but these errors were encountered: