alanruttenberg
commented
17 hours ago Bump: This has been in the works for a long time. Could people please weigh in so we can finally get this done?
Open alanruttenberg opened 1 week ago
alanruttenberg
commented
17 hours ago Bump: This has been in the works for a long time. Could people please weigh in so we can finally get this done?
swartik
commented
16 hours ago @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:
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.
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
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_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.