Great ! guys.

The logical answer and the prospective designer tool are the best answers I 
could have hoped for! :-)

You just brought down in half the first rough extentions costs I had.

Have a good weekend. 

Le 13 février 2016 14:17:17 HNE, Adam Lodge <[email protected]> a écrit :
>Adam,  
>
>In order of your questions asked, the answers are no and yes.  The DB
>only enforces that the graphs contain classes and properties that are
>loaded to the respective classes and properties tables.  We assume,
>therefore, that if the graphs are intended to be truly CRM-compliant
>(or compliant with any other loaded ontology), that the designer of the
>graph is someone who is qualified to make that (fairly subjective)
>judgement call.
>
>That said, your point about the source/target columns of the properties
>table is valid.  They are not used for any meaningful purpose in the
>Arches v3.  In earlier iterations, we used them when we took a swing at
>deeper enforcement of CRM rules, but backed off on that as we came to
>better understand the appropriate role of Arches in facilitating CRM -
>not defining it.
>
>There is some exciting stuff coming up in this area in Arches v4
>because we will be including a graph design tool.  Our intent is that
>ontologies will be enforced at graph-design-time, and the actual Arches
>DB will import graphs with no ontology enforcement at all.  That will
>provide the best flexibility to use (or not use) ontologies in your
>graph design, and the benefit of tight enforcement at design-time if it
>is desired.   
>
>Thanks for the good questions..
>Adam
>
>--  
>Adam Lodge
>Geospatial Systems Consultant
>Farallon Geographics
>
>
>On Saturday, February 13, 2016 at 10:22 AM, Adam Cox wrote:
>
>> Hi Adam and Philippe, thanks for the great info.  I've looked at the
>db_data.sql file, and it leads to another question:  Where the
>properties are defined, it looks like two entities are included,
>presumably as a "source"/"target" pair.  Is this enforced anywhere in
>the database?  Also, are the labels that are included in the entity and
>property definitions the only things that explicitly tie the classes
>and properties to the CIDOC CRM?
>>  
>> Adam
>>  
>> On Friday, February 12, 2016 at 10:09:07 AM UTC-6, Adam Lodge wrote:
>> >  
>> > Hi Philippel,
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > It sounds like what you are really asking for is this: What are the
>steps necessary to build an Arches Application (something different
>from the pre-made “HIP” application) that includes ontology beyond
>CIDOC CRM? In the interest of helping you get to where I think you are
>looking for, I’ll target my answer toward that question.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > As a first step, you will want to define the resource graphs
>(http://arches3.readthedocs.org/en/latest/arches-data/#resource-graphs)
>that you want to load to Arches.  The act of defining your resource
>graph(s) forces you to define what ontological classes and properties
>you wish to assign to each node in your graph.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > If you wish to apply classes and properties that are outside of the
>realm of CIDOC CRM, you will need to make Arches aware of these
>additional ontologies by loading them to the respective classes and
>properties tables within the ontology schema of the underlying
>database.  The easiest way to do that is to update
>//arches/db/db_data.sql file.  You will just have to add the insert
>statements necessary to account for these new classes and properties.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > After you have populated the Arches db with these new classes and
>properties, you then can load the graphs you built in the first step
>outlined above without errors.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > I believe the next major consideration will be around building the
>UI to interact with your custom resource graphs.  Following the js
>examples provided in the HIP application should get you a long way on
>that, but others more knowledgeable than I in that area may want to
>chime in.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> > I hope this helps.  Best,
>> >  
>> >  
>> > Adam
>> >  
>> >  
>> >  
>> > --  
>> > Adam Lodge
>> > Geospatial Systems Consultant
>> > Farallon Geographics
>> >  
>> >  
>> > On Wednesday, February 10, 2016 at 5:16 PM, Philippel wrote:
>> >  
>> > > Hello,
>> > >  
>> > >  
>> > > I am not sure if I should open a new thread with this, but it
>seems the right place to start.
>> > >  
>> > > Considering implementation considerations.
>> > >  
>> > > We are working on a regular basis with Django, so we have been
>mandated to evaluate costs of implementing Arches.
>> > >  
>> > > The business experts are working with domain experts and
>ontological experts, so the how we get there, on the data side, if
>fairly well covered. What I can't figure out yet is the following.
>> > >  
>> > > Given that the domain we have to integrate is wider than the
>CIDOC CRM ontology capabilities, we will need to integrate parts of
>other ontologies. Possibly create a proprietary ontology exploiting
>CIDOC and others.
>> > >  
>> > > So basically not everything will be EXX and PYY, but I will have
>all the necessary conceptual model needed to generate the files and SQL
>to preload Arches and have the ontology data and thesaurus.
>> > >  
>> > > What are the layers that will needed to be updated to implement
>the business logic that is outside of the Arches normal implementation?
>> > >  
>> > > How complex is it, for a regular Django developer ?
>> > >  
>> > >  
>> > > I have not look in details to the use of template done by Arches,
>but it seemed fairly straight forward. So I expect that as long as I
>have regular views and entities in the end, the integration of forms
>and security should be stream line work.
>> > >  
>> > > Anyone as insight on this ?
>> > >  
>> > > Thanks
>> > >  
>> > > Philippe Laliberté
>> > > --  
>> > > -- To post, send email to [email protected]
>(mailto:[email protected]). To unsubscribe, send email to
>[email protected]
>(mailto:[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]
>(mailto:[email protected]). To unsubscribe, send email to
>[email protected]
>(mailto:[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.

Réponse mobile. Excusez la brièveté.

-- 
-- 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.

Reply via email to