Come up with graph diagram style guide

[azaroth42]

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)

[azaroth42]

The style that I use:

• Resource: colored ellipse
• Class: white rectangle
• Literal: white lozenge
• Relationship: black, filled single head, arrow
• Data type: ... not represented
• External/Internal: ... not represented
• Labels: Black text over or on top of relationship arrow, or within the ellipse

Colors I use:

[Habennin]

In my diagram representations I use the following colour scheme:

E2 Temporal Entity: Blue
E39: Pink
E28: Yellow
E18: Physical Thing
E53: Green

The colour choice is arbitrary, but the classes selected because they form the most important ontological divisions in CRM. I used to divide out Name and Type two with a different colour but then I thought it was confusing because they are just E28s. Another solution I thought of was a different shade? The argument for a different colour for them I guess being that they occur a lot?

Anyhow, I'm not doctrinaire about the actual colour choice, but I think there is a substance conversation on what part of the hierarchy to pick out with one colour and then what to do with sub parts of that same hierarchy if you wish to give a different colour without suggesting it is not part of that branch.

What is your standard means for representing isA? just a different style of arrow?

[azaroth42]

I also don't care about the color of the bikeshed, versus the main reactor. I would have E55 and E41 / la:Name as distinct because they serve different purposes in the branches and they occur a lot.

And yes, I use an outline arrow for rdf:type / isA, but it's also clear from the rectangle for the class.
I don't represent subClassOf / subPropertyOf in the same diagrams as instance level stuff, but have used dashed lines for them in other diagrams.

[adamlodge]

From a purely Arches requirements perspective, this is the minimum of what an Arches implementor needs to know in order to translate a diagram into a an Arches graph:

Each node in the diagram should represent one of the following things:

• A: a node in the branch being described
• B: an external ARM branch
• C: an external ARM resource model

Each node of type A (above) in the diagram should communication the following information:

• Ontology class of the node
• Data type of the node
• Name of the node (as it will be named in the graph, not the card)

Each relationship between nodes in the diagram should:

• Be captured as a directional line between two nodes
• Show the (CRM) property of the relationship

[azaroth42]

For the shape of the nodes, we started out with circles, but the ellipse shape makes it easier to have more text inside the shape. Ellipse rather than square makes it prettier for many relationships expanding out from a single node.

I agree with George that parts of the hierarchy should have different colors, with different parts being as different as possible -- e.g. Place and MMO and Type should be very different, Name and Identifier should be similar. Happy to recolor my nodes.

[azaroth42]

The current state of my JSON to diagram automation using OmniGraffle:
Given https://linked.art/example/object/60.json, it generates:

There are some obvious, easy additional fixes on my to-do list:

• Make classified_as / p2_has_type refer to a Type node, not a literal
• Align the top level node's class with all the way left
• Reorder the branches such that the deepest branch is in the middle, to make the best use of the available space (otherwise they end up in a diagonal line from top left to bottom right with lots of whitespace)
• Provide an alternative view that uses the RDF labels rather than the JSON-LD context labels
• Add in Arches specific details such as the internal data type

[dwuthrich]

A note about use of color: color-blind people may be at a disadvantage when working with color-encoded diagrams. Distinguishing between shades of red and green can be particularly problematic. I'm not opposed to using colors to help people recognize our hierarchy, but we should make it easy for color blind people to interpret the hierarchy without relying solely on our color-coding.

[azaroth42]

👍 Colors should help but not be essential for interpretation.

Ideas for expressing data typing:

• Semantic node: Ellipse with single stroke line.
• [External to current model] Resource-Instance: Ellipse with double stroke line.
• String: lozenge with "quoted text"
• Number: lozenge with number value, not quoted
• Date: lozenge with unquoted date ?
• RDM Concept: I think all Types will be RDM managed, so this could be just the Type node as above (black double stroke line on a white ellipse) ?

[annabelleee]

As discussed during August meetings:

Shapes
Ellipse - node
Diamond - type
Double-line ellipse - resource-instance
Lozenge - literal
Magic Lozenge - geo-json/file-list

Colors
Brown (FF9A69) - Physical Thing
Yellow (FFFF26) - Names, Identifiers, Appellations
Orange (FFAA00) - E55 and below
Pink (ffcce6) - Actor
Blue (0000e6)- Temporal Event E2 and below
Green (006600) - Place
Lavender (b3b3ff)- Dimension
Robin’s Egg Blue (80bfff0)- Time-Span
Red (e60000)- Rights, Property Interests

[annabelleee]

During the 9/19 call, GTB mentioned that RS and Nicola Carboni came up with a slightly different scheme during a SIG meeting, and there was a decision to harmonize with this scheme. Here's is a draft legend using the latest scheme for review during the 9/26 call:

Here are the colors used:

Information Object | #FDDC34
Physical Thing | #E1BA9C
Place | #94CC7D
Right | #CAB5EB
Activity | #82C3EC
Timespan | #DDFFFE
Actor | #FFBDCA
Appellation | #FEF3BA
Type | #FAB565
Dimension | #E6E4EC

[annabelleee]

Updated to replace Right with Digital Object: