In my ontology I have individuals "pic Joan" which is an instance of concept "mountain" and "port Cerbère" which is an instance of concept "village". I have the relation "dominates" going from "pic Joan" to "port Cerbère" (in the sense that the mountain is perceived as being close and above the village, and hence "dominates it").
But in fact, I need to represent the information "pic Joan dominates port Cerbère at a distance of 1.5 miles NW".
So, logically, I would need to attach to the relation "dominates" the data properties "distance=1.5M", "direction=NW".
But, AFAIK, OWL does not provide properties for relations. I know that I can define range and domain for relations, but this is not about range and domain, the same relation will have different property values when taken between different instances.
How would you represent this information in OWL?
(Auxiliary question: is there some other ontology formalism where I can define properties for relations? And if yes, are there tools like Protégé to manage ontologies in that formalism?)
The most common pattern for this use case is to introduce a new class, say RelativePosition:
RelativePosition a Class.
relationType a DataProperty.
relationType domain RelativePosition.
// relationType values not specified here: might be "dominant","overlooking"...
// depending on your needs, this might need more structure.
firstFeature a ObjectProperty.
firstFeature domain RelativePosition.
secondFeature a ObjectProperty.
secondFeature domain RelativePosition.
// both properties can appear multiple times for one instance of RelativePosition
// to group sets of entities which share a relative position
More properties can be added to introduce distance, or other characteristics.
Edit: copied link from Joshua's comment below: for n-ary relations, see here
is there some other ontology formalism where I can define properties for relations?
Have you looked into Topic Maps?
Related
I try to process line-based data using protege 5 and picture similar "regions" of a curve.
So I have a curve, which is deconstructed into portions of equal lengths in my ontology (class Portion, instances p_1, ... ,p_n). The portions are defined by their start- and endpoints (point_1, ... ,point_n+1), furthermore, the radius of the curve is stored in the ontology as data property of the instances (p_1, ... ,p_n). I managed to reason the adjacency relations between the different portions
hasStartPoint(p_2,point_2) o isEndpointOf(point_2,p_1) => isNextOf(p_2, p_1)
hasEndPoint(p_1,point_2) o isStartpointOf(point_2,p_2) => hasNext(p_1, p_2)
I also managed to create defined classes, storing portions with the same radius.
So here is my question: I want to reason the sets of portions (regions), which are adjecent and share the same curve radius. Then, i instances of a class Set should be created, for i different radius and non-adjecent sets, individuals (region1, ... ,regioni).
Here is the exemplary data I want to process: data I want to process
In other words: if a radius appears twice on the given line, and the portions of this radius are not adjacent, they should not be part of the same region. Further, regions should be created automatically when adding portions of different radius. The only idea I have, is to somehow traverse the set of portions with a loop over the isNext triplet, which requires some coding I guess, but I can't find anything alike here...
I hope, my problem is clear and I am happy to read if anybody has an idea on it.
Thank you in advance
Julian
From the owl-api tag, I infer you're looking to write code that uses the OWL API to reach your objective (You didn't mention which reasoner you're using in Protege - you'll need to use the same reasoner in your code to get things like hasNext relations inferred).
In OWL API, I'd do something like the following:
Infer the hasNext triples, if they are not already stored in the ontology file
For each of the defined classes that separate instances with the same radius
Retrieve all individuals of that class
Retrieve all property assertions with hasNext
Aggregate these instances into regions - e.g., seed one region for each property assertion, then merge two regions if their instances all belong to the same defined class and an endpoint in one region is a startpoint in the other. Repeat until only one region is left for a defined class (I believe, from your problem description, that regions cannot span outside of instances with the same radius) or until no further merges can happen.
In terms of OWLAPI implementation, once you have the ontology loaded in an OWLOntology object, you'd create an OWLReasoner with the OWLReasonerFactory implementation available for the reasoner of your choice (examples of this exist in the OWLAPI wiki), then there are a number of methods that can come in handy:
(Referencing OWLAPI 4 here because that's what Protege uses)
Get all individuals of a class: OWLOntology::getClassAssertionAxioms(OWLClassExpression) gives all axioms stating an individual belongs to a class, useful to retrieve instances of your defined classes. Through OWLReasoner, you can use OWLReasoner::getInstances(OWLClass)
Get all object property assertions for an individual: OWLOntology::getObjectPropertyAssertionAxioms(OWLIndividual). Useful to get hasNext values. Through the reasoner, this would be OWLReasoner::getObjectPropertyValues(OWLNamedIndividual, OWLObjectPropertyExpression)
I believe the rest of the algorithm can be implemented without OWLAPI specific code.
I am new to ontology design, and I have a project that requires me to match some individuals if they point to the same values for some of their properties.
I've posted some screenshots with the classes, object properties, data properties and individuals here:
https://imgur.com/a/Ak4og
A more "in detail" explanation(CAN ALSO BE DEDUCED FROM THE PICS): I have the class Person, who has a subclass Expert. There are also class FieldOfPractice(subclasses: computer_science, engineering, public_administration, etc.), Expertise(very_low,low,moderate,high,very_high) and Certification(A,B,C,D), Book and Expertise_Community classes.
I have as data properties firstName, lastName, dateAdded, bookName, communityName.
Each Person (so also Expert) has to have hasCertification, hasExpertise, hasFieldOfPractice properties which will all have the obvious range.
The Expert has to have recommendedBooks() and isInExpertCommunity properties.
The requirement: Create some Individuals of type Person, Expert, Book,etc. Make an "inference algorithm" such that for each person who has the same certification, expertise and field of practice as any of the experts, recommendedBooks() and isInExpertCommunity properties are inferred from the corresponding Expert Individuals to the Person Individual.
So for example lets say that: We have an individual Person: Mr.A , who has as object properties hasFieldOfPractice() computer_science, hasCertification() B, hasExpertise() very_low.
We also have an individual Expert: Expert5 with the same values for hasFieldOfPractice(), hasCertification() and hasExpertise() as Mr.A. Expert5 has as recommendedBooks() book1, book6 and for isInExpertiseCommunity() community4.
The "inference algorithm" should infer to Mr.A the recoomendedBooks() book1, book6 and isInExpertiseCommunity() community4. It should also do this if Mr.A matches with another expert who points at different books for reccomendedBooks() and/or another expertise community.
I have also found some similar questions but haven't been able to link the answers properly to my problem:
How to infer isBrotherOf property between two individuals - very good answers, but I need to change the SameAs() property instead of hasBrother() from the question.
Using Property Chains to get inferred Knowledge in an OWL Ontology(Protege) - same problem, but here my SameAs() which I think its predefined, corresponds with the example's employs().
From what I've seen I have to link somehow the sameAs() -> property chain -> rollification concepts, but I don't really get it yet.
To me, the dcterms:identifier property seems like a legitimate inverse functional property. When two things share the same identifier, I think it is safe to conclude that it is the same thing.
Is there any compelling reason not to define it as such (owl:InverseFunctionalProperty) in my ontology?
If you need to stay in OWL 2 DL, then it's not a good idea to declare data properties to be inverse functional - only object properties can be declared as such without violating the constraints and end up in OWL 2 FULL.
dcterms:identifier has a range of rdfs:Literal defined here
You could use a HasKey axiom to achieve similar results: keys were introduced in OWL 2 for the purpose of identifying one or more properties whose values are identifiers for the referring individuals, and both object and data properties can be used.
According to wikipedia
Dependency is a relationship that shows that an element, or set of elements, requires other model elements for their specification or implementation.[1] The element is dependent upon the independent element, called the supplier.
So is it not the same as unidirectional association?
Do we use dependency when an operation in one class uses object of the other class as its parameter?
How are unidirectional association and dependency different.
Any example would be very helpful
Dependency :
Indicates that a client element(of any kind, including classes,
packages, use cases, etc) has knowledge of another supplier element,
and a change in supplier can effect the client.
So "dependency" is very broad relationship.Suppose that if a class-object(client) has another class-object(supplier) as a member,if a class-object send a message to another class-object,if a class-object takes another class-object as an parameter from its methods, even if a class(client) is subclass of another class(supplier) there will be dependency since change from supplier will effect clients.
Technically all of those relationships can be shown by "Dependency" line. But some of above relationships already has special notations: such as for superclass-subclass relationship we have generalization relationship.No need to show also "dependency" line because if they have generalization relationship, they have dependency. And we have "association" relationship for class-object(client) who has another class-object as a member [attribute]. So also no need to show extra dependency line in this situation.
Actually "Dependency" is badly defined relationship for class diagrams. But it can be usefull for showing dependency in which UML has no special notation such as :
if you has another class-object(supplier) as a parameter in one of your class(client) methods
if you have dependency to global variables
when you call static methods on another classes.
local variables (which you think you have important dependency)
public class RepositoryManager
{
public UpdatePriceFor(ProductDescription description)
{
Time date = Clock::GetTime();
Money oldPrice =description.GetPrice();
...
}
private IList<Item> itemsList = new List<Item>();
}
So all "associations" are also shows "dependency".But "dependency" is
broad-general-weak relationship.As a rule if there is a special
relationship which is more specific-stronger than dependency
relationship than use it. And lastly use all your relationship
"economically". Show only important ones based on modeler-model reader
perspectives.
[ Source : Adapted from Craig Larman's Applying UML and Patterns book ]
Check Fowlers bliki for further information DependencyAndAssociation
Association means that the two associated entities are linked semantically. Dependency only declares that there is a... well, dependency of some sort. All associations are dependencies, while a dependency does not actually mean association. For example, class 'A' depends on class 'B' if it has a method that takes 'B' and passes it as argument to a function in another class. But if 'A' calls some method of class 'B', it should be modeled as association.
Disclaimer I have read the UML specification and also asked myself this question a number of times. I arrived at at the definition above, but I'm still not sure it is 100% correct.
Portfolio A → Fund 1
Portfolio A → Fund 2
Portfolio A → Fund 3
I couldn't frame my sentence without not using is/has. But between 1 & 2,
1) has a:
class PortfolioA
{
List<Fund> obj;
}
2) is a:
class PortfolioA : List<Fund>
{
}
which one do you think is better from the point of extensibility, usability? I can still access my funds either way, albeit with a small syntactical change.
I vote with the other folks who say HAS-A is better in this case. You ask in a comment:
when I say that a Portfolio is just a
collection of funds, with a few
attributes of its own like
TotalPortfolio etc, does that
fundamentally not become an "is-a"?
I don't think so. If you say Portfolio IS-A List<Fund>, what about other properties of the Portfolio? Of course you can add properties to this class, but is it accurate to model those properties as properties of the List? Because that's basically what you're doing.
Also what if a Portfolio is required to support more than one List<Fund>? For instance, you might have one List that shows the current balance of investments, but another List that shows how new contributions are invested. And what about when funds are discontinued, and a new set of funds is used to succeed them? Historical information is useful to track, as well as the current fund allocation.
The point is that all these properties are not correctly properties of a List, though they may be properties of the Portfolio.
do not 'always' favor composition or inheritance or vice-versa; they have different semantics (meanings); look carefully at the meanings, then decide - it doesn't matter if one is 'easier' than the other, for longevity it matters that you get the semantics right
remember: is-a = type, has-a = containment
so in this case, a portfolio logically is a collection of funds; a portfolio itself is not a type of fund, so composition is the correct relationship
EDIT: I misread the question originally, but the answer is still the same. A Portfolio is not a type of list, it is a distinct entity with its own properties. For example, a portfolio is an aggregate of financial instruments with an initial investment cost, a total current value, a history of values over time, etc., while a List is a simple collection of objects. A portfolio is a 'type of list' only in the most abstract sense.
EDIT 2: think about the definition of portfolio - it is, without exception, characterized as a collection of things. An artist's portfolio is a collection of their artwork, a web designer's portfolio is a collection of their web sites, an investor's portfolio consists of all of the financial instruments that they own, and so on. So clearly we need a list (or some kind) to represent a portfolio, but that in no way implies that a portfolio is a type of list!
suppose we decide to let Portfolio inherit from List. This works until we add a Stock or Bond or Precious Metal to the Portfolio, and then suddenly the incorrect inheritance no longer works. Or suppose we are asked to model, say, Bill Gates' portfolio, and find that List will run out of memory ;-) More realistically, after future refactoring we will probably find that we should inherit from a base class like Asset, but if we've already inherited from List then we can't.
Summary: distinguish between the data structures we choose to represent a concept, and the semantics (type hierarchy) of the concept itself.
The first one, because you should try to favour composition over inheritance when you can.
It depends whether the business defines a Portfolio as a group (and only a group) of funds. If there is even the remote possibility of that it could contain other objects, say "property", then go with option 1. Go with option 2 if there is a strong link between a group of funds and the concept of Portfolio.
As far as extensibility and usefullness 1 has the slight advantage over 2. I really disagree with the concept that you should always favour one over the other. It really depends on what the actual real life concepts are. Remember, you can always^ refactor.
^ For most instances of always. If it is exposed publicly, then obviously not.
I would go with option (1) - composition, since you may eventually have attributes specific to the portfolio, rather than the funds.
The first one, because it is "consists of". => Composition
I will differ with what appears to be the common opinion. In this case I think a portfolio is very little more than a collection of funds... By using inheritance you allow the use of multiple constructors, as in
public Portfolio(CLient client) {};
public Portfolio(Branch branch, bool Active, decimal valueThreshold)
{
// code to populate collection with all active portfolios at the specified branch whose total vlaue exceeds specified threshold
}
and indexers as in:
public Fund this[int fundId] { get { return this.fundList[fundId]; } }
etc. etc.
if you want to be able to treat variables of type Portfolio as a collection of funds, with the associated syntax, then this is the better approach.
Portfolio BobsPortfolio = new Portfolio(Bob);
foreach (Fund fund in BobsPortfolio)
{
fund.SendStatement();
}
or stuff like that
IS-A relation ship represents inheritances and HAS-A relation ship represents composition. For above mentioned scenario we prefer composition as PortfolioA has a List and it is not the List type. Inheritances use when Portfolio A is a type of List but here it is not. Hence for this scenario we should prefer Composition.