[Crm-sig] CIDOC CRM URI management

Athanasios Velios thanasis at softicon.co.uk
Fri Jan 17 15:38:52 EET 2020

Yes, if we have different URIs for each version of E5 Event, then this 
will complicate matters during implementation in local systems. If one 
wants to work out the difference in reasoning rules across the versions 
then they would need to refer to the whole document not each individual 
class. So yes to versions for the document URIs but no to versions for 
the individual class URIs.


On 17/01/2020 13:05, George Bruseker wrote:
>      >      > 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.
> But is your objection to showing the data in the form that you see when 
> you click this link (ie not a large html text and a pointer to the 
> anchor) or to showing a version?
> I like the way that the link above displays an individual class and the 
> functionality it gives to actually use the ontology. I don't know if it 
> breaks good practice though.
> Re displaying a version, don't you always have to display a version? 
> Even if you are displaying current, it is actually just the last 
> official version.
>      > 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.
> I think from a provenance point of view, given that the ontology is 
> changing if one knew the version it could help one interpret the 
> information in the future. I mean that if you made your data under 
> version 4 when the intension of class x was of a certain size and now we 
> widened it, then perhaps it affects how you used the ontology. I imagine 
> this is a pretty sci fi scenario right now and nobody has this use case, 
> but thinking of how things could shape up in a future world, I think it 
> would be relevant. Actually even thinking about conversations in 
> LinkedArt people get confused between versions. Why didn't you use 
> property x? Well I was looking at version x and in that version class y 
> doesn't have property x.
> Anyhow if we had a workflow in which the structured data for classes and 
> properties were edited first and from that the different products (doc, 
> rdf, owl etc.) were generated then generating the versioned version 
> would not be more overheard. Think it's a question of order of 
> production of the documents.

More information about the Crm-sig mailing list