I'm using Protégé to define an ontology and I'm having trouble defining constraints.
Let's say I have a class "Node" and the Node can be related to other nodes and so on (creating a hierarchical tree). Each node as a data property with a corresponding level.
While I can define domain and range for the property, and define that the class Node has a restriction on this property (only Node values), I don't see any way to define that a Node can only be related to a Node with a lower level.
Any ideas on how to do this using OWL?
Thanks
Related
I have lots of entities with nested List<> in each.
For example, I have BaseEntity which has List<ColumnEntity>.
ColumnEntity class has List<Info> and so on.
We are working with a WPF UI, and we need to track all changes in every List of BaseEntity. It is implemented by instantiating a new ObservableCollection based on the needed list, and with binding to that ObservableCollection.
What are the pros and cons changing all these nested Lists to ObservableCollections? So we can track all changes in BaseEntity itself without reassigning each list of BaseEntity to modified bound ObservableCollection?
Assuming that methods specific to List are never used.
Interesting question, considering that both List and ObservableCollection implement IList<T> there isn't much of a difference there, ObservableCollection also implements INotifyCollectionChanged interface, which allows WPF to bind to it.
One of the main differences is that ObservableCollection does not have AddRange method, which might have some implications.
Also, I would not use ObservableCollection for places where I know I would not be binding to, for this reason, it is important to go over your design and make sure that you are taking the correct approach in separating layers of concern.
As far as the differences between Collection<T> and List<T> you can have a look here
Generic Lists vs Collection
It depends on exactly what you mean by this:
we need to track all changes in every List of BaseEntity
Would it be enough to track changes to objects already in the list? Or do you need to know when objects are removed from/are added to/change positions within the list?
If a list will contain the same items for their whole lifetime, but the individual objects within that list will change, then it's enough for just the objects to raise change notifications (typically through INotifyPropertyChanged) and List<T> is sufficient. But if the list will contain different objects from time to time, or if the order changes, then you should use ObservableCollection<T>.
So while the differences may be interesting (and a previous poster has already covered those), typically you won't have that much of a choice - either you need ObservableCollection<T> or you don't.
List represents a strongly typed list of objects that can be accessed by index. It provides methods to search, sort, and manipulate lists. The List class is the generic equivalent of the ArrayList class. It implements the IList generic interface using an array whose size is dynamically increased as required.
ObservableCollection is a generic dynamic data collection that uses an interface "INotifyCollectionChanged" to provide notifications when items get added, removed, or when the whole collection is refreshed.
Read more about it in this link: http://www.codeproject.com/Articles/42536/List-vs-ObservableCollection-vs-INotifyPropertyCha
One more important difference is you can access ObservableCollection only from thread on which it was created where as list can be accessed fromany thread.
I see no problem with that, other than a very marginal performance overhead.
Note that if you modify the internal Lists directly, you are not notified about changes. Also if the objects which are contained in the ObservableCollection are modified you are not notified. Notification occurs only, if elements are added, replaced, removed or moved.
Having to work with a legacy silverlight application I ran into a strange piece of code. The viewmodel has a List dependency property as binding source for the grid. This DP has a default value, an other List that is used globally in the app. This is used to easily share entity data between different parts of the application.
DependencyProperty MyEntitiesProperty = DependencyProperty.Register("MyEntities", typeof(List<Entity>), typeof(...), new PropertyMetadata(Global.Entities));
Now, when the list is changed (on user actions), the global list is repopulated from database but MyEntities is never set explicitly. This does not work: the grid (the binding target) never changes. So its a wrong solution.
I speculate that the idea behind all this could have been been the following: if you have a DP with a given value and you never set a local value for it then the effective value of the DP will be the default value. If the 'underlying' default value is changed, the changes are reflected in the effective value.
If it worked, it was a nice way of sharing data between independent viewmodels without fiddling with property change events and such.
What is wrong here? Is it a big misunderstanding of how DPs work or the idea was ok and some implementation details were missed?
Please comment if something is not clear.
Well, taking also your comment into account, it is a big misunderstanding of how DPs work. Let me explain:
Setting a globally known list as the default value of MyEntities might not be a pattern I recommend, but is technically not faulty and can be done to share a list. MyEntities now holds a reference to this very list.
If you now replace the global list with a new list instance, the old instance does not cease to exist. Your property MyEntities still holds a reference to the old list. The value of a DP is only updated automatically if it is bound via Binding to either an ordinary property that is wired with the INotifyPropertyChanged mechanism or another DP.
Setting a default value happens neither via a Binding to an ordinary property nor via a Binding to another DP, it is just a plain old object reference.
I can think of several ways to correct the situation:
First solution
If the global list implements INotifyCollectionChanged (e.g. ObservableCollection, DependencyObjectCollection) you can - instead of creating a new list instance - just delete the old items from the list and add the new items. The views that have a reference to the list will perform an update as soon as they receive the associated CollectionChanged event.
Second solution
Make sure the Global.Entities list is available and always up-to-date as a public property (wired with INotifyPropertyChanged) on the DataContext of the root view. Now when you want a nested view somewhere deep down inside the UI tree to be connected to this Global.Entities list you can bind it to the root view's DataContext' public list property.
<MyRootView>
... nested views spread across multiple files ...
<MyNestedEntitiesListDisplay
MyEntities="{Binding
Path=DataConext.GlobalEntities,
RelativeSource={RelativeSource AncestorType=MyRootView}}"/>
Simple example:
I have VM with hierarchical item structure and I have designed View containing TreeView. Each tree node corresponds to data item related to the one in the Model.
GUI must respect user preferences and settings and store different parameters including whether each particular node is expanded or not. As long as every node relates to some data we need to tie View settings with the Model. I beleive it's not OK to define property IsExpanded in the class standing for the Model.
So where should I store the settings so they stayed consistent with the data?
I believe it's not OK to define property IsExpaned in the class standing for the Model.
Why? Will there be occassions when the model is linked to two different tree-views?
If that is the case you can certainly create an "adapter view-model" that wraps your models and adds the property. Just be careful because that can technique can easily lead to a memory leak.
Otherwise, it is perfectly acceptable to put it right in the model, especially if that model is being used specifically to serve that view. As with all things, start with the simplest, most pragmatic approach.
I was in a similar situation, here's what I did to solve it.
Each ViewModel node had an IsExpanded property, which was bound to the TreeViewItem's IsExpanded property. I didn't want to persist the state of the tree by storing it in the Model in IsExpanded properties (it's to do with visual state right?). So instead, I had the VM tree structure generate a dictionary that stored the expansion state for each node against a string key generated from the node's state in the tree:
Dictionary<string, bool> treeExpandedStates
Each node in the tree had an ID, so in my case the key was something like "/1/3/7", but anything unique will do. This Dictionary was then serialized to a file on application close (in actual fact it was a SerializableDictionary). Then on application restart, it was deserialized and used to set the expansion state after the hierarchy had been loaded back up. This meant that the state of the tree was exactly as the user had left it, but nothing was stored in the Model.
I recognize the problem as a common dilemma in MVVM. I can look at it from two sides.
Approach A)
In the separation of View, Model, and ViewModel, what you describe resides in the Model. You write for example that it needs to be stored. That does not mean it is the same part of the model as the other model data.
Consider the following separation:
FolderModel - A model of the content or properties of a folder.
TreeNodeModel - A model of a users choices when exploring the tree view.
It might not be that easy to do a separation just like that, but the point is that MVVM is not meant to force you to stuff everything in the same place, and I do not think MVVM prevents you from keeping models for user interactions, the same way as you keep models for data content. Microsoft writes:
The data could come from a database, a Web service, a named pipe, a file on disk, or even carrier pigeons: it simply does not matter.
Why should not data for a data model be able to come from interactions of a user? :)
Approach B)
My usual approach to these dilemmas, though, is that properties like IsExpanded does mostly not need to be stored between sessions. That way, a property in the ViewModel, with a default value instead of a stored value, suffices. :)
And if it needs to be stored, it does not need to be stored in the Model. The ViewModel is for logic for presenting model data. If the ViewModel wants to save its logic state, that does not have to be stored in the Model.
Summary
In my point of view, you can store it any of these ways without breaking the MVVM pattern.
I've got a database structure similar to this:
Items
ID
Name
ParentItemFK (tasks & notes can have any item as a parent; categories can only have other categories as a parent)
CategoryFK
TaskFK
NoteFK
Categories
ID
Description (optional)
Tasks
ID
FullDescription
IsComplete
Notes
ID
FullText
The items are to be displayed in a TreeView. An item can be either a category, task, or note (so one and only one of the FK columns are filled in).
I'd like to display all items in a TreeView. I am using a DomainService with WCF to get the data from the back-end, for display in Silverlight.
I could programmatically build objects to be displayed in the TreeView (i.e. make an object such as ItemNode, with child ItemNodes for each sub-item). This would probably work alright, but when the data that the DomainService has is refreshed, I think the whole list of ItemNodes would have to be rebuilt (which could happen often).
I'm using entity framework underneath the DomainService, if that matters.
Is there a better way to do this??
Thanks!
I did something similar to this and I created a custom object which represented my hierarchy. Then I created a helper class to recurse through the custom object and create Tree nodes to bind to the TreeView.
I also used the Hierarchy SQL Datatype to represent my Hierarchy in the database.
Since your using Entity framework, I'm thinking your best bet is to just create some TreeNode class which will take in your entities and then recurse through them and spit back out a Hierarchy of TreeNodes which you can then bind to the TreeView.
Also, you will want to put the unique identifier for that entity in the TreeNode.Value so that when a user interacts with a node, you will be able to easily modify the entity which represents the TreeNode. So, create another class which will recurse through your entities and get a reference to that entity based on its identifier.
hth
Hi I am using an interface IFooNode, which is part of a tree.
I wanted to display this tree in a TreeView using a HierarchicalDataTemplate.
This however does not work due to the interface.
I see two ways around that neither are what I would call "nice"
Find out what type really implements IFooNode (let's call it FooNode...), then find the assembly defining FooNode, add a Reference to that assembly and create a HierarchicalDataTemplate for FooNode (hoping the Implementating class never changes...)
Write a class MyCoolIFooNodeWrapperForWpf that wraps IFooNode, do not bind to the tree, but fill a list of MyCoolIFooNodeWrapperForWpf from the tree root and create a HierarchicalDataTemplate for MyCoolIFooNodeWrapperForWpf.
Can I somehow always apply a HierarchicalDataTemplate, no matter what type the data is (This I think would be the lesser evil...)
Any other Ideas?
You can use ItemTemplateSelector. In the selector's code you can check which interface your data object implements, and select the appropriate DataTemplate/HeirarchicalDataTemplate for this item.
The selector can both be applied to the container itself (ItemsControl.ItemTemplateSelector) and to your hierarchical data template (HeirarchicalDataTemplate.ItemTemplateSelector).
I think this is the lesser evil.
If you're not selecting from among multiple templates, you don't need to specify a data type on the template. If all of the objects in your tree implement your interface, just stick in a template using properties of that interface and you're good to go. You don't need to do anything in the template to make it specific to that interface.
If, for some reason, you need to do template selection based on what interface an object supports, you need to implement a template selector, and deal with the many-to-one problem that prevents WPF's built-in template selection mechanism from using interfaces in the first place. (That is, if you have a template for IFoo and one for IBar, what template do you use for an object that supports IFoo and IBar?)