Should/Will ECRM implement CIDOC CRM drafts?

11 views
Skip to first unread message

Martin Scholz

unread,
Feb 10, 2014, 11:08:15 AM2/10/14
to erlangen-crm
Hi,

The latest drafts of the CIDOC CRM introduce some new constructs that we and maybe other ECRM users would like to use.

Till now, ECRM did only implement official versions of CIDOC CRM, but not drafts.

However, the last official release is two years old and there does not seem to be a date for the next official release. So it may be time to revise the strategy and introduce the innovations of the drafts into ECRM.

What do you as (potential) ECRM users think?
Is there a need for an ECRM implementation of CIDOC CRM 5.1 or 5.1.2 or drafts in general?

If so, some questions arise:
1) What classes and properties should be implemented? All or only some? What criteria should be applied?
2) How should be dealt with incomplete information? E.g. some domain, range, superpropertys and superclass information is missing or unclear
3) What status does such a version have? As this mainly depends on the CRM draft status, I think this boils down to what namespace should be used. Should there be a current-unstable beneath the current one?

Regarding these questions, I propose
1) to only implement new constructs of a draft if a user need for these constructs arises. In the best case, users would contribute the amendments they need. Lately, the ECRM development moved to github <https://github.com/erlangen-crm/ecrm>, so participation should be rather easy and transparent.
2) to be conservative with missing information. If a piece of information, however, can be clearly inferred from scope note or superclass/property, it may be added. (See also the discussion on transitive properties.) I think, the aim should be to minimize the amount of work for updating datasets to the next normal version.
3) that draft versions should be separated from normal ones. A draft version should not update the current namespace. In github, releases are marked with tags, eg. CIDOC-CRMv5.0.4 <https://github.com/erlangen-crm/ecrm/tree/CIDOC-CRMv5.0.4> for the ECRM implementing the resp. CRM version. A draft could be marked with a tag like CIDOC-CRM-DRAFTv5.1.2.

Comments welcome :)

Martin Scholz




Vladimir Alexiev

unread,
Feb 13, 2014, 2:13:17 PM2/13/14
to erlang...@googlegroups.com
>Is there a need for an ECRM implementation of CIDOC CRM 5.1 or 5.1.2 or drafts in general?

I think so. Not necessarily all, but those that seem “major releases”.
There was a recent discussion on the CRM list about the “draft” status of 5.1; maybe it can inform this discussion

> 1) What classes and properties should be implemented? All or only some?

ALL (or none ;-). Else uncertainty will result.

>2) How should be dealt with incomplete information?
>2) to be conservative with missing information.
> If a piece of information, however, can be clearly inferred from scope note or superclass/property, it may be added

Sounds reasonable.

> In github, releases are marked with tags, <https://github.com/erlangen-crm/ecrm/tree/CIDOC-CRMv5.0.4>

Following LOD publication principles (and COOLURIs), Ontologies must resolve at the namespace URI.
The version should be in the URI.
So: are you prepared to use the above github URL as namespace URI?
Maybe google "github ontology versions" can provide some advice...

I think it's extremely important to have the latest version (draft or not) at a fixed location (ecrm.owl) and with fixed namespace (/current/).
Else you'll make people having to migrate URLs in knowledge bases, which is a huge pain.

Also, my scripts work on /current so I made ecrm-140212.owl vs ecrm.owl in github.

Cheers! V

Note: I prefer ecrm-5.1 instead of ecrm-140212 .
It doesn’t matter when an ECRM version was made, it matters which CRM version it was based upon.



Reply all
Reply to author
Forward
0 new messages