Represent UML diagram in OWL - uml

I have two classes Person and Vehicle having owns as relation between them.
There is 1 to many relation between them like one person can own many vehicles. Person has attribute 'name' (person name) and vehicle also has attribute 'name' (brand name).
Question is how to model this in OWL using protege editor?
If there is an attribute on 'owns' relation saying 'DateOfPurchase' how to represents this in OWL ?

If there is an attribute on 'owns' relation saying 'DateOfPurchase'
how to represents this in OWL ?
If that's the domain model, then the UML doesn't capture it. What you're describing is that there's an Purchase or Ownership entity with some additional attributes, more like
+--------+ +-----------+ +---------+
| Person | → * | Ownership | → | Vehicle |
+--------+ +-----------+ +---------+
| date |
+-----------+
This is essentially the same approach that I described in your earlier question, Can OWL punning help in defining data properties on object property?. There's no way to "sneak in" metadata about a relationship; you must make it explicit.

Object properties in OWL describe relation between individuals, not between classes. It is a "borrowed" URI, nothing else. So, what you need is to reify each statement such as :PersonA :owns :VehicleB. RDF allows that, however Protégé does not. So, here's a workaround:
You create two object properties :hasSubjectOfOwns and :hasObjectOfOwns, and for each case you need to describe dateOfPurchase, you define an individual representing the statement, and assert :
:AownsB :hasSubjectOfOwns :PersonA; :hasObjectOfOwns :VehicleB; :dateOfPurchase "2014-10-01"^^xsd:date
Initially you'd need to create a property chain, which in Protégé would look like that:
inverse (hasSubjectOfOwns) o hasObjectOfOwns SubPropertyOf owns

Related

How to extend JHipster JDL

We would like to extend JDL to represent some additional GUI aspects in the generated frontend. E.g.:
show additional attributes from joined entities in the table
show custom defined attribute instead of entity ID in dropdowns
show detail list in parent entity form
etc.
Is there any way to extend JDL and use it in some custom blueprint? Or should we use some different approach?
In relation to the second item, there is a feature in the JDL relationship definition which helps:
relationship (OneToMany | ManyToOne | OneToOne | ManyToMany) {
<from entity>[{<relationship name>[(<display field>)]}] to <to entity>[{<relationship name>[(<display field>)]}]+
}
If you define one "display field" for the relationship end, JH will generate a drop-down using that field instead of the "id".
In relation to the third item, I am also interested in that feature. So, please let us know if you find a solution.

Tagged Value Type - Collection of Structured Types in Enterprise Architect

Is it possible in Enterprise Architect to define as Tagged Value Type collection of some structured types?
For example if i need to extended Table's attributes with collection of N addresses (street, number, city) - hypothetical example:
Table: Person
Tagged Value: List of addresses -
West Street, 1, New York
South Street, 2, New York
East Street, 3, New York
In general i want to simulate in EA what is known in PowerDesigner as Extended Composition of Extended Subobjects.
I followed suggestion to use RefGUIDList, what seems to be most close to my use case but failed as well:
I created Stereotype Address based on Class Metaclass and imported UML Profile containing this metatype to my data model:
I defined Tagged Value Type List of Addresses as:
I created a pair of Address objects and expected to be able to select between them when tagging table Person, but it did not work and no address showed up.
When removing filter for Types and Stereotypes from Tagged Value Type definition i was able to select Addresses between all objects in model:
This behaviour is far from PowerDesigner's Extended Compositions functionality. In addition, i need to be able to create new Address right during editing Tagged Value List of Addresses and not before...
Your List of Addresses definition is wrong. Values specifies the metatype, so it should be
Type=RefGUIDList;
Values=Class;
Stereotypes=Address;
When you've got it set up right, you can select the specified metaclass/stereotype using the ellipsis button. The dialog that opens has an Add New button, which allows you to create new elements of the proper type on the fly.

Is this how to structure classes for DDD?

Assume I have the relationship where every customer has an address (which in this case, is an entity), like below:
Customer{ Id, Name, MyAddress (instance of Address) }
Should I be allowing a structure that exposes the following option:
MyCustomer.MyAddress.Street = "Pine Street";
CustomerRepository.Save(MyCustomer);
Should this cascade a save, both for the Customer class and for the Address class? Or, is it better to perform the following:
MyCustomer.MyAddress.Street = "Pine Street";
AddressRepository.Save(MyCustomer.MyAddress);
Unfortunately, Address really is a value object, but I cannot make it interchangable like DDD requires as the Id tag is present; for example, if I did the following:
Customer1.setAddress(Customer2.getAddress());
Both Customer1 and Customer2 now have the same binding to the same record, which is dangerous.
None of your samples is DDD. Each one is simple CRUD.
Don't "set fields". Do meaningful operations.
customer.MoveTo(new Address(...))
customer.FixAddressTypo(new Address(...))
Repositories are for aggregates, not any entities. Identify your aggregates. http://dddcommunity.org/library/vernon_2011/
Why not map the Addres value Object as a bunch of fields in the Cutomers table? You don't need separate table just because you have a separate class.
Value objects should be immutable.

UML object attribute linkage

If you've got a function like this inside a class called 'A'
public updateResponse(UpdateRequest updateRequest){
//...
}
Where UpdateRequest is another class which you create an object from
as in UpdateRequest ur = new UpdateRequest();
What is the relation between those two classes (Between 'A' and 'UpdateRequest')? I thought of an "usage" link between the interface of A and the class UpdateRequest. Is this correct? If not, what kind of link should it be?
If the diagram is a class diagram there is no relationship to be taken from your question.
The relationship between these two classes would be best show in a Sequence Diagram or an Activity Diagram. These show method calls etc, a method may be a member of a class in a class digram but it wouldn't really be expressed as a link. Unless you specifically wantto highlight this method, you could then put a usage link to the method on the class. But its not always good practice to do this for every method as you end up with a very messy class diagram.
It's always best to show these relationships in the diagrams you have to show the usage of the method.
EDIT:
How does the class A instance relate class UpdateRequest instance?
Q - What relationship are you trying to show? A - Method/function call.
Some class calls updateResponse and the information flow is an UpdateRequest instance.
Therefore... From left to right
SomeClass --| A
| | a = new UpdateRequest |
|<-----| |
| |
| updateResponse(a) |
|------------------------------------>|
Your sequence diagram might look something like this. There is no specific relationship drawn between class A and UpdateRequest as it is simply a piece of information that flows through the method call you have in your example. If the class was a member of the class, then the relationship would be shown directly on a class diagram, not applicable here. All the classes might (should) shown on a class diagram seperately, this can then be used as a reference point about all the objects in any diagram for those that need to analyse the design.

drupal 6 view: 'sibling' node reference

apologies if this has been answered--this seems like a common enough problem, but i didn't find anything.
in a drupal 6 view, i need to find other nodes that reference same node as current node, sort of like sibling references. this is for a student/parent directory.
the view is a list of students (one content type), the parents per student ('parent' being another content type, node referenced from the 'student' type) and the siblings of students (the stickler)--these are 'student' nodes that share the same 'parent' node references.
something like:
student | parents | siblings
--------------------------------------
jane d. | mom. d, dad d. | jeff d.
jeff d. | mom. d, dad d. | jane d.
any help is appreciated.
in views you should use Relationships and View arguments (if required).
via relationships, you can set your rules (parent > student). Also, please bear in mind that if you're using relationship and want to access related nodes' fields, in display fields, you should choose use relationship, so it will print fields of related nodes, not the parent one.
Hope this helps. Don't hesitate to ask more, I will be glad to help.

Resources