I agree that it's a bit annoying. No idea why the specs were written liken this. It seems like it was already the case in RFC 1766 (March 1995) , so it goes back a while.
As long as the AAT is consistent in it's usage of lowercase the problem should be fixable. Interestingly enough they do use some of the conventions in the URI's they have, eg. http://vocab.getty.edu/aat/term/1000563645-zh-Latn-pinyin-x-hanyu (Doesn't work if you lowercase it there). Cheers, Koen ________________________________ Van: Alexei Peters <[email protected]> Verzonden: woensdag 6 januari 2016 18:54 Aan: Van Daele, Koen CC: Arches Project Onderwerp: Re: [Arches] error in SPARQL query Thanks for pointing that out Koen. While they do say the these codes are case insensitive, later they go on to specify certain conventions (which in my opinion the AAT should follow, but don't). These conventions include: o [ISO639-1<http://tools.ietf.org/html/rfc5646#ref-ISO639-1>] recommends that language codes be written in lowercase ('mn' Mongolian). o [ISO15924<http://tools.ietf.org/html/rfc5646#ref-ISO15924>] recommends that script codes use lowercase with the initial letter capitalized ('Cyrl' Cyrillic). o [ISO3166-1<http://tools.ietf.org/html/rfc5646#ref-ISO3166-1>] recommends that country codes be capitalized ('MN' Mongolia). In any case it looks like we'll have to do exactly as you recommend and lowercase our language codes when interacting with the AAT. Cheers, Alexei Director of Web Development - Farallon Geographics, Inc. - 971.227.3173 On Wed, Jan 6, 2016 at 1:23 AM, Koen Van Daele <[email protected]<mailto:[email protected]>> wrote: Hi Alexei, that tripped me up in the past as well (casing of subtags). But the AAT way is valid. See http://tools.ietf.org/html/rfc5646#page-6 (2.1.1) . While there are conventions for displaying, they do not carry any meaning and are purely formatting. en-US and en-us should be treated as identical. Not sure, but if the AAT always uses the lowercase version, you can just always construct the filter lowercase? Cheers, Koen Op dinsdag 5 januari 2016 20:07:58 UTC+1 schreef Alexei Peters: Hi Angela, I looked into this issue and there are a couple of things that are preventing you from importing the AAT value for "stovewood construction" (http://vocab.getty.edu/aat/300164032). If you notice, the raw query includes a FILTER for language. By looking at your query I can see that you have only one language defined (en-US). If you remove the FILTER portion of the query and run it directly from the link provided you'll see that the AAT provides this concept in 4 languages (en-us, en, nl, es). The issue seems to be that the AAT lowercases the region subtag part of the language code (the "US" part of "en-US"). This seems to go against convention (look at the examples provided by the IETF itself http://tools.ietf.org/html/rfc5646#appendix-A). Because of this our filter doesn't work. A quick work around would be to add the "en" base language to your Arches installation via the admin page (localhost:8000/admin). You'll then need to restart your web server (or the django dev server) for the change to take effect (which is an actual bug in our software). If you do that, you should be able to import that concept. Hope this helps, Alexei Director of Web Development - Farallon Geographics, Inc. - 971.227.3173<tel:971.227.3173> On Tue, Jan 5, 2016 at 7:31 AM, Angela Labrador <[email protected]> wrote: Hello all and happy 2016, I am encountering a SPARQL query error in the RDM when trying to import a child concept from the AAT (attached photo). When I choose "Import Child" I can search the AAT and the Concept Identifier is completed correctly; however, the syntax for the query seems to be incorrect because it returns 0 results (and the error). I have tried accessing the same concept id from vocab.getty.edu<http://vocab.getty.edu> by using their search bar and can (http://vocab.getty.edu/resource/getty/search?q=300164032&luceneIndex=Brief&indexDataset=AAT&_form=%2Fqueries); however, I don't know how to correct the query itself. On the surface it seems that the query syntax that vocab.getty.edu<http://vocab.getty.edu> is expecting doesn't match what the latest Arches-HIP is using. But, I wanted to confirm that this was the case and not a problem with my settings or configuration before reporting it on Bitbucket. Thanks, Angela [X]<https://lh3.googleusercontent.com/-Tf2wexWbMfU/VoveM1ReZAI/AAAAAAAABEI/thpcZDcJycQ/s1600/screen-capture.png> -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]<mailto:[email protected]>. To unsubscribe, send email to [email protected]<mailto:archesproject%[email protected]>. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
