archesproject / arm_working_group Goto Github PK

Basic description branch as discussed in May meetings. Branch JSON to follow.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

The group has not considered appropriate cardinality and uniqueness setting for cards within our graphs. We should comb through our models, think through appropriate default settings for those, and apply them in order to consider the graphs complete.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Branch for Dimension as discussed during May 2018 meetings. JSON pending.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

What benefits are there for E31 Document over E73 Information Object?

• E31 has the P70 documents predicate, which is a subPropertyOf refers_to, but when the reference is "regarded as being of documentary character". This distinction has no use, but means that the E31 Document is equally of this ill-defined "documentary character".

• E31s only make propositions about reality, not about ... non-reality. This almost always impossible to determine from systems that are not natively encoded with the distinction ... which are none. The documentary-ness of documents that make absurd propositions about reality is not a matter for ontologists, but for scientists. For example, this well described pseudo-scientific document proving the earth is flat: http://library.tfes.org/library/Experimental_Proofs.pdf E31 or not? The Bible ... E31 or not?

So, my estimation is that the distinction of "propositions about reality" as opposed to propositions about anything is not very useful. Maybe all of the propositions in a work are about reality ... maybe they're not. We likely have absolutely no way of knowing, a priori, from a database entry. There's no system that I know of that would change its behavior in seeing an E31 vs an E73. Meaning that for practical purposes, the distinction is useless.

E73, on the other hand, has the important feature of being both symbolic and propositional. We can prune further back up the tree than that.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

https://docs.google.com/document/d/1OOmBdZVTlhHpEp6Czt5Mw66pgPQtaBwkk3XWXlrbq74/edit

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Name branch as discussed during May 2018 meetings (image includes basic branch and extension to branch). Branch JSON to follow.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

To abuse our issue tracking system here but ensure that there's visibility of the work for the larger group...

google doc for discussion of how to reboot CRMDig efforts towards a more useful goal:
https://docs.google.com/document/d/1qFJMwWwhyaydnutKFD_haI-WuN8AE2W1LBWrOdk5bwA/edit

A best practice question ... is it better to have two separate nodes in a model, each of which has specific configurations but the same relationship, or one node that has a broader configuration.

For example, groups have members that can be either sub-groups (hierarchy) or people (the leaf nodes). It can be accommodated in either way:

1. a single node, with P107 as relationship, that is a resource-instance that takes either a Group or a Person
2. two nodes, each with P107 as relationship, each is a resource-instance, one has only a Group the other only a Person

This seems related to / would have an impact on #3485 as well ... one might be easier to process incoming create/update requests.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

https://docs.google.com/document/d/1OOmBdZVTlhHpEp6Czt5Mw66pgPQtaBwkk3XWXlrbq74/edit

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Branch for Production as discussed during May 2018 meetings. JSON pending.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Branch/Resource Model for Man-Made Object as discussed during May 2018 meetings. JSON pending.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Branch/Resource Model for Group as discussed during May 2018 meetings. JSON to follow.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Basic Location Model

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve Model

For the majority of cases (that we consider in Linked.Art at least), we only need one way to partition text or other content, however there are two predicates in CRM for this:

P106 (Symbolic Object has_part Symbolic Object)
P148 (Propositional Object has_part Propositional Object)

The distinction is very clear to people who understand the CRM -- the part of the story where the hero lives happily ever after is part of many propositional objects (or plots), whereas the symbols that encode that plot point within a certain larger set of symbols (the book) is clearly not part of all those other stories.

The issue is that for most cases, both are simultaneously true, however one is not a subPropertyOf the other. The Information Object that represents the set of symbols that encodes the story within the book is both P106 and P148 to the Information Object of the book. The auction entry record in the auction catalog is both propositionally and symbolically part of the larger entity. And so on.

We don't (I strongly believe) want to always assert both P106 and P148 all the time. It's messy and no one beyond semantics junkies cares about the difference. Yes, "tea" is symbolically part of "team" but not propositionally ... but just don't do that then. We don't have a use case for strict symbolic subsets at arbitrary levels of granularity.

For consistency, we should pick which ever covers the most cases to avoid the gotcha of "Oh but for X class you need to use this other partitioning property...". And it's easy to pick, as Appellations are not Propositional, only Symbolic. Hence we should use P106 rather than P148. The only cases when P148 is required would be Propositional Object (rarely if ever used directly) and Right (already so semantically messed up as to be useless). All other classes that have PO as an ancestor also have Symbolic Object as an ancestor.

Revise charter per edits in the following charter document v1.1:
https://docs.google.com/document/d/1OCvy8x9TGQJ1wyOzIPKO_HjfgS5vWk-wEop1ze_LC3w/edit

And comment on combining sections 4.1.2 & 4.1.3 and adding more information on how to participate.

Person branch as discussed during May 2018 meetings. Branch JSON to follow.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Model to represent textual works that are potentially carried by multiple objects. Sketch to come.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Vote on the adoption of the Arches Resource Model Working Group Charter:
https://docs.google.com/document/d/1OCvy8x9TGQJ1wyOzIPKO_HjfgS5vWk-wEop1ze_LC3w/edit

As a reminder, please vote as follows:
+1 - Yes/Agree
0 - Neutral
-1 - No/Disagree

If you are a -1, please state why and we can address this at the next meeting.

Branch/Resource Model for Activity as discussed during May 2018 meetings. JSON pending.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Name Branch (Partitioned)

For documentation on Name Branch (Simple), see issue #13

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

File: /branches/name/8_linkedart_Personal-Name_20150215.json

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

We discussed two versions of this: one using the EDTF data type in Arches and the other using XSD. I don't have a photo of the sketch on this (just my notes), so if someone has it, please upload the sketch photo.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

For discussion of options regarding a short-term/initial repository for the content that the ARM WG creates.

https://docs.google.com/document/d/1OOmBdZVTlhHpEp6Czt5Mw66pgPQtaBwkk3XWXlrbq74/edit

Hey Everyone...
I wanted to point out in an issue here that, in order to implement our models and branches as designed, you need to load the two ontology extensions contained in the zip file on this issue.

https://app.zenhub.com/files/119609623/1522488b-1a77-4561-9f80-d69f63a6c58c/download

Documentation on loading ontology here: https://arches.readthedocs.io/en/stable/command-line-reference/?highlight=ontology#ontology-commands

This how a successful load on my machine looks:

(ENV) Adams-MBP:sfport adamlodge$ python manage.py load_ontology  -x /Users/adamlodge/Desktop/linkedart_crm_enhancements.xml -vn 1
Select the number corresponding to the
base ontology to which you want to add the extension.
1. CIDOC CRM v6.2 (e6e8db47-2ccf-11e6-927e-b8f6b115d7dd)
1

Loading Source Ontology: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/cidoc_crm_v6.2.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMinf_v0.7.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMsci_v1.2.3.rdfs.xml"
Loading Extension: "/Users/adamlodge/Desktop/linkedart_crm_enhancements.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMdig_v3.2.1.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/arches_crm_enhancements.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMarchaeo_v1.4.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMgeo_v1.2.rdfs.xml"
(ENV) Adams-MBP:sfport adamlodge$ python manage.py load_ontology  -x /Users/adamlodge/Downloads/linkedart.xml -vn 1
Select the number corresponding to the
base ontology to which you want to add the extension.
1. CIDOC CRM v6.2 (e6e8db47-2ccf-11e6-927e-b8f6b115d7dd)
1

Loading Source Ontology: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/cidoc_crm_v6.2.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMinf_v0.7.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMsci_v1.2.3.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMdig_v3.2.1.rdfs.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/linkedart_crm_enhancements.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/arches_crm_enhancements.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMarchaeo_v1.4.rdfs.xml"
Loading Extension: "/Users/adamlodge/Downloads/linkedart.xml"
Loading Extension: "/Users/adamlodge/repos/arches/arches/db/ontologies/cidoc_crm/CRMgeo_v1.2.rdfs.xml"
(ENV) Adams-MBP:sfport adamlodge$ ```

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

Will fill out later....

We should have a consistent style guide for graph diagrams for models.

In particular:

• Resource / Node
• Class
• Literal value
• Relationship
• Data type
• External vs internal node
• labels for relationships

Nice to have:

• color / style guide for different classes or group of classes (e.g. appellation, contact point, identifier, name in my diagrams are light blue, whereas places are brown)

Right now, capitalization is a mixed bag within the graphs we have developed / are developing. We should define a standard of what different flavors of capitalization mean (mixed case, lowercase, etc) and consistently apply those standards to our node naming.

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

See the "Metadata 4 Branch" tab in the following document for the proposed branch metadata as presented and discussed in the April 5 meeting:
https://docs.google.com/spreadsheets/d/1mqRtHiZAD_ET73XDWfiwRhJrCMiyU0nJp_biXLMISns/edit#gid=539583974

The metadata is both for branch information and discoverability on the eventual repository.

Please add any comments/suggestions/questions regarding the proposed branch metadata here. Note that the branch metadata will likely inform the metadata for resource models and packages, but is not necessarily the same.

https://docs.google.com/document/d/1OOmBdZVTlhHpEp6Czt5Mw66pgPQtaBwkk3XWXlrbq74/edit

Basic Location Branch (see #15 for full notes on Location Model)

Steps to completion (updated):

• Metadata
• Diagram (using ARM WG notation)
• Sample Data
• Sample Concepts
• JSON of Arches branch based on diagram in ARM WG github repo
• Vote in comments to officially approve branch

We need to define what the process and mechanism for reviewing submitted models/branches.