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.
T.
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.
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
