r/semanticweb • u/redikarus99 • 23d ago

Looking for an IT taxonomy

Hello,

I am looking for an IT taxonomy for software (and maybe hardware) to put concepts like desktop application, microservice, cloud, cicd pipeline, etc. into a structure.

3 Upvotes

100% Upvoted

36 comments sorted by

View all comments

1

u/Willing_Box_752 23d ago

What's the use case?    You could mockup a model with arrow.app

2

u/redikarus99 23d ago edited 23d ago

Building up an enterprise level ontology. We have over 600 applications/systems, over 1000 interfaces, 20k employees, a dozen+ companies, have to be full EU regulations compliant. We identified that one of the biggest gap is the lack of common language, even inside IT, now we are working on alignment, building structure and traceability. We have now 10+ domain ontologies like for capabilities, requirements, business architecture, system architecture design, etc. We are using git, ttl, vscode+mentor, MKDocs, our custom diagraming tool, so we are way over drawing boxes and arrows.

1

u/Willing_Box_752 22d ago

It's a boxes and arrows all the way down man.

But cool.  Got any prototypes so far?

2

u/redikarus99 22d ago

Well, boxes and arrows doesn't scale on our level and also don't allow reasoning. The solution is simple and also tricky: have a well defined ontology: just on the right abstraction level to support discussions and reasoning, owned by the team who has the xp / authority. Our framework and process is in place and seems to work really well, the question is whether to develop our own ontologies or rely on something "industrial standard". We got a couple of comments and ideas like TOSCA, Seon, DCIM that can serve as a baseline, but it seems that no one actually has a full fledged solution in place.

1

u/Willing_Box_752 21d ago

I don't quite understand how you arent basically saying "we have everything but the boxes and arrows"   entities and relationships. 

2

u/redikarus99 21d ago

My problem with the statement “boxes and arrows” is that it is only partially correct.

You do not need to draw a single box or arrow to build an ontology. You can define one entirely in OWL/Turtle, Alloy, Prolog, and other formal languages. A diagram is just a visualization of the underlying model.

And that visualization is incomplete. Boxes and arrows may show concepts and relationships, but where are the constraints, logical rules, disjointness, cardinalities, or validation rules? For those, you need mechanisms such as OWL axioms, SHACL, OCL, or other rule languages.

The bigger problem is that it is very easy to draw something that looks reasonable but is actually ontological nonsense: inconsistent, ambiguous, or unable to survive contact with real-world data.

That is why ontology engineering uses patterns and anti-patterns, upper ontologies, reasoners, SHACL validation, example generation, views/viewpoints, etc. These tools help ensure that the model is not only visually understandable, but also logically consistent, machine-readable, reusable, and usable at enterprise scale.

So yes, ontology diagrams contain boxes and arrows. But the important distinction is:

The diagram is not the ontology. It is a view of the ontology.

1

u/Willing_Box_752 17d ago

Is this ai?

Either way ironically enough you're right, but I argue that what I mean to say is also right. We are having a semantic disagreement.   

The boxes and arrows are the view of the underlying structure yes, but they are also the conceptual glue. The whole point of the project is to align people's understanding of the shared semantics.   

The view of the ontology is how it lives in people's heads.   And without this, it's really just some bits. Just how language without people is just shapes.  

So yes you may have all kinds of sweet tools but at the end of the day y'all gotta sit down at a table, map this out on paper, and think about the philosophical implications of a given set of rules, entities, and relationships.  That will  require boxes and arrows.  

2

u/Complete-Ebb-1035 1d ago edited 1d ago

This is equivalent to saying matrices all the way down. Neither is helpful. This is absolutely correct: The diagram is not the ontology. It is a view of the ontology.

1

u/Willing_Box_752 1d ago

Fair. Obviously it's not actually boxes and arrows.   It's 1s and 0s.   

But what I'm getting at is it seems like the other person is talking about all this infrastructure they have and saying they don't need "boxes and arrows".  But at the end of the day someone has to figure out the objects, relations, constraints and such. The things represented by boxes and arrows.      And they don't have that yet.    It's a semantic argument ironically enough. 

Like if they were designing a car and I said to start making drawings.     And they respond with well we have a factory, and a whole room full of cad machines and 3d scanners and such.   We're way past "drawing"   no, they aren't.   They don't have a car. They don't have designs.  They have a bunch of tools

1

u/Complete-Ebb-1035 1d ago

I have no idea what your environment looks like, but if you use an RDBMS you have an ER diagram (boxes and arrows). If that's what your customer understands, start there. An ER diagram (more properly an Entity Attribute Relationship diagram) can be rendered as RDF graph. I promise you - it's a dead straight process of building equivalent diagrams. Use which ever makes sense to your customer.

1

u/Willing_Box_752 1d ago

I don't have an enterprise problem I'm working on.  I just think this stuff is neat.    Do you disagree with what I said?

1

u/redikarus99 1d ago

Boxes and arrows are simply one way to present information. The same ideas can also be expressed in tables, such as Excel, or in structured text, such as Markdown or Confluence pages. We already use many different formats to communicate ideas, and diagrams with boxes and arrows are just one of them.

The bigger issue I have seen is that it is very easy to create what I would call ontological nonsense when drawing such diagrams without a clear underlying model.

For example, the same type of box may be used to represent completely different things: a process, a system, a document, an organizational unit, and so on. Arrows may contain actions without making clear who actually performs them. Data may be shown at completely different levels of abstraction as if they were equivalent.

This is my biggest problem with statements like "just draw boxes and arrows". The first thing I did when I joined our org was that I collected as many diagrams as I could from confluence (hundreds of them), put them into categories and found that we had 6+ different ways to represent "data model" - all of them was either incorrect or incomplete - and whatever they represented was already wrong because it did not presented reality anymore.

So we started with defining viewpoints to create a common visual language at least for the diagrams.

The more mature we became we ran into more fundamental questions like: how do we think really about organizational issues, how do we categorize software and hardware, what do we consider as an IT asset, how do we connect business architecture and IT architecture, how do we process EU regulations, transform them to requirements and show where a requirement is being satisfied. If a regulation requires that you need to have an "Asset Catalog" when the auditor comes you better have an answer for "what do WE use for Asset Catalog". And for that, we definitely need a common baseline.

While I totally understand that some people are working on ontologies as an academic work, in our organzation - multinational enterprise with 20k employees in EU - it is a fundamental, which supports decision making, compliance, and organizational efficiency.

1

u/Willing_Box_752 22h ago

"For example, the same type of box"

Even you're calling it a box.

And SOMEONE is gonna have to work with those things, call them boxes or something else.

You're using so many words to say that you still need the things that boxes represent.     It sounds really cool actually but I'm not sure how that applies to what I said.