C4L Diagram Drafts

[seanpetiya]

Below is my offering and first attempt at a diagram building on @philbarker's Venn diagram idea from our meeting on 12/18.

This diagram uses a legend (squares and circles) to illustrate the distinction between resources (data, records, etc.) and types (classes, concepts, etc.).

There are two views presented: 1) a resource (WEM) belonging to one or more types (and hopefully other possible overlaps WE + M, W + EM, etc.) , and 2) an expanded view showing distinct resources and their relationships (W + E + M + I). Not sure if the crow's feet are correct... (one or many for all?)

[kcoyle]

Here are the links to the comments that Johannes Busse presented to us:
https://www.jbusse.de/lovs/dcmi-openwemi.html
https://www.jbusse.de/lovs/rdfs-range-bunny-carrot.html

His comments about the ranges tend to focus on the impact of the "OR"d ranges on inferencing, and he is correct that using the ranges defined in OpenWEMI, the triples that inferencing returns are hardly useful. He also pointed out to us that our diagrams do not reflect the TTL or the text.

Our intention was not to support inferencing on OpenWEMI but to allow the development of subproperties that are narrower in scope than OpenWEMI properties. There isn't another way to express this in RDFS except with a union of classes. (I'm thinking of trying to create a DCTAP for OpenWEMI - because RDF doesn't allow you to describe "rules" for your metadata schema.)

[kcoyle]

OK, I did this based on what Sean and Phil came up with. It still needs some finessing. I liked the hashes that Sean used but I don't know if they'll get lost when the diagram is reduced in size (and on small screens when reading online). I'm happy to take Sean's advice on that since he knows better.

[seanpetiya]

Here's a version of @kcoyle's diagram with less space between the hatches. This should work at smaller sizes, just have to work on the labels if we do not want to use abbreviations for the classes.

Also, not sure if we want to include a diagram for commonX/relatedX, but something like the figure below might work at the end?