Proposal: IBA/IBE/ICE refactor

[alanruttenberg]

Here is the outline of what I would change. I'll rewrite definitions if there is consensus that these are the changes to make. There are further changes I would make, adding axioms and additional classes, but this is the bare minimum.

IBAs that make more sense as ICEs

• Barcode and subclasses
• Book
• Certificate
• Database
• Document
• Image, Chart
• Information line (unless you are talking about things like the touch bar on a macbook)
• Journal article
• List, Code List
• Message and subclasses
• Spreadsheet
• Video

Rearrangements:

Book, Journal article to be subclass of Document. I'm unsure whether
spreadsheet should also be but lean that way. Document, I think, connotes a whole. Images
and Charts may be documents, but also may be only parts of documents.

Rename

Document Form -> Form Document. The label makes it sound like a part of document.

Material artifacts

Some of the above are sometimes interesting as physical items, things
you would track copies of.

Book Artifact: Material artifact and is carrier of some Book
Document Artifact : Material artifact and is carrier of some Document

An alternative would not to define them and just have material
artifact instances and relate them to what they carry, in the RDF.

remaining IBA classes

Timekeeping Instrument with subclass System Clock, Instrument Display
Panel, seem to me to be Information Medium Artifacts.

IBE

Document Field: Move to ICE. Add axiom: continuant part of some Document

Deprecate IBA.

The distinction between IBE and IBA is minor and IBE is more general. It's arguable whether
a tree with a carving "A heart L" is an IBA, but it is clearly an IBE.

Properties whose domains or range is IBE

Deprecate the 'has value' properties like 'has text value' in
favor of a single 'has value' property. That would include all data
properties other than: 'has latitude value', 'has longitude value', and
'as WKT'. The typing of the relation is unecessary - the type information is available from the value, and restrictions could be added to constrain types where relevant.

In the below relations, change IBE to ICE in domain or range

• is excerpted from (both). Consider Document as D/R, else ICE, but I think that too broad.
• is geospatial coordinate reference system of, uses geospatial coordinate system
• is measurment unit of, uses measurement unit.
• is reference system of, uses reference system
• language used in, uses language
• time zone identifier used by, uses time zone identifier

is_tokenized_by

Deprecate and suggest has value instead.

Logistics

The proper thing to do is to deprecate old terms and create new terms
where there is a significant change, like IBA->ICE. The alternative is
to keep using the same IRIs, but this risks cases where domain
ontologies have specialized below the top-level classes. So specializing
Document will be fine in the switch, because a subclass of Document will
remain a subclass of Document in the switch. However, if a new direct
subclass of IBA is created, that won't move, as the proposal does not
include equating ICE with the old IBE.

For rearrangements, such as putting Book and Journal article below
Document, the potential damage is less, and in such cases the terms do
not need to be deprecated.

There will be a mapping file from english name IRIs to numeric IRIs. I'd
suggest that the old classes not be included in that mapping, but a
supplementary information mapping that maps deprecated terms to
alternatives be included as an adjunct.