My 1st Post to the #cidocCRM SIG Mailing List

Today I felt bold or desperate enough -- actually some of both -- to prod a bit for a reply to a request for advice from a couple of my mentors in my #cidocCRM/#TEI Personal Learning Network. If you are successful developing a really good #PLNet (might as well mint a hashtag for on-going use), your loose group of mentors will, by definition, be EXTREMELY busy beyond your imagining, and the best won't suffer fools lightly. So evolving your #PLNet is always a balancing act.

Thoughts on CIDOC-CRM Classes: "Oops, who put all this Time Stuff in my Box of Things!?"

I am using the CIDOC-CRM – the Conceptual Reference Model developed by the International Council of Museums – as the primary domain reference model guiding design and development of the FactMiners social-game platform. In a recent post I looked at the Conceptual Reference Model from a "pure graph" perspective, re-imagining the CRM's Property Declarations as "just another" labeled subset of model elements, that is, as just another important subset of CRM Classes. In this post, I explore the "entity-ness" of the CIDOC-CRM Class Declarations.

Thoughts on a Graph Representation of the CIDOC-CRM: Property Declarations

I am having an interesting time looking at the CIDOC-CRM – the Conceptual Reference Model for museums developed by the International Council of Museums (ICOM). In particular, as generally described in my last post, I am looking at the CIDOC-CRM with a "pure graph" lens on a metamodel developed with an object-oriented perspective. In this post, I take a closer look at what "node-ifying" the CIDOC-CRM Property Declarations would look like and why this is a potentially powerful idea.

On "Node-ifying" Relations in a Neo4j Graph Database of the CIDOC-CRM

One aspect of the metamodel subgraph design pattern we are using for the FactMiners Fact Cloud is a graph transformation that can be viewed as "node-ifying" a relationship. That is, if our source database has a relationship, we model the relationship as a node in the metamodel so we can more fully model the relationship. In this post I explore an aspect of the UI view of such an approach and wonder if Structr and KeyLines could be used to create an intuitive and easy-to-use visualization of such a dynamic graph transformation at the view level. My particular interest here is use this design pattern to create a Neo4j-based exploratory viewer on the CIDOC-CRM.

CIDOC-CRM Meet METS/ALTO - A Recipe for FactMiners 'Fact Clouds'

FactMiners.org is very pleased to announce that we are adopting METS/ALTO as the "drill down" metadata and file/data format specifications that will guide our DSL (Domain Specific Language) extensions of the CIDOC-CRM as part of the design of the Open Source FactMiners LAM-based social-game platform.

FactMiners Fact Clouds to be CIDOC-CRM Compliant

FactMiners.org is pleased to announce adoption of the Conceptual Reference Model (CRM) of the International Committee for Documentation (CIDOC) of the International Council of Museums (ICOM). The CIDOC-CRM is an 'ontology' for cultural heritage information, in other words it describes in a formal language the concepts and relations relevant to the documentation of cultural heritage. This ISO standard will be used as the reference model for the development of the FactMiners Fact Cloud metamodel that will logically organize the 'facts' to be 'mined' out of our initial project — the digital archive of Softalk magazine — respecting both the elements of its editorial content and the complex document structure of a magazine.