[Arches] What's the meaning of "collector" in authority files?

[Cindy Mao]

Hi all,

I see there are two different kinds of ConceptType in the sample authority 
files, but I don't really understand when shall I give a "collector", not 
an "index". Can somebody explain this for me?  I’d be grateful for any 
knowledge you all may have.

Best,
Cindy

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. 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 archesproject+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arches] Supporting "fuzzy dates", approximations, and uncertain dates in Arches

[Angela Labrador]

Greetings!

While learning how Arches works and testing it out in house, we found that 
adding Extended Date/Time Format 
support to 
Arches date fields would possibly benefit users who need to manage a wider 
range of dates in their inventory system: dates such as "about 1800" or 
date ranges such as "1934 - present". 

We've developed a validation function that can handle such date strings 
while maintaining consistency and basic integrity for search in Arches. The 
feature is available to the community at our Github repository along with 
more detailed technical documentation 
 for installing and testing. 
Our recent blog article 
 provides some 
background as well. 

Please try it out -- we welcome all contributions and issue reports at our 
repo!

Hope this helps out some folks,
Angela Labrador, PhD.
Coherit Associates, LLC

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. 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 archesproject+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Arches] Changes to resource.py do not seem to be read

[zerbini . eamena]

I will try this soon Alexei - thank you. May I ask why one has to rerun the 
install command? Also, will have to rerun the install whenever I modify the 
resource.py?




On Friday, May 6, 2016 at 7:50:07 AM UTC+1, Alexei Peters wrote:
>
> Andrea,
> I was able to achieve what you wanted by creating a resource.py file that 
> inherits from arches_hip.
> I then only overwrite the function that you're interested in and made the 
> changes you mentioned (entity_data = _('None')).
> I've attached the file here.
>
> in my settings file, nothing unusual:
> RESOURCE_MODEL = {'default': 'arches_la.models.resource.Resource'}
>
> I re-ran the install (python manage.py packages -o install) after adding 
> this file and I got the result you expected.
> Hope any of this helps.
> Cheers,
> Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Thu, May 5, 2016 at 9:22 AM, Adam Cox  > wrote:
>
>> Oh, sure.  In fact, you can see them here (and the rest of the app): 
>> https://github.com/mradamcox/afrh/blob/master/afrh/models/resource.py
>>
>> The forms imports reference the new forms I've made for this project, so 
>> leave those out...
>>
>> On Thu, May 5, 2016 at 10:17 AM,  
>> wrote:
>>
>>> Thanks for this Adam. I tried applying your fixes, but clearly I must be 
>>> missing some imports out, cause I get a DoesNotExist error on 
>>> eamena.models.resource.Resource and, once that happens for the first time, 
>>> even if I roll things back I am forced to raze elasticsearch and replace it 
>>> with a backup copy. Could you by any chance post me the complete list of 
>>> your imports on your app's resource.py.
>>>
>>> Thanks,
>>>
>>> Andrea
>>>
>>> On Wednesday, May 4, 2016 at 7:44:37 PM UTC+1, Adam Cox wrote:

 Ok, here's how I just got this to work:

 If you go back to the arches.models.resource file, you'll find that 
 there are a set of functions that should be moved together, in order for 
 them to correctly reference each other. The first two are bulk_index() and 
 index().  Both of these functions call four other indexing functions, one 
 of which is prepare_documents_for_map_index(), which you are trying to 
 modify.  So, I'd recommend copying and pasted these six functions into 
 your 
 resource.py file.
 bulk_index()
 index()
 prepare_documents_for_search_index()
 prepare_documents_for_map_index()
 prepare_terms_for_search_index()
 prepare_documents_for_report_index()

 You'll also have to add (at least)
 from arches.app.models.entity import Entity
 to the top of your resource.py file.  I already had some extra import 
 statements in mine when I did this, so there may something missing for you 
 when you try this.

 After adding those functions to my resource.py file, the map popup info 
 was updated as desired.  Note that the index() function is called on a 
 resource any time you save a new node to it, so if it's not working right 
 away, edit the resource, save it, and return to the map view.

 Let me know if that works.

 Adam

 On Wed, May 4, 2016 at 12:06 PM, Adam Cox  wrote:

> Sounds good.  The .pyc file is a compiled version of a .py file which 
> means that your resource.py file has been used by the app.  One thing I 
> do 
> all the time is add print statements within functions to double check 
> that 
> they are being called.  Just inside the prepare_documents_for_map_index 
> function, try adding print "prepare_documents_for_map_index IS BEING 
> USED" 
> or something.  Then watch the server console output.
>
> I haven't had to modify that function yet, but if a simple 
> modification to it is not reflected, you may need to do a little 
> sleuthing, 
> because it's possible that it is only called from inside the arches 
> "site-package", in which case you may need to migrate more functions to 
> your own app and change some import statements.  Alexei would have a 
> better 
> handle on that right now than I do...
>
> Adam 
>
> On Wed, May 4, 2016 at 11:51 AM,  wrote:
>
>> Not only did I do that Adam, I also tried deleting both resource.py 
>> files from my app and the Arches-HIP folder structure. No effect 
>> whatsoever. 
>>
>> A small update though. It would appear that, by setting up the 
>> RESOURCE_MODEL path as you indicated and after restarting Postgres.app, 
>> I 
>> finally got django to re-render resource.pyc in my app folder (which I 
>> had 
>> deleted) - so the source file was finally accessed. However, once again 
>> there has been no change in the entity_data default string, which still 
>> gets displayed in the Resource map popup as 'None specified' despite my 
>> having changed it 

Re: [Arches] Changes to resource.py do not seem to be read

[Alexei Peters]

Andrea,
I was able to achieve what you wanted by creating a resource.py file that
inherits from arches_hip.
I then only overwrite the function that you're interested in and made the
changes you mentioned (entity_data = _('None')).
I've attached the file here.

in my settings file, nothing unusual:
RESOURCE_MODEL = {'default': 'arches_la.models.resource.Resource'}

I re-ran the install (python manage.py packages -o install) after adding
this file and I got the result you expected.
Hope any of this helps.
Cheers,
Alexei


Director of Web Development - Farallon Geographics, Inc. - 971.227.3173

On Thu, May 5, 2016 at 9:22 AM, Adam Cox  wrote:

> Oh, sure.  In fact, you can see them here (and the rest of the app):
> https://github.com/mradamcox/afrh/blob/master/afrh/models/resource.py
>
> The forms imports reference the new forms I've made for this project, so
> leave those out...
>
> On Thu, May 5, 2016 at 10:17 AM,  wrote:
>
>> Thanks for this Adam. I tried applying your fixes, but clearly I must be
>> missing some imports out, cause I get a DoesNotExist error on
>> eamena.models.resource.Resource and, once that happens for the first time,
>> even if I roll things back I am forced to raze elasticsearch and replace it
>> with a backup copy. Could you by any chance post me the complete list of
>> your imports on your app's resource.py.
>>
>> Thanks,
>>
>> Andrea
>>
>> On Wednesday, May 4, 2016 at 7:44:37 PM UTC+1, Adam Cox wrote:
>>>
>>> Ok, here's how I just got this to work:
>>>
>>> If you go back to the arches.models.resource file, you'll find that
>>> there are a set of functions that should be moved together, in order for
>>> them to correctly reference each other. The first two are bulk_index() and
>>> index().  Both of these functions call four other indexing functions, one
>>> of which is prepare_documents_for_map_index(), which you are trying to
>>> modify.  So, I'd recommend copying and pasted these six functions into your
>>> resource.py file.
>>> bulk_index()
>>> index()
>>> prepare_documents_for_search_index()
>>> prepare_documents_for_map_index()
>>> prepare_terms_for_search_index()
>>> prepare_documents_for_report_index()
>>>
>>> You'll also have to add (at least)
>>> from arches.app.models.entity import Entity
>>> to the top of your resource.py file.  I already had some extra import
>>> statements in mine when I did this, so there may something missing for you
>>> when you try this.
>>>
>>> After adding those functions to my resource.py file, the map popup info
>>> was updated as desired.  Note that the index() function is called on a
>>> resource any time you save a new node to it, so if it's not working right
>>> away, edit the resource, save it, and return to the map view.
>>>
>>> Let me know if that works.
>>>
>>> Adam
>>>
>>> On Wed, May 4, 2016 at 12:06 PM, Adam Cox  wrote:
>>>
 Sounds good.  The .pyc file is a compiled version of a .py file which
 means that your resource.py file has been used by the app.  One thing I do
 all the time is add print statements within functions to double check that
 they are being called.  Just inside the prepare_documents_for_map_index
 function, try adding print "prepare_documents_for_map_index IS BEING USED"
 or something.  Then watch the server console output.

 I haven't had to modify that function yet, but if a simple modification
 to it is not reflected, you may need to do a little sleuthing, because it's
 possible that it is only called from inside the arches "site-package", in
 which case you may need to migrate more functions to your own app and
 change some import statements.  Alexei would have a better handle on that
 right now than I do...

 Adam

 On Wed, May 4, 2016 at 11:51 AM,  wrote:

> Not only did I do that Adam, I also tried deleting both resource.py
> files from my app and the Arches-HIP folder structure. No effect
> whatsoever.
>
> A small update though. It would appear that, by setting up the
> RESOURCE_MODEL path as you indicated and after restarting Postgres.app, I
> finally got django to re-render resource.pyc in my app folder (which I had
> deleted) - so the source file was finally accessed. However, once again
> there has been no change in the entity_data default string, which still
> gets displayed in the Resource map popup as 'None specified' despite my
> having changed it to 'None' in resource.py.
>
> I look forward to more ideas,
>
> Andrea
>
>
> On Wednesday, May 4, 2016 at 6:39:30 PM UTC+1, Adam Cox wrote:
>>
>> That's very strange.  Just to confirm: you copied the
>> arches_hip/models/resource.py file, pasted it into the corresponding
>> directory of your own app, and then changed the RESOURCE_MODEL as 
>> described
>> above, correct?  That's all you should need to