In message <25DCE13B-7EB9-44E7-957D-38E7D8195CF1@...>,
Sebastian Rahtz <sebastian.rahtz@...> writes
>the material i presented today at the SIG meeting is up at
>I'll be doing more work on this on the SIG site, I expect, so this is
>just a snapshot
Interestingly, I'm producing very analogous CRM in the context of
SKOSifying an artist authority file. Looking at your RDF pointed out
some properties and classes I had missed, so thanks for that.
More generally, I am wondering if it would be useful to agree and
publish some design patterns for the use of CRM to encode core
properties of say people, places, events and named periods? If other
implementers could just pick up a standard structural template and drop
their data into it, our combined RDF resources would respond much better
when dropped into a triple store vat and stirred vigorously. There are
so many ways to use the CRM, even if you're using it correctly ...
(Previously, perhaps influenced by the seductive simplicity of e.g.
dbpedia, I have dismissed the CRM as being to verbose for use in Linked
Data RDF. But then, once you realise how little a simplistic list of
assertions lets you say about historical events, it becomes clear that
you need something more richly-structured. Also, if you can use URLs to
refer to related entities, the structure becomes quite manageable.)