Here are the annotated guidelines that we came up with over about 10 years of trying different styles across several projects.
- Colored ovals for resources, with the URI slug within the oval. The color is an indication of the sort of resource, but is not the only source of the information (re color blindness) Ovals are important because they give enough space to have text within them, without taking up too much vertical space. Also enough room to have multiple lines leading in and out. Colors are important for most people to see patterns, but need to be careful of accessibility. - Boxes for classes. But not everything should be boxes, or it looks very square and blocky. The distinction between class and instance is important, and easy to see with this. - Lozenges for literals. Put strings in ""s inside the lozenge to distinguish from numbers, dates, etc. Lozenge has enough horizontal space, without looking like a stretched class. - Black lines with arrows between shapes to establish the connections, with labels centered on or above the line. Obviously. - Able to be generated and laid out automatically in a non-terrible way When you have a lot of diagrams, this becomes important! We tried having hollow arrow heads for type and filled arrow heads for other properties, but the distinction is clearer with the class being a box so we removed it. We never ran into a need for colored lines or line labels, as the colors are too subtle to distinguish, so black is better for a11y. The colors of the ovals should be consistent. We've tried to align across a few projects now: Time: blue Actor: red Conceptual: yellow Physical: brown Place: green Data: grey Digital: Purple Class box: white Examples: https://linked.art/model/base/#names-and-identifiers-for-a-resource (Scroll down a little past the JSON -- this is generated automatically from the RDF) https://linked.art/api/1.0/endpoint/place/#property-diagram (This is generated by hand in Omnigraffle) You can see the evolution of this: First: http://openarchives.org/ore/1.0/datamodel#Metadata_about_the_ReM Evolved to: http://www.openannotation.org/documents/CNI_Dec-OAC_Handout.pdf Evolved to: http://openannotation.org/spec/beta/ Evolved to: https://www.w3.org/TR/annotation-vocab/#datapositionselector Evolved to the above. HTH Rob On Wed, Jul 8, 2020 at 6:49 AM George Bruseker <george.bruse...@gmail.com> wrote: > Dear all, > > In the context of Issue 457 > > > http://www.cidoc-crm.org/Issue/ID-457-harmonization-of-graphical-documentation-about-crm > > We are looking to create style guides for the CRM SIG on how to formulate > the diagrams that will go in the documentation (e.g. publication of the > standard, web publications etc.). The goal is to create consistent looking > documentation that is easily accessible to the CIDOC CRM audience (domain > specialists, developers, ontological modellers etc.) This would be an > effort to both create a clean and consistent look for the representations, > to lower barriers to understanding/adopting CRM, and to more efficiently > produce this documentation. > > Currently we are looking to put together proposals on the possible > parameters of the style guide, such as which kinds of arrows to use for > general properties, for IsA property, which kinds of boxes/bubbles to use > for classes and instances etc. > > If you have best practice in mind that should be taken into account, can > you please share to the list. We will take on board what is shared and make > a proposal of different possibilities for voting on by the SIG membership. > > All best, > > George > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Rob Sanderson
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
