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.
Feature: add supertypes (indirect types) to reportXML.xml
- 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
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
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).
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 .
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 could use some template slot for the new subclass.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.
"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.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.
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 .
- 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
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
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 wanted to make sure that we were not building capability that was already there that you may not have been aware of!
I would use multiple "type" tags instead of creating an additional one.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?
Not so cumbersome as the hierarchy is not very deep.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.
AMHA, this query will not be so "simple" : i think it will have to recurse on the subtype/supertype hierarchy.Then you could use a simple query to get all the subclasses of a particular superclass
It would be easier to "resolve" the hierarchy with java when (or before) uploading the xml file.
I'd modify the renderer java code in order to have multiple "type" tag for each instance (stopping at EA_Class).What do you think?
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...
- 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
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
- 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
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
Wow, thanks Jonathan. I think we may call the new feature "inheritance unfolding" .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.
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 ...jonathan.carter wrote: We're working on releasing a maintenance release and we may be able to get this into that release.
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.
- 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
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
Jonathan,
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
Use case:
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.
Hi Jean-Marie,
I like the term "inheritance unfolding"!
That's OK.Please set me straight if I've misinterpreted what you are describing!
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'.I'm basing this on this Protege FAQ - I have to say that I have not experimented with how it's implemented in Protege.
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 did a little experiment and i think that you'll have to unfold/resolve them ..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.
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".
+ 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.
- + 4 occurences for each Debian "technology_product".
+ 1 occurrence for the definition of the Debian OS "technology_product_family"
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.
Jonathan,
Use case :
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.
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).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.
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".
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.
- 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
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
Right.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.
I was more thinking to some mechanism in the reporting tab code ...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 don't think it's realistic to add this functionality ....
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....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!
Right.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).
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.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.
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)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!
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.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.
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 .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.
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, ......
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 ...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, ......
Hope you will never have to listen to it .By the way, your English is fantastic and certainly not why I didn't understand your use-case!
Regards,
J.-M.
- jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
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.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.
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.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)
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.
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.I do not think this is the solution if by "render time" you are thinking to "xslt time".
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".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".
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