Importing "Places" xml results in Subjects Taxonomy as destination not Places Taxonomy
|Assignee:||José Raddaoui Marín||% Done:|
|Target version:||Release 1.4.0|
|Google Code Legacy ID:||atom-2299||Tested version:|
Google user: jessica%...@gtempaccount.com
To reproduce this error:
1)import taxonomy xml for places
taxonomy results in subjects
taxonomy results in places
[g] Legacy categories: Taxonomy / term
#5 Updated by Jesús García Crespo over 8 years ago
Radda, check this: https://github.com/artefactual/atom/blob/1.x/lib/QubitXmlImport.class.php#L156
We should pass the taxonomy to sfSkosPlugin::parse().
I guess here: https://github.com/artefactual/atom/blob/1.x/lib/task/importBulkTask.class.php#L95
#6 Updated by José Raddaoui Marín over 8 years ago
- Status changed from New to In progress
Thanks Sevein, we're always using the subjects taxonomy in the SKOS import proccess.
But, how can we determine the taxonomy for the import? I've took a look at the skos reference but I couldn't find where the taxonomy may be specified.
#7 Updated by Jesús García Crespo over 8 years ago
- Assignee changed from José Raddaoui Marín to Dan Gillean
That's a good question. Let's assign this to Dan so he can take a closer look to the reference. Maybe we can force the user to pass an option like "--skos-type" to define the taxonomy being used. From the web ui, we may have to wait for the step-by-step bulk import feature so we can ask the user after the SKOS has been proplery uploaded and detected by the app, and in the meanwhile just assume a default value?
#8 Updated by Jesús García Crespo over 8 years ago
- Assignee changed from Dan Gillean to José Raddaoui Marín
- Target version changed from Release 1.4.0 to Release 2.1.0
Radda, this is a comment from a user that may be helpful.
Regarding this ‘bug’: I think you need to change sfSkosPlugin.Class.php. Changing importBulkTask.class.php has no effect in the choice of the correct taxonomy. However, changing sfSkosPlugin.class.php has the correct result. I just added some small logic to pick the right taxonomy, using QubitTaxonomy::SUBJECT_ID as default taxonomy. My logic won’t be monkey-proof but is based on the values of the dc:title childnodes of the element ConceptSchema. I just added this logic behind the comments on line 49 “//Set taxonomy” Maybe this can lead you towards a (more) stable solution?
#10 Updated by Dan Gillean over 8 years ago
PS - Radda, I also don't know of anything in the SKOS standard that would allow us to determine the target - my thought is, once we have incorporated a job scheduler, we will want to review the import GUI overall (as we will also want to develop our options further to allow for bulk import/export, etc) - and at this point, we can consider adding an option for a user to set the target taxonomy prior to clicking import.
#11 Updated by Mike Gale over 8 years ago
Hi Radda, I just saw this ticket, please see this commit:
I didn't get a ton of time to QA test it, but I think this is basically what you want to do here except it's for CLI instead of GUI.
#12 Updated by José Raddaoui Marín over 8 years ago
I can add a select in the sfSkosPlugin/import page where the user can pick the taxonomy and pass it to the import script. But what can I do in the general import/xml page? Doesn't seem right to add the select there. Maybe we can add a message saying something like "If you're going to import an SKOS file in a taxonomy different than subjects go to sfSkosPlugin/import" and linking the page. Any other ideas?
#13 Updated by Dan Gillean over 8 years ago
Once we have the job scheduler, I think we will have to do a broader redesign of the general imports page, so your solution sounds fine for now. It would be great if, in the future, we had logic that could detect if it was a SKOS file and provide the user with a pop-up asking them which taxonomy - a scheduler seems like it would allow for this since it could cue the job until it receives the necessary input. For now, however, I think that what you propose is still a much needed improvement.
I would put it as such: "If you are importing a SKOS file to a taxonomy other than subjects, please go to the "
#15 Updated by Dan Gillean over 8 years ago
- Status changed from QA/Review to Feedback
Everything works great; it's a workaround solution for now but it works fine.
One tiny minor point I noticed that I wonder if we have a means of fixing: see, in the attached screenshot, the title of the page we are redirected to: "Import Subjects (SKOS)".
This seems odd to me, since the user has just clicked a link because they are importing terms "other than Subjects".
The URL for the page appears generic (http://1x.test.artefactual.com/;sfSkosPlugin/import) - you get the "Import places" Title if you go through the GUI (Manage > Taxonomies > Places > Import SKOS), and end up at a more specific URL: http://1x.test.artefactual.com/places;sfSkosPlugin/import
Similarly, going through the GUI (Manage > Taxonomies > Subjects > Import SKOS) to arrive at the Subjects import gives you the URL: http://1x.test.artefactual.com/subjects;sfSkosPlugin/import
So my ideal solution then is:
If, then, it's true that the original URL is generic, can we make that page just say "Import Terms (SKOS)" without changing the more specific pages for Subjects and Places?
If this is NOT possible, then I would suggest that the link from the general XML pages (the one that links to the SKOS Import page) should actually go to /places;sfSkosPlugin/import, since this is the next most likely kind of term that users import.