[Crm-sig] CIDOC CRM URI management

Francesco Beretta francesco.beretta at cnrs.fr
Fri Jan 17 14:27:55 EET 2020


Dear all,

This very interesting conversation was up to now focusing on CRMbase. 
But what about the extensions family ? Often pointing from one extension 
to antoher ?

One major point for having machine actionable, consistent ontologies is 
to have a mechanism to point to the versions of each module (and base) 
to which a certain module version refers. This, as you know, to provide 
consistency.

One of the reasons for developing OntoME <ontome.dataforhistory.org/> 
was to provide a way of easily integrating different modules and 
extensions. We added recently the possibility of having a rdf-owl export 
of a namespace and more will follow soon, I hope, to export profiles in 
OWL and probably soon SHACL.

The general vision for OntoME is to go from beta to MVP in summer, and 
at the same time go opensource so that the community can help improve 
the platform. And also integrate it, if desirable and desired, with the 
tooling at FORTH or any other platform.

I think we should discuss on a vision and rules for providing a robust, 
machine actionable integration of CRMbase and modules in general (i.e. 
platform independent). And to develop a commun platform providing 
versions integration and easy to use tooling for the community.

I raise this issue because I've heard expressing this need in the user 
community multiple times, and I wonder in which direction we should 
move, and I know developing such platforms is time-consuming, expensive 
and and causes headaches...

All the best

Francesco



Le 17.01.20 à 12:44, Athanasios Velios a écrit :
>
>> My underlying assumption would be that the default thing served up 
>> would be html, but you could reach the other representation 
>> consistently through adding an appropriate ending or whatever would 
>> be most suitable... but that people looking at the html should have a 
>> shiny red button type clue that there is another way to retrieve the 
>> info which is for example as owl.
>
> Yes, I agree.
>
>>      > I will point out that on the CRM site, there is also an entire
>>      > architecture wherein each version has its own overall 
>> presentation:
>>      > e.g.: http://www.cidoc-crm.org/Version/version-6.2.1
>>
>>     I think this should be maintained but not used as URIs for classes.
>>
>>
>> Why would you argue against using it as the resolving point for 
>> individual classes?
>
> Because it includes versions. These are necessary when working across 
> different versions but I do not think versions are needed for classes.
>
>> Currently this is not supported at all, correct? I mean you always 
>> point at a version. So you would suggest that 'current' should be 
>> 'versionless'?
>
> I am suggesting that classes do not need versions at all. Doing 
> reasoning on a per class and per version basis would be bad practice, 
> no? One would expect that the whole RDF/OWL representation would be 
> used for reasoning. I think class URIs are only used as identifiers. 
> This also avoids the problem of ensuring correct older versions for 
> deprecated classes.
>
>>
>> How I understood Erlangen to work is that it just makes the 
>> versionless URI redirect to the current. So I thought the idea would 
>> be that 'current' resolves to the present official (whatever the 
>> present official means). If a class has been deprecated then I guess 
>> it would have to revert to the last official in which it had existed?
>>
>>
>>     All the best,
>>
>>     Thanasis
>>
>>
>>     _______________________________________________
>>     Crm-sig mailing list
>>     Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
>>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20200117/5dd5e6d2/attachment-0001.html>


More information about the Crm-sig mailing list