History   View   Links to this page Revision from: 2012 September 7 | 03:08 pm
This is the revision from 2012 September 7 at 03:08 pm   View the current live version of the article.

The variability of design and architecture related resources is quite large. AM resources can be used in many different ways for many different purposes. This specification does not limit the variablility of resource types (beyond what the core specification does).

To support resource usage scenarios like impact analysis within the AM domain and across other domains (i.e. CM, RM, QM) we should define a nubmer of properties that can either be used directly in an AM resource’s ontology or shape, or made equivalent to an exisitng property such that automated or semi automated impact analysis can be carried out.

The CM specification defines a number of properties in the open-services.net namespace: http://open-services.net/bin/view/Main/CmVocabulary

This wiki page will document our discussions of these properties.

Existing Property Sources

http://www.w3.org/2000/01/rdf-schema#

http://www.w3.org/1999/02/22-rdf-syntax-ns#

http://www.w3.org/2002/07/owl#

http://www.w3.org/2003/06/sw-vocab-status/ns#

http://dublincore.org/

http://www.foaf-project.org/

http://usefulinc.com/ns/doap#

http://web.resource.org/rss/1.0/ (http://web.resource.org/rss/1.0/schema.rdf)

http://creativecommons.org/ (http://creativecommons.org/schema.rdf)

RELATIONSHIP: A vocabulary for describing relationships between people http://vocab.org/relationship/.rdf

Some thoughts on recripocating relationships. ie. references / isReferencedBy. Is it important to define both, or can we assume that all relationships has a recipricol? Vishy: DC doesn’t make assumptions that one implies the other. They need to be explicitly stated.

We can’t infer

Example Properties

Name Description URI Comment
Relation A general purpose relationship between two resources. http://purl.org/dc/terms/relation
References A related resource that is referenced, cited, or otherwise pointed to by the described resource. http://purl.org/dc/terms/references
Requires A related resource that is required by the described resource to support its function, delivery, or coherence. http://purl.org/dc/terms/requires
Implements A resource represents an implementation of another resource as a specification. http://open-services.net/ns/am#implements
Generalizes A UML relationship in which one model element (the child) is based on another model element (the parent).. http://open-services.net/ns/am/uml#generalization
Contains The resource is a container that includes the referenced object. http://open-services.net/ns/am#contains Isn’t there an RDF/RDFS concept for this?

Generic OO Properties

Name Description URI Comment
A Kind Of Is a unique member of a group of similar objects.
Is A Is a type of a specific class of objects.
Part Of Is a member of a group of objects that together make up another object.
Has A The inverse of Part Of, indicates that the referenced object is a part of this object.

UML Properties

Relationship Description URI Comment
Abstraction An abstraction relationship is a dependency between model elements that represent the same concept at different levels of abstraction or from different viewpoints. You can add abstraction relationships to a model in several diagrams, including use case, class, and component diagrams.
Aggregation An aggregation relationship depicts a classifier as a part of, or as subordinate to, another classifier.
Association An association relationship is a structural relationship between two model elements that shows that objects of one classifier (actor, use case, class, interface, node, or component) connect and can navigate to objects of another classifier. Even in bidirectional relationships, an association connects two classifiers, the primary (supplier) and secondary (client),
Binding A binding relationship is a dependency relationship that assigns values to template parameters and generates a new model element from the template.
Communication path A communication path is a type of association between nodes in a deployment diagram that shows how the nodes exchange messages and signals.
Composition A composition relationship represents a whole–part relationship and is a type of aggregation. A composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier.
Control flow A control flow is a type of activity edge that models the movement of control from one activity node to another.
Dependency A dependency relationship indicates that changes to one model element (the supplier or independent model element) can cause changes in another model element (the client or dependent model element). The supplier model element is independent because a change in the client does not affect it. The client model element depends on the supplier because a change to the supplier affects the client.
Deploy A deploy relationship shows the specific component that an instance of a single node uses. In a UML model, a deploy relationship typically appears in deployment diagrams.
Directed association A directed association relationship is an association that is navigable in only one direction and in which the control flows from one classifier to another (for example, from an actor to a use case). Only one of the association ends specifies navigability.
Extend An extend relationship between use cases indicates that one use case, the extended use case, can extend another use case, the base use case. An extend relationship has the option of using the extended use case.
Generalization A generalization relationship indicates that a specialized (child) model element is based on a general (parent) model element. Although the parent model element can have one or more children, and any child model element can have one or more parents, typically a single parent has multiple children. In UML 2.0, several classes can constitute a generalization set of another class. Generalization relationships appear in class, component, and use case diagrams.
Implementation An implementation relationship is a specialized type of realization relationship between a classifier and a provided interface. The implementation relationship specifies that the realizing classifier must conform to the contract that the provided interface specifies.
Include An include relationship between use cases specifies that an including (or base) use case requires the behavior from another use case (the included use case). In an include relationship, a use case must use the included use case.
Manifestation A manifestation relationship shows which model elements, such as components or classes, are manifested in an artifact. The artifact manifests, or includes, a specific implementation for, the features of one or several physical software components.
Note attachment A note attachment relationship connects a note or text box to a connector or shape. A note attachment indicates that the note or text box contains information that is relevant to the attached connector or shape.
Object flow An object flow is a type of activity edge that models the flow of objects and data from one activity node to another.
Realization A realization relationship exists between two model elements when one of them must realize, or implement, the behavior that the other specifies. The model element that specifies the behavior is the supplier, and the model element that implements the behavior is the client. In UML 2.0, this relationship is normally used to specify those elements that realize or implement the behavior of a component.