Feature: add supertypes (indirect types) to reportXML.xml

Post Reply
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

As I understand it the reportXML.xml is produced through the "Essential XML Renderer"... Actually the code seems to only use the direct types of an instance ...

Would it be possible to add all the supertypes (superclasses hierarchy) of the instance in the reportXML.xml file ?
=========
Use case:
We have many app providers and I would like to have some classification on the protégé UI ...

So I subclassed the Application_Provider type with a class named "Business_External_Application_Provider".

As only the direct instance types are saved in the report I do not see my external applications in the App. Provider catalogue.
=========
Another plus of subclassing would be the possibility to add default values to slots according to the direct type of an instance. Or, better yet, we could also use template values (with some other modification to the renderer).
=====
An alternative to my wish would be to use multiple class for an instance adding some classification hierarchy .... But I fear displaying of slots (on the protégé side) may be impacted by such a use of multi-classing.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Yes, the XML rendering of the contents of the repository holds only those instances that exist in the model and only those slots that contain any values.

A lot of the Views actually just navigate relationships rather than querying by the type of the instance, so often the inheritance from superclasses or any polymorphic behaviour 'just works'. Obviously, when building catalogue Views, any hierarchies need to be considered and where we have those - e.g. Application Provider and Composite Application Provider, we account for that.

I understand what you are trying to achieve with that new subclass but I'm not sure the semantics of those "Business External Application Provider" are different to Application Provider or Composite Application Provider. Rather it feels more like a classification (as you describe), which can sometimes be rather arbitrary and for just these things, we have created the Taxonomies. These allow you to overlay your own classification schemes over the Essential ontology.

It's a modelling question and I'm not sure exactly what you mean by Business External Application Provider, so I could be wrong but a key indicator of needing a new class with new semantics is when you need new relationships that do not make sense to the existing class.

Each class in the Essential Meta Model has strong, clear semantics and is more than just a taxonomy (classification hierarchy). Rather, in doing the modelling, we are building a knowledge base in which the classes accurate describe what the elements in the model are.

As the model grows, you can use the Query tab (and save/re-use common queries) to filter a particular class, e.g. by one of your own classifications (Taxonomies).

Default values for slots can be set within the Classes and slots in Protege - including template values. Note that these are only applied to new Instances in Protege but you can do some scripting to apply these retrospectively. If the slots have a value, then they appear in the XML snapshot to be used by the Views.

On your last point, you can have multiple inheritance in Protege but my points above about the meta model stand. However, if you're looking for classification of things, the Taxonomies allow you to create your own and then any instance can be classified in as many taxonomies as you like - and because every element has the "element_classified_by" if it's classified by one or more Taxonomy Terms, this slot will be populated in the XML.

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

Jonathan,
I understand your point of view as you do not want over-complicate the core model, hence the use of taxonomies and classification which helps to organize the views.

As you said I was asking for a capability to classify things at the protégé interface and not in the viewer (easier data input).
I understand what you are trying to achieve with that new subclass but I'm not sure the semantics of those "Business External Application Provider" are different to Application Provider or Composite Application Provider.
I could use some template slot for the new subclass.
It's a modelling question and I'm not sure exactly what you mean by Business External Application Provider, so I could be wrong but a key indicator of needing a new class with new semantics is when you need new relationships that do not make sense to the existing class.
"Business External Application Provider" was only a use case (may be a bad one): we have many external application to interact (mainly for kpi reporting) and I wanted to simplify data input.

Also In this new subclass I could constraint some slots to some subclass of the original domain.

Note: My initial proposal was to "resolve" instances supertypes to simple types in the resulting reportXML hence the xsd and the xslt files would not have to change. The change impact would be minimal : only some code to change in the essential renderer :).
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

All makes sense and what you describe extends the meta model rather than changing what is there - which is exactly what we recommend in order to support on-going updates. I wanted to make sure that we were not building capability that was already there that you may not have been aware of! ;)

Back to the specific feature request - and it is an interesting one. I agree that there are some times in the Views where it would be good to be able to deal with things polymorphically, using the class / superclass hierarchy.

I am wondering how the class hierarchy would be represented in the XML. Do we show the immediate superclass as an additional tag related to the <type> tag? However, there are times when we need to deal with things as a very generic type - e.g. EA_Class. It could get quite cumbersome if we listed all the superclasses in each instance.

The XML renderer is based on the code that produces the Experimental XML project format in Protege. This includes the Classes as well as the Instances. We have dropped the Classes deliberately, so far. However, we could include the meta model (the Classes) as well as the model (the Instances) in the XML, which would provide all the information about the class hierarchy to the Viewer queries - and probably in a more efficient format.

Then you could use a simple query to get all the subclasses of a particular superclass and then use that node-set as part of a query to find the required instances that have <type> = values in the node-set.

What do you think?

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

I wanted to make sure that we were not building capability that was already there that you may not have been aware of!
Your answers are welcome. Before using Essential I had some experiments with Protégé in order to describe our business/applications/infrastructure dependencies... Tnus I have to admit that I'm much less aware of E.A than of Protégé :).

I am wondering how the class hierarchy would be represented in the XML. Do we show the immediate superclass as an additional tag related to the <type> tag?
I would use multiple "type" tags instead of creating an additional one.
However, there are times when we need to deal with things as a very generic type - e.g. EA_Class. It could get quite cumbersome if we listed all the superclasses in each instance.
Not so cumbersome as the hierarchy is not very deep.

Then you could use a simple query to get all the subclasses of a particular superclass
AMHA, this query will not be so "simple" : i think it will have to recurse on the subtype/supertype hierarchy.
It would be easier to "resolve" the hierarchy with java when (or before) uploading the xml file.
What do you think?
I'd modify the renderer java code in order to have multiple "type" tag for each instance (stopping at EA_Class).

I will try this proposal later when I'll come back after vacations and then let you know if it entails some side effects with your current reports...
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Good points.

In the Java, there's a simple API call to get all the superclasses. Multiple <type> tags would work nicely as the XSL would sort that "where 'type' = baseclass" neatly.

We think there could be a couple of Views that would be adversely impacted by this, so we need to check out the impact but otherwise, this looks like an excellent idea that is more efficient than what I was proposing.

I will take this away and try implementing that in the XMLRenderer class

Jonathan
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

A quick follow up on this.

We have completed the experiments that we discussed and the addition of the class inheritance tree to the XML snapshot was simple to code and although it does increase the amount of XML being generated, we felt that this was acceptable - especially in terms of the payback for improved querying in Viewer.

I have added to the XMLRenderer that is used by a couple of plugins. There's actually no impact on the Essential Viewer platform but does require an update to the Reporting Tab plugin for Protege.

We're working on releasing a maintenance release and we may be able to get this into that release.

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

jonathan.carter wrote:A quick follow up on this.

We have completed the experiments that we discussed and the addition of the class inheritance tree to the XML snapshot was simple to code and although it does increase the amount of XML being generated, we felt that this was acceptable - especially in terms of the payback for improved querying in Viewer.
Wow, thanks Jonathan. I think we may call the new feature "inheritance unfolding" :).
jonathan.carter wrote: We're working on releasing a maintenance release and we may be able to get this into that release.
So with this release we will be able to subclass the model, add instances to the new subclass and then see these instance in the viewer. Fine ...

Would it be possible to add a another feature : let's call it "template value unfolding".

It would allow to explicity relate "template value slots" (i.e. slots associated to classes) to instances in the reportXML.xml.

Remark: I'm not talking about "default values" but "template values".


What do you think ?

Jean-Marie.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Jean-Marie,

I like the term "inheritance unfolding"!

In terms of applying something similar to Template Values, these are values that are set at the class level and cannot be changed by subclasses and instances (unlike default values).

This is all handled inside Protege and whatever slot value is set in the repository will be there in the snapshot XML, available to the Viewer.

Given that the values of the slot are effectively static to a class hierarchy, there would be nothing to unfold for that slot.
I'm basing this on this Protege FAQ - I have to say that I have not experimented with how it's implemented in Protege.

In terms of defining relationships to classes (rather than to other instances) this is something that we use in some of our associated tools and the current XML rendering handles this. Where we have a slot that holds a relationship to a class, the class name is reported in the slot value.

If this related class is a superclass, then the inheritance unfolding would still enable you to quickly define a query for any instances (direct or subclasses) of the specified class.

I might be missing your point but I think we have all the capabilities in place to support what you describe without having to unfold the template values.

Please set me straight if I've misinterpreted what you are describing!

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

Jonathan,
Hi Jean-Marie,

I like the term "inheritance unfolding"!
:)
Please set me straight if I've misinterpreted what you are describing!
That's OK.
I'm basing this on this Protege FAQ - I have to say that I have not experimented with how it's implemented in Protege.
Mmm, the FAQ says that instances will have the template value --defined at class level-- as slot value. But, as I understand it, it does not say that this template value will be added to each instance as a 'slot_value'.

The protege UI seems to have a capability allowing it to resolve/display these template values ... so ... I would think that the "essential protege tab" has to possess the same capability :)
I might be missing your point but I think we have all the capabilities in place to support what you describe without having to unfold the template values.
I did a little experiment and i think that you'll have to unfold/resolve them ..

Use case:
  • + I have 4 "technology_product" : debian wheezy, debian squeeze, debian lenny and debian sarge.
    + All my "technology_product" are from the "Debian OS" "technology_product_family".
    + As lazy as I am I don't want to add the technology family to each "technology_product."
    => I define a template value in the "technology_products" class for the slot "member_of_technology_product_families".
    • Remark : I do not want to use a *default* value for the slot as I think that the "technology_product_family" may change from "Debian OS" to "Debian GNU/Linux OS".
    + Under Protégé, I verify that, in the instance tab, the value of slot "member_of_technology_product_families" is now correct for the 4 Debian "technology_product".
    + I create the reportXML.xml file through the "Reporting tab"
    + I search for the protege name (id) of the "Debian OS" instance in the reportXML.xml file. For me that's "Test1_Class750063"
    + I search (grep) for the number of occurence of the "Test1_Class750063" string in the reportXML.xml file.
If your view is correct I should have 5 occurrences of in the file :
  • + 4 occurences for each Debian "technology_product".
    + 1 occurrence for the definition of the Debian OS "technology_product_family"
But that's not the case : there is only one occurrence.

That's why I think you may have to unfold/resolve these template values.

Hoping my English is not hurting you too much,

regards,

J.-M.
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

Jonathan,
jonathan.carter wrote:A quick follow up on this.

We have completed the experiments that we discussed and the addition of the class inheritance ....

I have added to the XMLRenderer that is used by a couple of plugins. There's actually no impact on the Essential Viewer platform but does require an update to the Reporting Tab plugin for Protege.
I don't know for other essential users but, now, I sometimes use the capability that subclasses are *not* processed in the reporting tab (and so instances of these classes are not displayed in the viewer catalogs).

Use case :
  • Reason : I don't want to see in the catalog some application provider I defined in the model, but I don't want to lose the properties already defined for this provider.
    Action: I create a subclass of Application_Provider called "Unused_Application_Provider" and move the unwanted instances from the Application_Provider class to
    "Unused_Application_Provider".
Would it be possible to keep the same capability in your next version ?

That could be done by finding a way to list the classes that we do not want to display within the EA_Support hierarchy.

Regards,

J.-M.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Let me answer your second post first.

What you are doing makes perfect sense and will work just fine with the current implementation of the XML - without the inheritance unfolding. However, this approach would stop working and I think this is what you are saying.

And I also think you are on the right approach - this is something that we would add into the EA_Support area. Either something as simple as a Taxonomy or maybe a "built-in" taxonomy such as a class "Hide_Instances" in the Essential Viewer section of EA_Support.

The trickier bit is the impact that this would have on the Views. Every query would have to be qualified with a "and not in Hide_Instances". We could start introducing that to the catalogues, relatively easily but as you have seen, Viewer is highly inter-linked and really to properly hide things we'd have to add this qualification to all Views.

I don't think it's realistic to add this functionality in the XML Rendering as this should have no understanding of the meta model to ensure the extensibility of the meta model and the platform's ability to add or change any class with no software change required.

Potentially, we could expand the Menu Management framework to add an "exclude" types slot to the Report Menu definition, so that "hidden / unused" classes have no menu to further detail. This would be relatively simple to add to the framework - in fact even simpler if we took the Taxonomy approach to classify things as "hidden in viewer". You would be able to see the name of the element but you would not be able to drill into more detail.
That could be a starting point…

Interesting use-case!

On your earlier post, about the template slot values:
I see what you mean. So, Protege GUI can use the template slot values if no slot value is provided but it is kind of inherited rather than displayed (as it would using the default value).

I think the clearest way to see the difference between Default Slot Value and Template Slot Value is that Default Slot Values work fine but only set the value for NEW instances. It does not apply retrospectively. In contrast, the Template Slot Value does apply to all instances at once. However, I did note that I could not change that value, once it was set as a template slot - and I'm not sure that that is always a good idea.

We tend to use the Default Slot Value if we need something like that but set it before we need to use it. If there are a lot of instances to which we want to retrospectively apply this to, I normally put a short Python script together to run in the Script Console. I appreciate this isn't what you are looking for!

So, what it would need, in order to support the template slot values would be to add these as slot values in the XML at render-time.

Maybe it is just the example you've shown but I don't think using Template Slot Values is the safe way to do what you describe. Remember this applies at Class level - so all instances of Technology Product would suddenly be classified as being in the "Debian OS" technology product family. Again, I appreciate that this is just an example but I don't think that makes sense. For this particular scenario, if we know that that product family is changing from "Debian OS" to "Debian GNU/Linux" for all products that were grouped into "Debian OS", I would suggest taking a copy of the existing "Debian OS" instance and renaming the original to "Debian GNU/Linux". Then, automatically, all products that were grouped as Debian OS are linked to Debian GNU/Linux.

If we did have a default group that was the correct thing for most products, then we would be best using the Default Slot Value as we can then change it if it's wrong. We can't change the value of the Template Slot Value (although, if it's a multi-instance slot, we can add more).

By the way, your English is fantastic and certainly not why I didn't understand your use-case!

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

jonathan.carter wrote:Let me answer your second post first.

What you are doing makes perfect sense and will work just fine with the current implementation of the XML - without the inheritance unfolding. However, this approach would stop working and I think this is what you are saying.
Right.
And I also think you are on the right approach ....

The trickier bit is the impact that this would have on the Views. Every query would have to be qualified with a "and not in Hide_Instances". We could start introducing that to the catalogues, relatively easily but as you have seen, Viewer is highly inter-linked and really to properly hide things we'd have to add this qualification to all Views.
I was more thinking to some mechanism in the reporting tab code ...
I don't think it's realistic to add this functionality ....
Potentially, we could expand the Menu Management framework to add an "exclude" types slot to the Report Menu definition, so that "hidden / unused" classes have no menu to further detail. This would be relatively simple to add to the framework - in fact even simpler if we took the Taxonomy approach to classify things as "hidden in viewer". You would be able to see the name of the element but you would not be able to drill into more detail.
That could be a starting point…

Interesting use-case!
I do not have a clear view on the best solution to use and I'm sure you'll find something (also) intersting for the use case....

On your earlier post, about the template slot values:
I see what you mean. So, Protege GUI can use the template slot values if no slot value is provided but it is kind of inherited rather than displayed (as it would using the default value).
Right.
I think the clearest way to see the difference between Default Slot Value and Template Slot Value is that Default Slot Values work fine but only set the value for NEW instances. It does not apply retrospectively. In contrast, the Template Slot Value does apply to all instances at once. However, I did note that I could not change that value, once it was set as a template slot - and I'm not sure that that is always a good idea.
You cannot change the value at the instance level but you may change it in the *slot template definition". All instances will then get a new value for the slot.
We tend to use the Default Slot Value if we need something like that but set it before we need to use it. If there are a lot of instances to which we want to retrospectively apply this to, I normally put a short Python script together to run in the Script Console. I appreciate this isn't what you are looking for!
Python would be fine but I'd like to avoid the script tab for that. BTW the algernon native tab would also be fine (http://algernon-j.sourceforge.net/doc/a ... otege.html)
So, what it would need, in order to support the template slot values would be to add these as slot values in the XML at render-time.
I do not think this is the solution if by "render time" you are thinking to "xslt time". It would be better to add the slot values to instances in the reporting tab The thread https://mailman.stanford.edu/pipermail/ ... 02252.html could be helpful for that.
Maybe it is just the example you've shown but I don't think using Template Slot Values is the safe way to do what you describe. Remember this applies at Class level - so all instances of Technology Product would suddenly be classified as being in the "Debian OS" technology product family. Again, I appreciate that this is just an example but I don't think that makes sense.
My example is totally non-sense.However it had two purpose : 1) find a quick way to explain the use case and 2) put Debian as a googleable string in the forum :).

Note however that this example could be more appropriate if we have the "inheritance unfolding' capability : The "Debian OS" family could then apply only to instances of some "Debian_OS_Technology_Product" subclass of "Technology_Product".
For this particular scenario, ......
If we did have a default group that was the correct thing for most products, then we would be best using the Default Slot Value as we can then change it if it's wrong. We can't change the value of the Template Slot Value (although, if it's a multi-instance slot, we can add more).
For this particular scenario, ......
As I said above we may change the value at the *class level* or in the slot definition. However I understand that we have to access either the class or the slot tab for doing so ...
By the way, your English is fantastic and certainly not why I didn't understand your use-case!
Hope you will never have to listen to it :).

Regards,

J.-M.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

You cannot change the value at the instance level but you may change it in the *slot template definition". All instances will then get a new value for the slot.
We sometimes manage this sort of requirement via indirection and instances but I understand the requirement - even though I think we're talking about making the modelling more convenient rather than a missing capability in the framework.
Python would be fine but I'd like to avoid the script tab for that. BTW the algernon native tab would also be fine (http://algernon-j.sourceforge.net/doc/a ... otege.html)
Yes, I tend to use the script tab to quickly update a lot of instances at once. Our Essential Update Tab could be of use here to avoid the use of the script tab, running an update pack that changes the slot value. Easy to run - perhaps a little fiddly to put together.

If you find the other tabs, such as Algernon or Prolog or something easier, please make use of them. That is one of the beauties of Protege, that there are so many plugins.
I do not think this is the solution if by "render time" you are thinking to "xslt time".
No, not XSLT-time. I meant when the Essential Reporting Tab renders the XML that is published to the Essential Viewer. I think we agree on this.
Note however that this example could be more appropriate if we have the "inheritance unfolding' capability : The "Debian OS" family could then apply only to instances of some "Debian_OS_Technology_Product" subclass of "Technology_Product".
Careful, here. We should never have specifics like a particular type of operating system as a class. Even more specific types of technology (as an example) should NOT be classes but should be instances. The philosophy is that the meta model should work, make sense and not need updating regardless of how technology (or business, application, information) may change. This is why we don't have meta classes such as "operating system" or "database".

Although the practicalities of the model are not quite as neat as using "instance-specific" classes, this scenario is exactly what we designed the Taxonomies for. It may not be quite as neat in Protege but much more scalable and practical in the Viewer environment.

We will have a detailed look at the potential for template slot values in general and make a call on whether this is something that we should be adding to the platform. I think the solution is fairly straight-forward (extending how the XML is created) it is probably going to be a question of prioritisation.

Regards

Jonathan
Essential Project Team
Post Reply