Whatis.com states that "an ontology is the working model of entities and interactions in some particular domain of knowledge or practices."
In which case, an ontology sounds more like a metamodel, which Zachman is not.
In Zachman's table the interactions between the elements/cells that would define an ontology are missing.
Furthermore, the cells are not entities in the EA domain of practice since the matrix is neither enterprise nor architecture specific. It can apply to any system. And solely one row is in fact, about architecture. The cells are artifacts themselves, composites of such entities.
As such, Zachman's is not an ontology because it describes neither the entities of the knowledge domain nor their relationships.
Zachman' s is not a framework either.
Here is what Whatis.com writes about frameworks:
"A framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful"
Hence, Zachman's is not a framework because it does not represent the structure of the enterprise or its architecture. Putting the artifacts in cells, back in the "framework", does not constitute an integrated EA but still a table of disjoint set of enterprise representations.
Zachman's is a simple veiled process though. The vertical dimension describes the system development process beginning with objectives establishment and concept design and ending with Implementation.
The process is described by either deliverables (the business model, the logical, physical...) and/or by phase owners (planner, business owner, architect, designer...) rather than by process phases.
Were we to describe the process the following phases would be evidenced: objectives specification (row 1), concept definition (row 2), logical design (row 3), technology design (row 4), implementation (row 5) (and eventually utilisation (row 6) or I would say deployment).
It is uncommon too that each phase is executed by a different participant or firm. The process would be often executed end-to-end by the same entity. In this case repeating questions like why, who... etc for each phase of the development makes little sense. Why should one ask the why question again and again, once the business case for the development has been already established in a previous phase?
To sum up, Zachman's looks to me like a straightforward system development process specified on the vertical dimension of the matrix by its deliverables and/or owners of the phase.
The "w" questions that help justify and qualify the activities in each phase, make sense once only for the whole development process, rather than repeated for each phase, at least because the owner of the phase does not change.
In any case, the EA architect is not responsible or accountable for all the activities in phases. Take for instance the planer's, the contractors' rows... But the architect should be clearly in charge of the architecture, logical/system phase (=row).
You cannot track an end-to-end process in Zachman's table. You cannot navigate to the resources that implement it.
I solely use Zachman's to market EA to top management who needs to ask questions like why, who... at each phase of a major development. That is because they have responsibility for the whole outcome to ensure that it is fit for purpose, delivered in time by participants and resourced accordingly.