Product Information Graph
Properties
▣ pig Ontology Language Diagram
The ontology language (pig-ol) of the Product Information Graph (pig) has the following characteristics:
- There are concepts for entities, relationships and organizers, all being elements of the graph. For example, entity concepts may be Requirement or Function, relationship concepts may be satisfies or refines and organizer concepts may be 'Package', 'Folder' or 'View'. Like entities, the organizers are elements (nodes) of the graph, but the latter are not part of the model and thus no model elements.
- Element concepts (thus entity, relationship or organizer) usually are related to eligible property concepts. E.g. a Requirement would have properties Title, Description and Priority.
- Property concepts may be related to eligible value concepts. For example, a property Priority may have enumerated values high, medium and low.
- A relationship concept may define eligible concepts for source and target. For example, a relationship satisfies may have a source Function or Component and a target Requirement, but nothing else. If no eligible source is specified, all entities are eligible. The same rule applies to eligible targets.
- For The time being, not all attributes of the concepts are shown the diagram.
Note: This class diagram may indeed cause confusion: The concrete classes and the named associations contribute to the semantics of the ontology, whereas the abstract classes and the UML:Generalization are construction aids to simplify the diagram. Thus, an UML:Generalization indicates that all attributes and named associations apply to all of the subordinated classes, whereas associations of type pig-ol:specializesX indicate that one concept is a specialization of another.
Data according to this information model (thus an ontology defined with the classes of the ontology language shown here) can be used to generate the ontology classes in the upper part of the pig Metamodel Diagram:
- A concrete concept (an instantiation of a shown class) becomes a corresponding class with a shape.- For this purpose the concepts shown here must have certain attributes (which are not shown yet) to generate the details needed.
In addition, this information model can be implemented with the pig metamodel. Thus, the same software can be used to edit the ontology based on this ontology language which is used to manage the application data later on:
| Level | | Ontology Definition | | Data Management |
|---|
| Ontology Language | manually → | pig-ol classes | | |
Ontology =
Application Language | | pig-ol instances | → generate → | pig classes |
| Application | | | | pig instances |
To discuss and validate:
- Shall the ontology language be expressive enough to define the OMG Commons Ontology Library? Consider property restrictions, domains and ranges.
- Similarly, should the IOF be expressible, as well?
- The existing DDP Dictionary and the SpecIF Ontology can be expressed.
- Consider the naming of concept classes: pig-ol:Resource instead of pig-ol:Entity and pig-ol:Predicate rather than pig-ol:Relationship?
Properties
| Element Type | Diagram |
| Notation | UML Class Diagram |
Statements
▣ pig Metamodel Diagram
The metamodel is a 'platform independent model' in OMG terms and defines both the classes (above the dashed line) and their instances (below the dashed line) for the Product Information Graph (PIG). Both the classes and the instances are data:
- pig:Entity and pig:anEntity are used for model elements, such as a requirement, a function or a system component.
- pig:Relationship and pig:aRelationship are used for relations between elements, such as a 'system component satisfies a requirement'. A relationship class may define the classes of entities or relationships, whose instances are eligible as source or target in a directed relationship.
- pig:Organizer and pig:anOrganizer are used for diagrams, chapters, folders or similar with references to any pig:Element, which is an entity, relationship or organizer. An organizer class may define the classes of entities, relationships or organizers, whose instances are eligible to be referenced (i.e. organized).
- Every pig:Organizer, pig:Entity and pig:Relationship can define an individual set of pig:Property, each of which specifies a data type and range. For example, a requirement might have three properties, such as a „Title“ with data type „String of max. length 96“, a „Description“ with data type „String“ without restriction and a „Priority“ with data type „String with a single choice of ['high', 'medium', 'low']“.
- A data type may be any of those known from XML. As described above, some parameters may restrict the value range, such as minimum and/or maximum value of a number, a string length or a set of enumerated values.
- pig:anOrganizer, pig:anEntity or pig:aRelationship is an instance of a pig:Organizer, pig:Entity or pig:Relationship respectively. Each instance usually has a set of pig:aProperty corresponding with the pig:Property of its class.
Note:
- The prefixes 'pig*', 'sh*' and 'dcterms*' designate namespaces. In other technical environments such as RDF, XML and JSON, a namespace would be separated with ':' more appropriately, which may lead to confusion in UML. The separator '*' may be replaced during transformation.
- As usual, the classes with white background and italic name are abstract.
Properties
| Element Type | Diagram |
| Notation | UML Class Diagram |
Statements
pig:ModelElement
A superclass of all model elements with class pig:Entity and pig:Relationship.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
pig:Relationship
pig:Relationship is a class of relationships between two entities, such as a 'system component satisfies a requirement'. All relationships are bilateral and directed. This allows for statements according to propositional logic. They can be easily mapped to many technologies such as RDF or ReqIF.
Details:
- A pig:relationship must have a title (name) and may have a description (definition).
- A pig:relationship lists zero to many property classes its instances may have.
- A pig:relationship may define entitiy classes or relationship classes, whose instances are eligible as source resp. target in a relationship. If none are defined, all entities and relationships are eligible.
- A pig:relationship is reified (as a rdfs:Resource in RDF), so that it can be a source or target of another relationship as described before ... to make a statement on a statement.
- The definitions of the relationship together with those of the properties may be used to build user dialogs and to check its instances whether all properties have a correct type and value range as well as whether all required ones are present.
Properties
Statements
☆ pig:aModelElement
A superclass of pig:anEntity and pig:aRelationship. Thus, an instance of pig:aRelationship may be related to any pig:anEntity or pig:aRelationship with pig:hasSoure and pig:hasTarget.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
☆ pig:aRelationship
Is used for relations between entities, such as a 'system component satisfies a requirement'. All relationships are bilateral and directed.
Details:
- This is a reified graph edge and must have exactly one source and target entity each. The source must be an entity or relationship with a class defined by an eligible source class of its pig:Relationship. The same applies for the target.
- A relationship may have zero to many properties as defined in its class.
Properties
Statements
☆ pig:Property
Every class pig:Entity, pig:Relationship and pig:Organizer can have an individual set of pig:Property, each of which is uniquely defined by a data type and range. For example, a requirement might have a list with three pig:Property, such as Title with data type „String of max. length 96“, Description with data type „String“ wíthout length restriction and Priority with data type „String with a single choice of ['high', 'medium', 'low']“.
Details:
- A property class must have a title named dcterms:title and may have a description named dcterms:description.
- A property class may define a minimum and maximum count of values.
- A property class may define a default value which must of course satisfy its own data type.
- A property class may be composed of multiple property classes to form a structured data type (xs:complexType). The structure must be a tree, i.e without cyclic dependency.
Properties
Statements
○ sh:datatype
One of the xs: data types. Shall be anyURI.
Properties
Statements
○ sh:minCount
tbd: Use 'xs:minOccurs' instead?
Properties
Statements
○ sh:maxCount
tbd: Use 'xs:maxOccurs' instead?
Properties
Statements
○ sh:maxLength
Properties
Statements
○ sh:pattern
A Regular Expression that must evaluate successfully with the property value. Can also be used to limit the number of decimals of a number, as there is no restriction like xs:fractionDigits in SHACL.
Properties
Statements
○ sh:minInclusive
Properties
Statements
○ sh:maxInclusive
Properties
Statements
○ sh:defaultValue
Optional default value(s) in case a modelElement's property does not have an individual value. It must follow the definitions of the PropertyClass, of course.
Here, the attribute is named 'sh:defaultValue' for clarity and may just be called 'values' in an implementation, as all restrictions and operations of a property's values apply.
Properties
Statements
☆ pig:aProperty
Each property belongs to a single entity, relationship or organizer. A property has no identifier, thus a property update results in a new revision of the element to which it belongs.
Details:
- A property may be required or not depending on the attributes sh:minCount and sh:maxCount of its class, but an existing property must have a value.
- A property may be composed of multiple properties to form a structured data set according to its class pig:Property.
Properties
Statements
○ pig:value
Properties
Statements
pig:Entity
pig:Entity is a class of model elements, such as a system component or a requirement.
Details:
- A pig:entity should have a title (name) and may have a description (definition).
- A pig:entity lists one to many classes of properties its instances may have. (No pig:property at all is formally allowed to be consistent with other elements, but an entitiy without property has no reason to exist.)
- The definitions of the entity together with those of the properties may be used to build user dialogs and to check its instances whether all property values have a correct type and value range as well as whether all required ones are present.
Properties
Statements
☆ pig:anEntity
Is used for model elements such as a system component or a requirement.
Details:
- An entity should have at least one property as properties are the only payload an entity can carry. (No property at all is formally allowed to be consistent with other elements, but an entity without property has no reason to exist.)
- The entity's class lists the classes of properties it may have.
Properties
Statements
☆ pig:aHierarchyRoot
Anchors hierarchies (trees) whose leaves point to a pig:Entity each. Thus, hierarchies with their items organize entities for a given target group or purpose, such as a bill of material (BoM) or a document outline. A given entity may be referenced by none, one or multiple items in one or more hierarchies.
Properties
☆ pig:Identifiable
All specializations are identifiable and under revision control.
Details:
- The class is abstract.
- All attributes are inherited by its subclasses.
Properties
Statements
○ pig:id
Properties
Statements
○ pig:revision
Properties
Statements
○ pig:priorRevision
Links to the previous revisions of the identifiable item. It is a list with
- zero elements, if it is the first revision,
- one element for a subsequent revision or
- two elements when two branches are merged.
Properties
Statements
○ dcterms:modified
Properties
Statements
○ dcterms:creator
Properties
Statements
○ dcterms:title
Properties
Statements
○ dcterms:description
Properties
Statements
☆ pig:Element
A superclass of pig:Entity (class of entities), pig:Relationship (class of relationships) and pig:Organizer (class of package, folder, view etc.). Any of those classes may be selected by a pig:Organizer to restrict the eligible elements. Thus, a folder class may be defined allowing its instances to contain activity diagrams and activities, but not any other.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
○ pig:icon
Properties
Statements
pig:Organizer
pig:OrganizerClass is used for types of diagrams, chapters, folders and similar with links to any pig:Element, which is an entity, relationship or organizer.
Details:
- An organizer class must have a title (name) and may have a description (definition).
- An organizer class lists zero to many classes of properties its instances may have.
- An organizer class may define the classes of entities, relationships or organizers, whose instances are eligible to be linked (i.e. organized). If none are defined, all entities, relationships and organizers are eligible.
- The definitions of the organizer class together with those of the property classes may be used to build user dialogs and to check its instances whether all properties have a correct type and value range as well as whether all required ones are present.
Properties
Statements
☆ pig:anElement
A superclass of pig:anEntity, pig:aRelationship and pig:Organizer. Thus, an instance of pig:Organizer may be related with pig:hasElement to any instance of pig:anEntity, pig:aRelationship or pig:anOrganizer, as long as the related element's class is among the pig:Organizer's eligible element classes.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
☆ pig:anOrganizer
Is used for diagrams, chapters, folders and similar with references to any pig:anElement, which is an entity, relationship or organizer. An organizer class may define the classes of entities, relationships or organizers, whose instances are eligible to be refernced (i.e. organized).
Details:
- An organizer must have at least one refernce to an entity, relationship or organizer with a class defined in its pig:Organizer. If none is defined, all entities, relationships and organizers are eligible.
- A organizer may have zero to many properties as defined in its class.
Properties
Statements
☆ pig-ol:Organizer
Is a concept used for an organizer which is a special graph element. An organizer is an element organizing model elements. An example is a list of requirements or a diagram using a certain notation which depicts selected model elements.
Properties
Statements
☆ pig-ol:Entity
Is a concept used for an entity which is a special graph element. An entity is a model element representing a resource or object.
Properties
Statements
☆ pig-ol:Relationship
Is a concept used for a relationship which is a special graph element. A relationship is a model element representing a statement on two resources or relation between two objects.
Properties
Statements
○ pig-ol:Name-hasSource
Name for the objectProperty pointing at the source of the relationship.
Properties
Statements
○ pig-ol:Name-hasTarget
Name for the objectProperty pointing at the target of the relationship.
Properties
Statements
☆ pig-ol:Property
A property such as Title, Description or Priority.
Properties
Statements
○ sh:minCount
tbd: Use 'xs:minOccurs' instead?
Properties
Statements
○ sh:maxCount
tbd: Use 'xs:maxOccurs' instead?
Properties
Statements
☆ pig-ol:Value
A value such as high or low for use with a property named Priority. Values can only be assigned to leaves in a complex (= composed) property.
Properties
Statements
☆ pig-ol:Concept
A concept is a unit of knowledge created by a unique combination of characteristics. It corresponds to a mvf:Entry, see Multiple Vocabulary Facility (MVF).
A concept is considered a normalized (cross-domain) term in the Product Information Graph and can be replaced by a term used in a certain domain or community for display. A concept name (= title) usually is given with a namespace.
Properties
Statements
○ rdfs:label
Properties
Statements
○ rdfs:comment
Properties
Statements
☆ pig-ol:Element
Is a concept used for a graph element, namely an entity, relationship or organizer.
Properties
Statements
☆ pig-ol:ModelElement
Properties
Statements
Model Elements (Glossary)
Properties
| Element Type | Model Elements (Glossary) |
○ dcterms:creator
Properties
Statements
○ dcterms:description
Properties
Statements
○ dcterms:modified
Properties
Statements
○ dcterms:title
Properties
Statements
☆ pig-ol:Concept
A concept is a unit of knowledge created by a unique combination of characteristics. It corresponds to a mvf:Entry, see Multiple Vocabulary Facility (MVF).
A concept is considered a normalized (cross-domain) term in the Product Information Graph and can be replaced by a term used in a certain domain or community for display. A concept name (= title) usually is given with a namespace.
Properties
Statements
☆ pig-ol:Element
Is a concept used for a graph element, namely an entity, relationship or organizer.
Properties
Statements
☆ pig-ol:Entity
Is a concept used for an entity which is a special graph element. An entity is a model element representing a resource or object.
Properties
Statements
☆ pig-ol:ModelElement
Properties
Statements
○ pig-ol:Name-hasSource
Name for the objectProperty pointing at the source of the relationship.
Properties
Statements
○ pig-ol:Name-hasTarget
Name for the objectProperty pointing at the target of the relationship.
Properties
Statements
☆ pig-ol:Organizer
Is a concept used for an organizer which is a special graph element. An organizer is an element organizing model elements. An example is a list of requirements or a diagram using a certain notation which depicts selected model elements.
Properties
Statements
☆ pig-ol:Property
A property such as Title, Description or Priority.
Properties
Statements
☆ pig-ol:Relationship
Is a concept used for a relationship which is a special graph element. A relationship is a model element representing a statement on two resources or relation between two objects.
Properties
Statements
☆ pig-ol:Value
A value such as high or low for use with a property named Priority. Values can only be assigned to leaves in a complex (= composed) property.
Properties
Statements
☆ pig:aModelElement
A superclass of pig:anEntity and pig:aRelationship. Thus, an instance of pig:aRelationship may be related to any pig:anEntity or pig:aRelationship with pig:hasSoure and pig:hasTarget.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
☆ pig:anElement
A superclass of pig:anEntity, pig:aRelationship and pig:Organizer. Thus, an instance of pig:Organizer may be related with pig:hasElement to any instance of pig:anEntity, pig:aRelationship or pig:anOrganizer, as long as the related element's class is among the pig:Organizer's eligible element classes.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
☆ pig:anEntity
Is used for model elements such as a system component or a requirement.
Details:
- An entity should have at least one property as properties are the only payload an entity can carry. (No property at all is formally allowed to be consistent with other elements, but an entity without property has no reason to exist.)
- The entity's class lists the classes of properties it may have.
Properties
Statements
☆ pig:anOrganizer
Is used for diagrams, chapters, folders and similar with references to any pig:anElement, which is an entity, relationship or organizer. An organizer class may define the classes of entities, relationships or organizers, whose instances are eligible to be refernced (i.e. organized).
Details:
- An organizer must have at least one refernce to an entity, relationship or organizer with a class defined in its pig:Organizer. If none is defined, all entities, relationships and organizers are eligible.
- A organizer may have zero to many properties as defined in its class.
Properties
Statements
☆ pig:aProperty
Each property belongs to a single entity, relationship or organizer. A property has no identifier, thus a property update results in a new revision of the element to which it belongs.
Details:
- A property may be required or not depending on the attributes sh:minCount and sh:maxCount of its class, but an existing property must have a value.
- A property may be composed of multiple properties to form a structured data set according to its class pig:Property.
Properties
Statements
☆ pig:aRelationship
Is used for relations between entities, such as a 'system component satisfies a requirement'. All relationships are bilateral and directed.
Details:
- This is a reified graph edge and must have exactly one source and target entity each. The source must be an entity or relationship with a class defined by an eligible source class of its pig:Relationship. The same applies for the target.
- A relationship may have zero to many properties as defined in its class.
Properties
Statements
☆ pig:Element
A superclass of pig:Entity (class of entities), pig:Relationship (class of relationships) and pig:Organizer (class of package, folder, view etc.). Any of those classes may be selected by a pig:Organizer to restrict the eligible elements. Thus, a folder class may be defined allowing its instances to contain activity diagrams and activities, but not any other.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
pig:Entity
pig:Entity is a class of model elements, such as a system component or a requirement.
Details:
- A pig:entity should have a title (name) and may have a description (definition).
- A pig:entity lists one to many classes of properties its instances may have. (No pig:property at all is formally allowed to be consistent with other elements, but an entitiy without property has no reason to exist.)
- The definitions of the entity together with those of the properties may be used to build user dialogs and to check its instances whether all property values have a correct type and value range as well as whether all required ones are present.
Properties
Statements
○ pig:icon
Properties
Statements
○ pig:id
Properties
Statements
☆ pig:Identifiable
All specializations are identifiable and under revision control.
Details:
- The class is abstract.
- All attributes are inherited by its subclasses.
Properties
Statements
pig:ModelElement
A superclass of all model elements with class pig:Entity and pig:Relationship.
Details:
- The class is abstract.
- All attributes and associations are inherited by its subclasses.
Properties
Statements
pig:Organizer
pig:OrganizerClass is used for types of diagrams, chapters, folders and similar with links to any pig:Element, which is an entity, relationship or organizer.
Details:
- An organizer class must have a title (name) and may have a description (definition).
- An organizer class lists zero to many classes of properties its instances may have.
- An organizer class may define the classes of entities, relationships or organizers, whose instances are eligible to be linked (i.e. organized). If none are defined, all entities, relationships and organizers are eligible.
- The definitions of the organizer class together with those of the property classes may be used to build user dialogs and to check its instances whether all properties have a correct type and value range as well as whether all required ones are present.
Properties
Statements
○ pig:priorRevision
Links to the previous revisions of the identifiable item. It is a list with
- zero elements, if it is the first revision,
- one element for a subsequent revision or
- two elements when two branches are merged.
Properties
Statements
☆ pig:Property
Every class pig:Entity, pig:Relationship and pig:Organizer can have an individual set of pig:Property, each of which is uniquely defined by a data type and range. For example, a requirement might have a list with three pig:Property, such as Title with data type „String of max. length 96“, Description with data type „String“ wíthout length restriction and Priority with data type „String with a single choice of ['high', 'medium', 'low']“.
Details:
- A property class must have a title named dcterms:title and may have a description named dcterms:description.
- A property class may define a minimum and maximum count of values.
- A property class may define a default value which must of course satisfy its own data type.
- A property class may be composed of multiple property classes to form a structured data type (xs:complexType). The structure must be a tree, i.e without cyclic dependency.
Properties
Statements
pig:Relationship
pig:Relationship is a class of relationships between two entities, such as a 'system component satisfies a requirement'. All relationships are bilateral and directed. This allows for statements according to propositional logic. They can be easily mapped to many technologies such as RDF or ReqIF.
Details:
- A pig:relationship must have a title (name) and may have a description (definition).
- A pig:relationship lists zero to many property classes its instances may have.
- A pig:relationship may define entitiy classes or relationship classes, whose instances are eligible as source resp. target in a relationship. If none are defined, all entities and relationships are eligible.
- A pig:relationship is reified (as a rdfs:Resource in RDF), so that it can be a source or target of another relationship as described before ... to make a statement on a statement.
- The definitions of the relationship together with those of the properties may be used to build user dialogs and to check its instances whether all properties have a correct type and value range as well as whether all required ones are present.
Properties
Statements
○ pig:revision
Properties
Statements
○ pig:value
Properties
Statements
○ rdfs:comment
Properties
Statements
○ rdfs:label
Properties
Statements
○ sh:datatype
One of the xs: data types. Shall be anyURI.
Properties
Statements
○ sh:defaultValue
Optional default value(s) in case a modelElement's property does not have an individual value. It must follow the definitions of the PropertyClass, of course.
Here, the attribute is named 'sh:defaultValue' for clarity and may just be called 'values' in an implementation, as all restrictions and operations of a property's values apply.
Properties
Statements
○ sh:maxCount
tbd: Use 'xs:maxOccurs' instead?
Properties
Statements
○ sh:maxInclusive
Properties
Statements
○ sh:maxLength
Properties
Statements
○ sh:minCount
tbd: Use 'xs:minOccurs' instead?
Properties
Statements
○ sh:minInclusive
Properties
Statements
○ sh:pattern
A Regular Expression that must evaluate successfully with the property value. Can also be used to limit the number of decimals of a number, as there is no restriction like xs:fractionDigits in SHACL.
Properties
Statements