Proposal: IBA/IBE/ICE refactor
Opened this issue · 2 comments
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.
Bump: This has been in the works for a long time. Could people please weigh in so we can finally get this done?
@alanruttenberg I agree with most of your proposal. I'm not convinced about barcodes. Barcode subclasses do seem to be more about standards than about material artifacts. However, someone went to the trouble to add them to CCO, presumably because they thought that level of detail would be useful. Class Code 93 Barcode has its uses as formulated. Members of the class are individuals that conform to the Code 93 standard. Formalizing that standard as a subclass of Directive Information Content Entity is also useful, but I'm not prepared to advocate for eliminating the class hierarchy under material artifact as well. I would:
- Keep class Barcode where it is.
- Create a hierarchy under Directive Information Content Entity, using labels like "Codabar Barcode Specification".
In the course of composing this reply, I've begun to wonder why CCO has this much detail on barcodes. Can anyone supply some history? I would be open to moving subclasses of Barcode to a separate module.