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