Q: How to model a server in EDG?

[Tim Smith]

Hi,

As I'm going through the EDG ontologies to understand how to model my environment, it is not always clear how the classes and properties should be used.

For example, I have a server, it could be a VM server or a physical server.  There is a Server class as well as a System class.  Server feels like the right class to use given that the System class has a property "hosted on" that says:

description:

Specifies the server that hosts the software.

property path:

edg:hostedOn

group:

Software Properties

order:

130

class:

Server

However, Server is a subclass of Software Asset.  One could argue that a VM server is effectively software.  However, the hardware running the VM or physical servers cannot be classified as Software Assets.

Am I missing something?  Should I use Server for physical servers or are there other options?  

Thanks for your help in understanding how to use the EDG classes properly.

Tim

[Irene Polikoff]

Hi Tim,

These days, when talking about IT Infrastructure, it is hard to separate hardware from software. In fact, with embedded systems I am not sure it is possible.

EDG models focus primarily on data processing. Thus, it is assumed that a server has a software aspect to it and that is the focus. People use the word “server” to talk about things like Tomcat Server, Solr Server, etc. 

The important part of the models are “-able” (Aspect) classes. A server is Locatable - thus, you can associate a location with it. It is also AccessControllable. By itself, it is not Interoperable. But Systems and SoftwareModules are. And Processable is an aspect class that is used for data or information that gets processed. So, it does not apply to software.

EDG models offer  comprehensive support for capturing information about data and application processing. They are not as comprehensive in handling other aspects of the world around us e.g., business processes, physical things, etc. Certain classes exist, but only to the extent necessary to support data governance/information management requirements. Compare this with a product that has a very strong focus on physical infrastructure or on business processes. It would have more richness and details in the models to support such needs.

A good thing though is that if a model does not have everything you need, you can always extend it to support your requirements. If you find it important to capture detailed information about physical boxes separately from the software, you can extend the model. We have customers that use EDG to describe physical assets where some of the assets are not even related to software e.g., a door or a window. Since EDG does not offer out of the box support for these entities, they model them themselves.

<image.png>

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnKcXHx%2Bq0WBmQCT5T5UDOnEYWOx9NM7nYHm%2BWA-rubEOg%40mail.gmail.com.

[Fan Li]

Does TopQuadrant offer training on using / extending the EDG ontology?

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11E55EF4-6D09-4507-BE29-B1D2917E0FE8%40topquadrant.com.

[Irene Polikoff]

Yes, through professional services.

Note that EDG ontologies are licensed according to the package they belong to. This means that in order to use the ontologies we are discussing here, you would need a metadata management package.

VM package only uses the SHACL version of SKOS and EDG Governance ontology. RDM package uses EDG Governance ontology and a model to support enumerations. All other ontologies have been developed to support the MM package of EDG.

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAC95LqUorcd4duQLtz0k304LWKMx1muzA1fcrCU-HXqLRKO6%2BA%40mail.gmail.com.

[Tim Smith]

Hi Irene,

This is very helpful information.  Knowing the key dimensions that the ontologies have been designed around provided the perspective I was missing.  I'm happy to add my own extensions as needed and I'll create ontologies to enable EDG to manage our infrastructure from OT devices through cloud computing and all the fun stuff in the middle.  Having a good UI experience is at least as valuable as the ontologies and I am looking to EDG to provide this experience.

To build on Fan's question with respect to extending the ontologies, I have read the EDG ontology extension portion of the Developer's Guide and feel comfortable that I can connect my models to EDG from a basic form/editing point of view.  I've been mostly successful  so far.  However, one component that is not clear to me is how to extend the ontologies in a way that the visualization capabilities of EDG pickup the extensions and treat them as native.  This is foundational to a good UI experience.

For example, I really need edg:successor to be a property that is shown when a LineageGram is generated, otherwise, processes don't show lineage even though edg:Process and edg:ProcessActivity are shown.  I will also have additional classes and properties that I would like for NeighborGram, LineageGram, etc... to display and interact with.  Therefore, with respect to extensions, are there key classes or properties that are natural extension points to enable the visualizations to use them?  Should I make my classes and properties super classes and super properties of specific classes?  This was a common design pattern in TBC/L with Spin functions, etc...

Do you have a standard training that is offered via Professional Services for which you could share the syllabus?

Thanks,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DD2804B6-D909-41A1-82D5-20597BEADF78%40topquadrant.com.

[Irene Polikoff]

Hi Tim,

Please see below

On Jun 1, 2020, at 11:03 AM, Tim Smith <smith...@gmail.com> wrote:

Hi Irene,

This is very helpful information.  Knowing the key dimensions that the ontologies have been designed around provided the perspective I was missing.  I'm happy to add my own extensions as needed and I'll create ontologies to enable EDG to manage our infrastructure from OT devices through cloud computing and all the fun stuff in the middle.  Having a good UI experience is at least as valuable as the ontologies and I am looking to EDG to provide this experience.

To build on Fan's question with respect to extending the ontologies, I have read the EDG ontology extension portion of the Developer's Guide and feel comfortable that I can connect my models to EDG from a basic form/editing point of view.  I've been mostly successful  so far.  However, one component that is not clear to me is how to extend the ontologies in a way that the visualization capabilities of EDG pickup the extensions and treat them as native.  This is foundational to a good UI experience.

For example, I really need edg:successor to be a property that is shown when a LineageGram is generated, otherwise, processes don't show lineage even though edg:Process and edg:ProcessActivity are shown.  I will also have additional classes and properties that I would like for NeighborGram, LineageGram, etc... to display and interact with.  Therefore, with respect to extensions, are there key classes or properties that are natural extension points to enable the visualizations to use them?  Should I make my classes and properties super classes and super properties of specific classes?  This was a common design pattern in TBC/L with Spin functions, etc…

There isn’t anything special in terms of NeighborGram. It will show all properties the same way.

LineageGram uses specific logic to roll up relationships and infer the “high level” connection to upstream or downstream. The roll up is done because the relationships can be very detailed e.g., a specific column in a specific table in a specific database is used by some program (or may be a module of a program) to populate another column in another table in another database. This is already a chain of several links to determine that two data sources are connected or that a db1 is input to an application and db2 is an output. If we were to show such a detailed display, it would be hard for users to see the forest for the trees. So, we roll up the relationships while allowing a drill down of each link.

This rollup logic is in SWP and that is the definitive documentation of the specific properties used. It can be extended. The dependencies are context sensitive. In other words,  the way things roll up depends on the type of resources which relationships need to be rolled up.

There is some documentation in the Lineage tutorial, but it is not complete.

Do you have a standard training that is offered via Professional Services for which you could share the syllabus?

I know that you are talking to Ralph later today. May be you can discuss this then.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnL%2BQYOFgi7o_Jm9XQb96z9hO0zk0RHHwM29r4Jjm4Umew%40mail.gmail.com.

[Tim Smith]

Thanks Irene!  That makes sense.  I'm looking forward to talking details with Ralph.

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D4FF8F95-D561-4F8C-BE55-24ED47D55DE0%40topquadrant.com.