├── .github ├── ISSUE_TEMPLATE │ └── issue-template.md └── issue_template.md ├── Assets ├── DevelopmentProcess.svg └── medium-oih-einzeilig-zentriert.jpg ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── Decisions ├── Closed │ └── DecisionsMade.md └── README.md ├── LICENSE ├── MasterDataModels ├── Addresses │ ├── AddressModelV2Description.md │ ├── Assets │ │ ├── Archive │ │ │ ├── DataModelSnazzyContacts.png │ │ │ ├── ER-Persons-relations-organizations.png │ │ │ ├── ER-Persons-relations-persons.png │ │ │ ├── ER-organizations-relations-organizations.png │ │ │ ├── OIHDataModelAddresses.svg │ │ │ ├── masterdatamodel-procedure.png │ │ │ ├── postal_adress_diagram_upus42.png │ │ │ ├── relations-among-persons.png │ │ │ ├── relations-of-organizations.png │ │ │ ├── types-of-addresses.png │ │ │ ├── typing-of-addresses.png │ │ │ └── use-case-relationship-person-organization.png │ │ ├── MasterDataModelAddressV2.svg │ │ ├── RelationshipsBetweenOrganizations.png │ │ ├── RelationshipsBetweenOrganizationsAndPersons.png │ │ └── RelationshipsBetweenPersons.png │ ├── DatamappingAddresses.md │ ├── MappingTableSnazzyContactsAddressModel.md │ ├── MasterDataModelAdresses.md │ ├── README.md │ └── UseCasesAndBestPractices.md ├── Assets │ ├── AggregateExample.svg │ ├── DataRecordOrderExample.svg │ ├── OIHDataRecord.svg │ └── OihMessageHeader.svg ├── Collaborations │ ├── Assets │ │ ├── OIH collaboration.png │ │ ├── OIH collaboration.svg │ │ └── readme.md │ ├── CollaborationModelDescription.md │ ├── Protocols │ │ └── 2018-07-31WorkgroupCall.md │ └── README.md ├── Documents │ ├── Assets │ │ ├── OIHDataModelDocumentMetadataSpecification.svg │ │ ├── OIHDataModelDocuments.svg │ │ └── OIH_Documents_Basic_Model.png │ ├── DocumentModelDescription.md │ ├── DocumentModelMetadataDescription.md │ ├── DocumentOperations.md │ └── README.md ├── MetaModel.md ├── Products │ ├── Assets │ │ ├── MasterDataModelProductsV2.svg │ │ ├── OIHDataModelProducts.svg │ │ └── productModelV2.svg │ ├── DatamappingProducts.md │ ├── MasterDataModelProducts.md │ ├── ProductModelDescriptionTable.md │ └── README.md ├── README.md ├── ReadmeTemplate.md ├── UserStories.md └── Versioning │ ├── Assets │ ├── change_request.svg │ ├── change_request.xml │ ├── realization.svg │ └── realization.xml │ ├── DataModelChanges.md │ ├── SpecializedDataModelsExample.md │ └── VersioningMasterDataModel.md ├── Protocols ├── 2017-03-23WorkgroupTelko.md ├── 2017-10-16CommitteeInnovationAgenda.pdf ├── 2017-10-16CommitteeInnovationWorkshop.md ├── 2017-11-29Workshop.md ├── 2017-12-11Telko.md ├── 2017-12-11WorkgroupCall.md ├── 2017-12-15WorkgroupCall.md ├── 2017-12-15WorkgroupTelko.md ├── 2017-12-19WorkgroupCall.md ├── 2017-12-19WorkgroupTelko.md ├── 2017-12-21WorkgroupCall.md ├── 2017-12-21WorkgroupTelko.md ├── 2018-01-02WorkgroupCall.md ├── 2018-01-02WorkgroupTelko.md ├── 2018-01-17Workshop.md ├── 2018-02-23WorkgroupCall.md ├── 2018-02-23WorkgroupTelko.md ├── 2018-03-23WorkgroupCall.md ├── 2018-04-06WorkgroupCall.md ├── 2018-04-06WorkgroupTelko.md ├── 2018-05-29CollaborationAndDocumentsCall.md ├── 2018-06-12CollaboratioAndDocumentsCall.md ├── 2018-07-17CommonWorkgroupCall.md ├── 2018-07-24UserTenantsRightsWorkgroupCall.md ├── 2018-07-30CommonWorkgroupCall.md ├── 2018-07-30DocumentsWorkgroupCall.md ├── 2018-08-13CommonWorkgroupCall.md ├── 2018-08-27CommonWorkgroupCall_Documents.md ├── 2019-08-21UserTenantsRightsWorkgroupCall.md ├── Assets │ └── SmartDataFramework.svg ├── MeetingAgenda.docx └── TEMPLATE.md ├── README.md └── src ├── examples └── schema │ └── order.json ├── main └── schema │ ├── addresses │ ├── V1 │ │ ├── organization.json │ │ ├── person.json │ │ ├── relation.json │ │ └── shared-definitions.json │ ├── organizationV2.json │ ├── personV2.json │ ├── relationsV2.json │ └── sharedDefinitionsV2.json │ ├── collaboration │ ├── calendarEvent.json │ ├── collaborationElement.json │ ├── email.json │ ├── task.json │ └── taskToTaskRelation.json │ ├── documents │ └── extended │ │ ├── Document.json │ │ ├── Folder.json │ │ ├── Object.json │ │ ├── Relation.json │ │ └── sharedDefinitions.json │ ├── oih-data-record.json │ └── products │ └── product.json └── xml ├── DataRecordOrderExample.xml ├── Document Model.xml ├── OIH collaboration.xml ├── OihDataRecord.xml └── productModelV2.xml /.github/ISSUE_TEMPLATE/issue-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Issue Template 3 | about: Used to create similar structured issues across all contributors 4 | 5 | --- 6 | 7 | As a _user type_, I want to _task_ so that _goal_. 8 | 9 | _Further description_ 10 | 11 | --- 12 | 13 | **Acceptance Criteria:** 14 | - [ ] Criteria 1 15 | - [ ] Criteria 2 16 | - [ ] Criteria N 17 | 18 | --- 19 | 20 | [**Definition of Done**](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/CONTRIBUTING.md#definition-of-done) 21 | -------------------------------------------------------------------------------- /.github/issue_template.md: -------------------------------------------------------------------------------- 1 | As a _user type_, I want to _task_ so that _goal_. 2 | 3 | _Further description_ 4 | 5 | --- 6 | 7 | **Acceptance Criteria:** 8 | - [ ] Criteria 1 9 | - [ ] Criteria 2 10 | - [ ] Criteria N 11 | 12 | --- 13 | 14 | [**Definition of Done**](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/CONTRIBUTING.md#definition-of-done) 15 | 16 | -------------------------------------------------------------------------------- /Assets/DevelopmentProcess.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | Master Data ModelAdapterTransformer2nd Step1st Step3rd StepDevelopment Process -------------------------------------------------------------------------------- /Assets/medium-oih-einzeilig-zentriert.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/Assets/medium-oih-einzeilig-zentriert.jpg -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, gender identity and expression, level of experience, 9 | education, socio-economic status, nationality, personal appearance, race, 10 | religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at dennis.steiniger@cloudecosystem.org. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contribution Guideline 2 | 3 | **Table of Content** 4 | 5 | 6 | - [Getting started](#getting-started) 7 | - [Definition of Done](#definition-of-done) 8 | - [Contributing a new data model](#contributing-a-new-data-model) 9 | - [Naming Conventions](#naming-conventions) 10 | - [Types and Properties](#types-and-properties) 11 | - [JSON-Schema](#json-schema) 12 | - [UML Class Diagrams](#uml-class-diagrams) 13 | - [Clarify all further aspects of a model with diagrams and/or textually](#clarify-all-further-aspects-of-a-model-with-diagrams-andor-textually) 14 | 15 | 16 | 17 | # Getting started 18 | If you plan to make your first contribution, please start with the [**Contributor Guide**](https://github.com/openintegrationhub/BusinessCommittee/tree/master/Contributing/Guide) for general information about making contributions to the Open Integration Hub project. 19 | 20 | The following represent additional rules specifically for contributions in this workgroup and repository. 21 | 22 | # Definition of Done 23 | An issue is marked as done, if all of the following criteria are fulfilled: 24 | 25 | - All acceptance criteria have been fulfilled 26 | - All Workgroup committer approved the content 27 | - Content is Open Source under https://www.github.com/openintegrationhub/data-and-domain-models 28 | 29 | 30 | # Contributing a new data model 31 | 32 | The OIH is an open-source platform maintained by the cloud community under the leadership of the [Cloud Ecosystem](http://www.cloudecosystem.org). It can be run with any model which is designed and implemented by the rules and regulations listed so far. 33 | 34 | In addition to the OIH platform itself, the OIH community also provides and maintains a number of concrete Master Data Models to be used by any OIH instance, such as models for contacts/addresses or products. 35 | 36 | For these models, there are some further rules and regulations to follow in order to be presented in a unified way. This helps to understand and, above all, use them (i.e., implementing OIH Connectors for applications to be integrated with - respectively via - an OIH). 37 | 38 | ## Organisatory 39 | 40 | * Create a new folder within the _MasterDataModel folder_ and name it equally to the domain the model is provided for 41 | * The first page of the folder has to follow the structure of the [ReadmeTemplate](MasterDataModels/ReadmeTemplate.md) to guarantee a unified description of all master data models 42 | 43 | ## Naming Conventions 44 | 45 | ### Types and Properties 46 | 47 | * __All type and property naming has to be in CamelCase:__ 48 | * Type names are always spelled in _upper_ camel case (e.g., UpperCamelCaseType). 49 | * Property names are always spelled in _lower_ camel case (e.g., lowerCamelCaseProperty). 50 | * __All type and property naming has to be done in English language.__ 51 | * __The prefixes _OIH_ and *OIH_* (or _oih_ and *oih_* for properties) are reserved for types and properties of OIH related Types and fields and may not be used for definitions in concrete models.__ 52 | 53 | Some attributes are used across multiple models (such as "description"). To ensure consistency across all models, some of these attributes and how they should be named wihtin OIH Data Models are listed in the following: 54 | 55 | |OIH Attribute Name|Other frequently used synonyms|Description| 56 | |:--|:--|:--| 57 | |deleted|deleted, removed|Flag to mark a dataset as deleted or removed| 58 | |type|type, baseType, productType, setType, ...| Used to describe the specifc object. **Expection**: Two or more types attributes are needed for one object| 59 | |notes|notes, note, additionalInformation, extraInformation, etc.|Used to provide additional information for the specific object (beyond description)| 60 | |url| url, link|Used for all kind of links associated with the specific object| 61 | |value|value, data|Used for the acutal content of a specific object E.g. in classical pair. (Example: Contact Data (Type: Email, Value: ...@example.com"))| 62 | |is...|All boolean attributes without `is`|Attributes of type boolean. Should be labeled starting with `is`. E.g. "isProduction", "isDirect", "isExact"| 63 | |tags|flags, labels|Attribute which assigns different descriptive buzzwords to an object| 64 | 65 | 66 | ### JSON-Schema 67 | 68 | * __Schema file names are always lowercase__. 69 | * __As a seperator within file names a hyphen (-) may be used__ (e.g. _some-schema.json_). 70 | * __The schema-ID (the _$id_ property in a JSON-Schema) is always structured as follows:__ 71 | * The global context is _http://openintegrationhub.org/schemas/_ 72 | * followed by a context directory and the name of the schema file (including the _.json_ suffix) 73 | 74 | Example: ```"$id": "http://openintegrationhub.org/schemas/products/product.json"``` 75 | * __Every field in a JSON-Schema must have a _description_ property__, as long as it's (even potentially) not self-explanatory. 76 | 77 | 78 | ## UML Class Diagrams 79 | 80 | * __Every OMDM must be depicted by one or more UML Class Diagrams__, which illustrate the static aspect of the model. I.e., amongst others: 81 | * of which different OIH Data Records and entities (types) the OMDM constists, 82 | * how every OIH Data Record itself is composed, 83 | * how the OIH Data Records are related to each other, 84 | * which properties every entity (type) has. 85 | * __Every OIH Data Record is defined by a Generalization relation__ (_OIHDataRecord_ is modelled as the superclass of the respective sub-model, s. [5. Example: the Order aggregate](#5-example-the-order-aggregate)). 86 | * __Property types may, but must not be declared__ in the diagrams as the main purpose of these diagrams is to clarify the structure of an OMDM. 87 | 88 | * Following the Domain-Driven-Design all _standalone_ objects (such as _person_ and _organization_ within the address model) should be coloured in yellow 89 | * Other attributes should be coloured in blue (See: [Address model](/MasterDataModels/Addresses#uml-diagram)) 90 | 91 | 92 | ## Clarify all further aspects of a model with diagrams and/or textually 93 | 94 | Schemas and class diagrams only point out static aspects of a data model. Normally, there are further (e.g. dynamic) aspects of a model, that those descriptions do not point out (e.g. the conscious acceptance of redundancy). To enable ISVs and any other developers to understand and work with an OMDM, 95 | 96 | * __all relevant aspects of a model, that are not derivable from JSON-Schemas or UML Class Diagrams have to be described textually and by further illustrations of any kind.__ 97 | 98 | 99 | 100 | -------------------------------------------------------------------------------- /Decisions/Closed/DecisionsMade.md: -------------------------------------------------------------------------------- 1 | # Decisions 2 | 3 | This document is a record of all data & domain model decisions made by the committers of this workgroup. 4 | It aims at creating a consistent knowledge base and understanding of the project. 5 | 6 | ## Schema Definition Language (meta-models) 7 | 8 | JSON schema is used as the schema definition language to describe meta-models. 9 | 10 | The schema was unanimously chosen by the committers within the [issue on the schema definition language](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/5). 11 | 12 | ## UML diagram tool (class-diagrams) 13 | 14 | Visual Paradigm is used as the UML diagram tool to draw class diagrams. 15 | 16 | The tool was unanimously chosen by the committers within the [Suggest tools for creating UML-Diagrams](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/17) 17 | -------------------------------------------------------------------------------- /Decisions/README.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/DataModelSnazzyContacts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/DataModelSnazzyContacts.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/ER-Persons-relations-organizations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/ER-Persons-relations-organizations.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/ER-Persons-relations-persons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/ER-Persons-relations-persons.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/ER-organizations-relations-organizations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/ER-organizations-relations-organizations.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/masterdatamodel-procedure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/masterdatamodel-procedure.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/postal_adress_diagram_upus42.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/postal_adress_diagram_upus42.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/relations-among-persons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/relations-among-persons.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/relations-of-organizations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/relations-of-organizations.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/types-of-addresses.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/types-of-addresses.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/typing-of-addresses.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/typing-of-addresses.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/Archive/use-case-relationship-person-organization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/Archive/use-case-relationship-person-organization.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/RelationshipsBetweenOrganizations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/RelationshipsBetweenOrganizations.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/RelationshipsBetweenOrganizationsAndPersons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/RelationshipsBetweenOrganizationsAndPersons.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/Assets/RelationshipsBetweenPersons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Addresses/Assets/RelationshipsBetweenPersons.png -------------------------------------------------------------------------------- /MasterDataModels/Addresses/DatamappingAddresses.md: -------------------------------------------------------------------------------- 1 | # Data-Mapping of Addresses 2 | 3 | This Document describes the evaluations of the data-mapping of the addresses 4 | within the Open Integration Hub. 5 | 6 | # Why is data-mapping necessary? 7 | 8 | One of the fundamental problems of the integration of data is the data-mapping. 9 | Data-Mapping is the process which moves different elements of data between 10 | different models of data. There are different ways to resolve this task. 11 | 12 | A datamodel is a model which describes the data and its elements of a specific 13 | domain, in this case the domain "addresses". The integration of addressdata is 14 | one of the main tasks of the whole OIH-Project. It's a fundamental and critical 15 | function of the Open Integration Hub. 16 | 17 | The data-mapping is necessary for the OIH, because most of the time the object 18 | models of addressdata are similar, but in detail different. The data is similar, 19 | but the structure is different. You see datasources which contains failures or 20 | dublettes or you for example can't see automatically if the specific element is 21 | a surname or not. Traditionally the mapping is hand-coded, where the data is 22 | copied between the objects. This is not very efficient and uses much resources. 23 | On the long run an algorithmic way would be more efficient. 24 | 25 | **Possible solutions for data-mapping of addresses** 26 | 27 | Algorithmic data-mapping can be put in different ways in function. 28 | You can implement it via procedural code, you can use xslt-transformations or 29 | with graphical mapping-tools, which build the code for the transformation. 30 | 31 | With graphical tools you can draw lines between the fields of data structure. 32 | Intelligent tools are able to see the relations between those fields by their 33 | name or values. From the defined relations they are generating SQL, XSLT or 34 | programm code. These tools are most of the times part of etl-tools (Extrac, 35 | Transform, Load). 36 | 37 | For semantic mapping you can use metadata collections. These collections extend 38 | the automatic identification of the relations of the graphical tools to see 39 | possible synonyms. For example if on data source contains of a delivery address and 40 | another one a billing address. Then the semantic mapping tool can acknowledge, 41 | that this are describing the same address, if both of them are listed as a 42 | synonym. But the semantic mapping only reveal the same synonyms and no 43 | transformations, for example the relation of zip code and town. 44 | 45 | A relative new field of research is the data driven mapping. It tries to foresee 46 | the mapping via heuristic evaluation and statistic methods of the data values 47 | of different data sources. The expectation is to see parts of the data, older 48 | collections of data or arithmetic relations or exceptions. 49 | -------------------------------------------------------------------------------- /MasterDataModels/Addresses/MappingTableSnazzyContactsAddressModel.md: -------------------------------------------------------------------------------- 1 | The following table represents a mapping table between the Snazzy Contacts Model and the [Open Integration Hub Master Data Model V2](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/ExtenstionAddressModel/MasterDataModels/Assets/MasterDataModelAddressesV2.svg). 2 | 3 | ## Person Object 4 | |SnazzyContacts Model|Matches|OIH MasterDataModel| 5 | |---|---|---| 6 | |rowid| = |(ApplicationRecord) RecordUid| 7 | |for_rowid||(Will be stored in a PersonToOrganizationRelationship)| 8 | |salutation| = |salutation| 9 | |firstname| = |firstName| 10 | |name| = |lastName| 11 | |birthday| = |birthday| 12 | |private_street| = |(address) street + (address) streetNumber| 13 | |private_zip_code| = |(address) zipcode | 14 | |private_town| = |(address) city| 15 | |private_state| = |(address) region| 16 | |private_country| = |(address) country| 17 | |phone| = |(ContactData) value| 18 | |phone| = |(ContactData) type| 19 | |fax| = |(ContactData) value| 20 | |fax| = |(ContactData) type| 21 | |email| = |(ContactData) value| 22 | |email| = |(ContactData) type| 23 | |url| = |(ContactData) value| 24 | |url| = |(ContactData) type| 25 | 26 | _Note:_ All other OIH MasterDataModel attributes for the person object are not needed. 27 | 28 | **SnazzyContact Model coverage:** ~ 93% (14/15) 29 | 30 | ## Organization Object 31 | 32 | |SnazzyContacts Model|Matches|OIH MasterDataModel| 33 | |---|---|---| 34 | |name| = |organizationName| 35 | |street| = |(address) street| 36 | |street_number| = |(address) streetNumber| 37 | |zip_code| = |(address) zipcode| 38 | |town| = |(address) city| 39 | |state| = |(address) region| 40 | |country| = |(address) country| 41 | |phone| = |(ContactData) value| 42 | |phone| = |(ContactData) type| 43 | |fax| = |(ContactData) value| 44 | |fax| = |(ContactData) type| 45 | |email| = |(ContactData) value| 46 | |email| = |(ContactData) type| 47 | |url| = |(ContactData) value| 48 | |url| = |(ContactData) type| 49 | 50 | _Note:_ All other OIH MasterDataModel attributes for the organization object are not needed. 51 | 52 | **SnazzyContact Model coverage:** 100% (11/11) 53 | -------------------------------------------------------------------------------- /MasterDataModels/Addresses/UseCasesAndBestPractices.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Introduction 4 | This file is designed to present some common use cases and best practices for using the master data model for addresses for the specific use cases. 5 | Each case includes some exemplary user stories as well as a mapping and a short description. 6 | 7 | The cases are seperated by different usage scenarios. 8 | 9 | ## Minimal Scenario 10 | 11 | |User Story Id| User Stories | 12 | |:---| :--- | 13 | |u-AdEx1|As a user I want to synchronize a private person and his/her contact data | 14 | |u-AdEx2|As a user I want to synchronize an organization and his/her contact data | 15 | |u-AdEx3|As a user I want to assign a person to different organizations with different contact data to see different roles or contexts of the same person| 16 | 17 | #### Example Values 18 | #### Person 19 | |Key|Value|Context| 20 | |:---|:---|:---| 21 | |firstName|Jon|-| 22 | |lastName|Doe|-| 23 | |Phone|+49123456789|Private| 24 | |mobilePhone|+499875612|Private| 25 | |EMail|jon.doe@example.com|Private| 26 | 27 | #### Organization 28 | |Key|Value|Context| 29 | |:---|:---|:---| 30 | |name|JDub|-| 31 | |logo|http://www.examplelogo.com|-| 32 | |Phone|+49123456789|Support| 33 | |EMail|support@jdub.com|Support| 34 | 35 | 36 | #### PersonOrganization 37 | 38 | |Key|Value|Context| 39 | |:---|:---|:---| 40 | |firstName|Jon|-| 41 | |lastName|Doe|-| 42 | |Phone|+49123456789|Company1| 43 | |Phone2|+499875612|Company2| 44 | |EMail|jon.doe@example.com|Company1| 45 | 46 | 47 | ### Best Practice 48 | #### u-AdEx1 49 | Just use the needed attributes from the "Person" object and from the "Address" object. The different phone numbers, email addresses and social media accounts are held within different "ContactData" objects. 50 | 51 | #### u-AdEx2 52 | See best [practice for u-Ex1](#u-ex1) but use the "Organization" object instead of the "Person" Object. 53 | 54 | #### u-AdEx3 55 | The link between the person and its organization is a "OrganizationToPersonRelationship". The person itself is held as a duplicate for every specific role and is linked via a "PersonToPersonRelationship" and marked as "SamePerson". 56 | 57 | *** 58 | 59 | ## Using Relations 60 | ### OrganizationToOrganizationRelationships 61 | 62 | |User Story Id| User Stories | 63 | |:---| :--- | 64 | |u-AdEx4|As a user I want to lay down any kind of delivery and / or invoice addresses for my customers, to be able to deliver my goods and my invoices to any location. | 65 | 66 | #### Example Values 67 | 68 | |Key|Value|Context| 69 | |:---|:---|:---| 70 | |name|JDub|-| 71 | |logo|http://www.examplelogo.com|-| 72 | |Phone|+49123456789|Support| 73 | |EMail|support@jdub.com|Support| 74 | |Address1|Examplestreet 99, 50667 Cologne, Germany|Delivery| 75 | |Address2|Examplestreet 90, 50667 Cologne, Germany|Invoice| 76 | 77 | #### Best Practice 78 | ##### u-AdEx4 79 | 80 | The organization itself is held as a duplicate. The different addresses are held within a "Address" object. The link between the organizations is a "OrganizationToOrganizationRelationship" and marked as "delivery address" or "invoice address". 81 | 82 | ### PersonToOrganizationRelationships 83 | 84 | |User Story Id| User Stories | 85 | |:---| :--- | 86 | |u-AdEx5|As a user I want to synchronize a contact person from a company and his/her contact data | 87 | 88 | #### Example Values 89 | |Key|Value|Context| 90 | |:---|:---|:---| 91 | |firstName|Jon|-| 92 | |lastName|Doe|-| 93 | |Phone|+49123456789|Company `JDUB`| 94 | |mobilePhone|+499875612|Company `JDUB`| 95 | |EMail|jon.doe@jdub.com|Company `JDUB`| 96 | |department|B2B Integrations|Company `JDUB`| 97 | |function|Development Lead|Company `JDUB`| 98 | |Address1|Examplestreet 99, 50667 Cologne, Germany|Company `JDUB`| 99 | |Address2|Samplestreet 1, 50931 Cologne, Germany|Private| 100 | 101 | |Key|Value| 102 | |:---|:---| 103 | |name|JDub| 104 | |logo|http://www.examplelogo.com| 105 | 106 | 107 | #### Best Practice 108 | ##### u-AdEx5 109 | You have to use the needed attributes from the "Person" object, from the "Organization" object and from the "Address" object. The different phone numbers, email addresses and social media accounts are held within different "ContactData" objects. The link between the person and its organization is a "OrganizationToPersonRelationship". 110 | 111 | ### PersonToPersonRelationships 112 | 113 | |User Story Id| User Stories | 114 | |:---| :--- | 115 | |u-AdEx6|As a user I want to synchronize two contact persons and their working relationship | 116 | 117 | #### Example Values 118 | |Key|Value|Context| 119 | |:---|:---|:---| 120 | |id|8|-| 121 | |firstName|Jon|| 122 | |lastName|Doe|-| 123 | |supervisor|3|-| 124 | 125 | |Key|Value|Context| 126 | |:---|:---|:---| 127 | |id|3|-| 128 | |firstName|Foo|-| 129 | |lastName|Bar|-| 130 | |supervisor|1|-| 131 | 132 | 133 | |Key|Value| 134 | |:---|:---| 135 | |name|JDub| 136 | |logo|http://www.examplelogo.com| 137 | 138 | 139 | #### Best Practice 140 | ##### u-AdEx6 141 | You have to use the needed attributes from the "Person" object for both persons.The link between the persons is a "OrganizationToPersonRelationship" e.g. with a label = supervisor__. 142 | 143 | *** 144 | 145 | ## Using Duplicates 146 | 147 | |User Story Id| User Stories | 148 | |:---| :--- | 149 | |u-AdEx7|As a user I want to see which person has a role in different organizations| 150 | 151 | 152 | ### Best Practice 153 | #### u-AdEx7 154 | The link between the person and the different organizations is done via the object "OrganizationToPersonRelationship". The person itself is held as a duplicate for every specific role and is linked via a "PersonToPersonRelationship" and marked as "SamePerson". 155 | -------------------------------------------------------------------------------- /MasterDataModels/Collaborations/Assets/OIH collaboration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Collaborations/Assets/OIH collaboration.png -------------------------------------------------------------------------------- /MasterDataModels/Collaborations/Assets/readme.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /MasterDataModels/Collaborations/CollaborationModelDescription.md: -------------------------------------------------------------------------------- 1 | 2 | - [CalendarEvent](#calendarevent) 3 | - [Contacts](#contact) 4 | - [Calendars](#calendar) 5 | - [Threads](#thread) 6 | - [CollaborationElement](#collaborationelement) 7 | - [Attachments](#attachment) 8 | - [Task](#task) 9 | - [Category](#category) 10 | - [TaskToTaskRelation](#tasktotaskrelation) 11 | 12 | 13 | 14 | # Objects 15 | 16 | ## CalendarEvent 17 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 18 | |---|---|---|---|---|---| 19 | |[collaborationElement](#collaborationelement)|Array (of collaborationElement objects)|-|Collaboration properties values|A collaborationElement object array|-| 20 | |[contacts](#contacts)|Array (of contact objects)|-|Contact information of the person|A contact object array|-| 21 | |[calendars](#calendars)|Array (of calendar objects)|-|Calendar connected to contacts|A contact object array|-| 22 | |location|String|-|Name of the location|"Room 123"|-| 23 | |start|Date|-|startdate of the event|01.01.2018|-| 24 | |end|Date|-|enddate of the event|31.12.2018|-| 25 | 26 | ## Contact 27 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 28 | |---|---|---|---|---|---| 29 | |name|String|-|Name of the contact|"John Doe"|-| 30 | |eMail|String|-|E-mail of the contact|"john.doe@email.com"|-| 31 | |[calendars](#calendar)|Array (of calendar objects)|-|Calendar information of the person|A calendar object array|-| 32 | 33 | ## Calendar 34 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 35 | |---|---|---|---|---|---| 36 | |calendar|String|-|URI to the person's calendar|http://cal.example.com/calA|-| 37 | |requestCalendar|String|-|URL to request an appointment with the person|janedoe@example.com|-| 38 | |status|String|-|URL which describes if the person is available or busy|http://www.example.com/busy/janedoe|-| 39 | 40 | ## Email 41 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 42 | |---|---|---|---|---|---| 43 | |[collaborationElements](#collaborationElement)|Array (of collaboration objects)|-|Collaboration properties values|A collaborationElement object array|-| 44 | |[threads](#thread)|Array (of thread objects)|-|thread information of the e-mail|A thread object array|-| 45 | 46 | ## Thread 47 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 48 | |---|---|---|---|---|---| 49 | |threadName|String|-|Name of the Thread|"Subject of the E-Mail"|-| 50 | |topic|String|-|Identification of the thread|randomized string|-| 51 | 52 | ## CollaborationElement 53 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 54 | |---|---|---|---|---|---| 55 | |from|String|-|E-Mail of sender|"john.doe@email.com"|-| 56 | |to|String|-|E-mail of receiver|"jane.doe@email.com"|-| 57 | |cc|String|-|E-mail of the contact in copy|"janet.doe@email.com"|-| 58 | |bcc|String|-|E-mail of the contact in blind copy|"jonathan.doe@email.com"|-| 59 | |subject|String|-|Subject line of the e-mail|"RE: Your Question"|-| 60 | |date|Date|-|Date|01.01.2018|-| 61 | |day|String|Enum|Day of the week|"Monday"|"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"| 62 | |time|Time|-|Timestamp|10:10:10|-| 63 | |messageID|String|-|Id of the message|some token|-| 64 | |language|String|-|Language of the e-mail content|"en"|-| 65 | |authentification|String|-|Authentification Result|"spf=pass smtp.mailfrom=email.com"|-| 66 | |MIMEVersion|Decimal|-|Version of MIME|1.3|-| 67 | |format|String|-|Format of the email content|"HTML"|-| 68 | |content|String|-|Content of the e-mail|"Dear John, please find attached"|-| 69 | |[attachments](#attachment)|Array (of attachment objects)|-|attachment information of the element|An attachment object array|-| 70 | 71 | ## Attachment 72 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 73 | |---|---|---|---|---|---| 74 | |type|String|-|Datatype of the attachment|"JPG"|-| 75 | |size|String|-|Datasize of the e-mail attachment|"54 KB"|-| 76 | 77 | ## Task 78 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 79 | |---|---|---|---|---|---| 80 | |[collaborationElement](#collaborationelement)|Array (of collaborationElement objects)|-|Collaboration properties values|A collaborationElement object array|-| 81 | |[category](#category)|Array (of category objects)|-|category information of the task|A category object array|-| 82 | |[taskToTaskRelation](#tasktotaskrelation)|String|-|Relation between two tasks|"is subtask to"|-| 83 | |subject|String|-|Subject of the Task|"Create a datamodel"|-| 84 | |startDate|Datetime|-|Date when the task starts|01.01.2018 00:00|-| 85 | |endDate|Datetime|-|Date when the task is closed|31.01.2018 00:00|-| 86 | |reminderDate|Datetime|-|Date when the task completion should be reminded|20.01.2018 00:00|-| 87 | |content|String|-|description of the Task|"To create a datamodel we have to analyze different systems..."|-| 88 | |status|String|Enum|status of the Task|"completed"|"started", "in progress", "completed"| 89 | |urgency|String|-|urgency of the Task|"low"|"low", "normal", "high"| 90 | 91 | ## Category 92 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 93 | |---|---|---|---|---|---| 94 | |category|String|-|category of the task or subtask|"Implementation"|-| 95 | 96 | ## TaskToTaskRelation 97 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 98 | |---|---|---|---|---|---| 99 | |label|String|-|relation between two tasks|"is blocked by"|"subtask", "blocks", "is blocked by"| 100 | |[tasks](#task)|Array of task objects|-|Array (of task objects)|-|-|-|-| 101 | |targetUiid|String|-|ID from the targeted task|-|-| 102 | |sourceUiid|String|-|ID from the source task|-|-| 103 | -------------------------------------------------------------------------------- /MasterDataModels/Collaborations/Protocols/2018-07-31WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | **Attendees:** Dennis, Philipp, Patrick, Peter
2 | 3 | ## Protocol 4 | 5 | # Feedback documentation: collaboration datamodel 6 | - description table needs to be added 7 | - additional realation from task to OIHDataRecord was added by Dennis, UML Diagram in GitHub needs to be updated 8 | - JSON Schema is missing, will be added in a later step by Peter 9 | 10 | ## Discussion of the collaboration datamodel 11 | - Patrick says that every e-mail should be seen as an action and not an element. This thought will be picked up for the second version of the colloboration datamodel. 12 | - Agreement on a two step approach: first step will be the finalization of the current model, afterwards the documentation will be send to different partners to gather feedback. In the second step the gathered feedback will be discussed and the model will be altered. 13 | - date can be deleted from the model, every OIHDataRecord has a property where the date will be saved. 14 | 15 | ## Next Steps 16 | - [ ] add description table to documentation **Responsibility: Peter** 17 | - [ ] send documentation to partners **Responsibility: Dennis** 18 | - [ ] read documentation and comment **Responsibility: Patrick** 19 | -------------------------------------------------------------------------------- /MasterDataModels/Collaborations/README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | In the following the master data model for the domain collaboration is explained in detail. As for every Open Integration Hub Master Data Model, an UML class diagram, a JSON schema as well as a description table exists. 4 | 5 | **Table of Contents** 6 | 7 | 8 | 9 | - [Introduction](#introduction) 10 | - [Basic Idea](#basic-idea) 11 | - [Considered Standards](#considered-standards) 12 | - [Standard for e-mail](#standard-for-e-mail) 13 | - [Standard for calendar](#standard-for-calendar) 14 | - [Standard for tasks](#standard-for-tasks) 15 | - [Operations](#operations) 16 | - [Content](#content) 17 | - [UML Diagram](#uml-diagram) 18 | - [JSON Schema](#json-schema) 19 | - [Description Table](#description-table) 20 | 21 | 22 | 23 | # Basic Idea 24 | The first version of the collaboration model will include models for e-mail, calendar events and tasks. 25 | Through community feedback these were identified as the most important models in the collaboration domain. 26 | 27 | Because all three of the models have identical properties they will be set in relation to an central element. 28 | The models will inherit the most important properties from this element and extensions will be made if neccessary. 29 | The idea behind this: collaboration relies on certain knowledge factors to establish an effective use. One has to know which person, when and with which properties created a certain element. 30 | 31 | # Considered Standards 32 | 33 | ## Standard for e-mail 34 | Finding a standard for e-mail properties proved to be difficult. Standards in the area of e-mail functions often specify the protocol, but not the properties of the e-mail. Therefore a analysation of different e-mail systems was made. 35 | Due to the extensive professional use of Microsoft Outlook the chosen e-mail standard is derived mostly from Outlook. 36 | 37 | ## Standard for calendar 38 | An existing standard for calendar events is "iCalender" (RFC 5545). In the following standard the properties of "iCalender" are incorporated and extended. 39 | 40 | ## Standard for tasks 41 | There is no existing standard for tasks. 42 | 43 | # Operations 44 | CRUD functionalities can be performed based on the model. 45 | 46 | # Content 47 | 48 | ## UML Diagram 49 | 50 | ![UML Draft OIH Master Data Model Collaboration](Assets/OIH_collaboration.png) 51 | 52 | ## JSON Schema 53 | 54 | - `EMail` Schema: [email](../../src/main/schema/collaboration/email.json) 55 | - Technical description of an E-Mail object 56 | - `CalendarEvent` Schema: [calendarEvent](../../src/main/schema/collaboration/calendarevent.json) 57 | - Technical description of an CalendarEvent object 58 | - `Task` Schema: [task](../../src/main/schema/collaboration/task.json) 59 | - Technical description of an Task object 60 | - `CollaborationElement` Schema: [collaborationElement](../../src/main/schema/collaboration/collaborationElement.json) 61 | - Technical description of shared definitions of e-mail, task and calendar in the CollaborationElement object 62 | - `TaskToTaskRelation` Schema: [taskToTaskRelation](../../src/main/schema/collaboration/taskToTaskRelation.json) 63 | - Technical description of a task to task relation object 64 | 65 | ## Description Table 66 | 67 | In addition to the uml class diagram, this folder contains a [description table](CollaborationModelDescription.md) which includes the following information for each attribute: 68 | - Type 69 | - Properties 70 | - Short description 71 | - Example values 72 | - Enumeration options (if attribute is an enumeration) 73 | -------------------------------------------------------------------------------- /MasterDataModels/Documents/Assets/OIH_Documents_Basic_Model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/MasterDataModels/Documents/Assets/OIH_Documents_Basic_Model.png -------------------------------------------------------------------------------- /MasterDataModels/Documents/DocumentModelDescription.md: -------------------------------------------------------------------------------- 1 | 2 | Second iteration of the document data model description. 3 | 4 | 5 | - [Object](#object) 6 | - [Document](#document) 7 | - [Folder](#folder) 8 | - [Version](#version) 9 | - [Document Property](#document-property) 10 | - [Policy](#policy) 11 | - [Sub Resource](#sub-resource) 12 | - [Relation](#relation) 13 | 14 | # Objects 15 | ## Object 16 | 17 | Objects describe base properties that are used by documents, folders or additional implementations. 18 | 19 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 20 | |---|---|---|---|---|---| 21 | |label|String||Name of the object|"Invoice #2018061023"|| 22 | |description|String||Additional information describing the object|"Invoice was sent on March 28th"|| 23 | |baseType|String|enum|Base type of the object|"document"|"document","folder"| 24 | |parentUid|String||Id of the parent element if hierarchically organized|"291ecb5e-cd8f-46fd-ae0d-40b5e280f23a"|| 25 | |path|String||Path from root to the objects parent|"/Invoices/Company Corp./2018/"|| 26 | |metadata|Map||Map that contains all metadata as specified by: [specification of generic metadata](DocumentModelMetadataDescription.md)||| 27 | 28 | ## Document 29 | 30 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 31 | |---|---|---|---|---|---| 32 | |currentVersion|Version||Current version of this document|||| 33 | |versions|Array (of version objects)|-|Current version of this document||| 34 | |subRessources|Array (of subResource objects)|-|Describes sub resources||| 35 | 36 | ## Item 37 | 38 | No additional properties available. 39 | 40 | ## Folder 41 | 42 | No additional properties available. 43 | 44 | ## Version 45 | 46 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 47 | |---|---|---|---|---|---| 48 | |label|String||Label of the document version. Most likely used for version numbering.|"1.0.1"|| 49 | |comment|String||Version comment by the author|"Rescanned document due to bad quality"|| 50 | |creation|Modification||Timestamp and user that created the document version||| 51 | |isLatestVersion|Boolean||Flag that indicates if this is the latest version of the document|true|| 52 | |isMajorVersion|Boolean||Flag that indicates if this is a major version of the document|true|| 53 | |size|Number||Filesize of the document version in bytes|2097152|| 54 | |mimeType|String||Mimetype of the file content|"image/png"|refer to http://www.iana.org/assignments/media-types/media-types.xhtml| 55 | |url|String||Download url for the document version.|"http://myservice.com/api/document/get/9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 56 | |uid|String||Id of the document version|"9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 57 | |type|String|enum|Type of the document version.|"image"|"image", "mail", "word", "audio", "video"| 58 | |extension|String||Type of the documents extension.|"pdf"|"jpg", "png"| 59 | 60 | ## Document Property 61 | 62 | Document properties can describe additional information depending on the documents type, 63 | e.g. systems that allow processing images can add the image size (width/height) in pixels. 64 | 65 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 66 | |---|---|---|---|---|---| 67 | |type|String|enum|Type or identifier of the property|"width"|| 68 | |value|Object||value of the property|1920|| 69 | 70 | ## Policy 71 | 72 | Policies can describe how objects are handled by the system. 73 | Invoices, for example, must be stored in a tamper-proof environment in order to comply with local law. 74 | Therefore policies can be used to define retention or deletion policies. 75 | 76 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 77 | |---|---|---|---|---|---| 78 | |type|String|enum|Type of the policy|"retention"|"retention", "deletion", "backup", "encryption", "storage"| 79 | |value|String||Description of the policy|""|| 80 | |uid|String||Id of the policy|"9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 81 | 82 | ## Sub Resource 83 | 84 | Sub resources can be used in order to provide additional information. 85 | DMS/ECM/EIM systems usually provide additional functionality like extracting fulltext content or generating preview images of the document. 86 | 87 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 88 | |---|---|---|---|---|---| 89 | |type|String|enum|Type of the sub resource|"rendition"|"rendition", "marker", "fulltext", "attachment"| 90 | |info|String||Additional information or description of the subresource|"small"|| 91 | |size|Number||Filesize of the document version in bytes|2097152|| 92 | |mimeType|String||Mimetype of the sub resource content|"image/png"|refer to http://www.iana.org/assignments/media-types/media-types.xhtml| 93 | |url|String||Download url for the sub resource|"http://myservice.com/api/document/subresource/get/9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 94 | |uid|String||Id of the sub resource|"9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 95 | 96 | ## Relation 97 | 98 | |Attribute|Type|Properties|Description|Example|Possible Enumeration Options| 99 | |---|---|---|---|---|---| 100 | |label|String||Name of the relation|"Relates to"|| 101 | |type|String|enum|Type of the relation|"link"|"link", "reference"| 102 | |targetUid|String||target object|"9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 103 | |sourceUid|String||source object|"9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"|| 104 | -------------------------------------------------------------------------------- /MasterDataModels/Documents/DocumentModelMetadataDescription.md: -------------------------------------------------------------------------------- 1 | # Generic metadata definition 2 | 3 | ![Generic metadata definition](Assets/OIHDataModelDocumentMetadataSpecification.svg) 4 | -------------------------------------------------------------------------------- /MasterDataModels/Documents/DocumentOperations.md: -------------------------------------------------------------------------------- 1 | # Operations 2 | 3 | ## Mandatory core operations 4 | 5 | The mandatory operations to be supported are CRUD operations on files. 6 | 7 | GET /root/ - If target is a document, retrieves the document content (with the appropriate mime type). 8 | If target is a directory, list all the children files. 9 | POST /root/ - Target must not exist. Creates document or directory depending on request body. 10 | PUT /root/ - Target must be a document. Overrides document (or adds a new version if versionning is supported). 11 | DELETE /root/ - Deletes document or directory 12 | 13 | POST /do?cmd=copy&from=... - To copy a document/directory 14 | POST /do?cmd=move&from=... - To move a document/directory 15 | 16 | 17 | ## Optional generic operations 18 | 19 | This more fine-grained API handles everything on `id` level for efficience purposes and clearly distinguishes between file content and file meta data. 20 | 21 | Generally speaking, HTTP verbs are used as follows: 22 | 23 | GET - retrieves the requested information 24 | POST - adds a new entry 25 | PUT - replaces an existing entry 26 | PATCH - partially edits an existing entry 27 | DELETE - deletes it 28 | 29 | There is also two API calls to detect version and feature set. 30 | 31 | GET /version Returns the version of the REST API it implements 32 | GET /features Returns a dictionary of booleans indicating which features are available. 33 | For example, a system supporting versionning and file sharing should return: 34 | {"versions":true, "shares":true} 35 | 36 | The following generic operations are common to most systems: 37 | 38 | * /config System configuration: backups, replication, options... 39 | 40 | * /files/{id}/info File informations: type, fullPath, owner, lastModified, description... 41 | * /files/{id}/content (for documents only) Document's content 42 | * /files/{id}/children (for directories only) Directory's children files. 43 | 44 | * /files/{id}/versions (for documents only) Lists document versions 45 | * /files/{id}/versions/{id}/info Version informations: comment, size, md5... 46 | * /files/{id}/versions/{id}/content Version's content 47 | 48 | * /files/{id}/shares Share links associated with document or directory 49 | * /files/{id}/permissions Unix permissions or full ACL 50 | * /files/{id}/lock File locking 51 | * /files/{id}/comments A list of comments: author, timestamp, title, message, inResponseTo... 52 | * /files/{id}/settings Settings like: retention/deletion rules, encryption, notifications,... 53 | 54 | GET /search?pattern=... Finds all documents matching pattern and fitting the provided criteria. 55 | 56 | POST /do?cmd={name}... Applies an arbitrary system specific operation 57 | 58 | The following operations are related to customizable and arbitrary meta data associated with the file: 59 | 60 | * /files/{id}/meta Arbitrary meta data "dictionary" 61 | * /files/{id}/meta/{name} A meta data "object" is identified by its name, and can have its own schema definition and permissions, as defined in /meta/{name} 62 | * /files/{id}/meta/{name}/... Since meta data is arbitrarily big, it is allowed to fetch/modify a specific entry directly 63 | 64 | * /meta Meta data definitions 65 | * /meta/{name}/schema Meta data can optionally be defined using a JSON schema. 66 | * /meta/{name}/permissions Meta data can have specific permissions that overrides the file's permissions. 67 | -------------------------------------------------------------------------------- /MasterDataModels/MetaModel.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | - mulit-tenancy support 4 | - conflict management support 5 | - extensibility per tenant 6 | 7 | ## Multi-Tenancy 8 | 9 | SaaS applications and multi-tenancy go hanad in hand. Hence, for the OIH it is essential to support multi-tenancy out pf the box. 10 | 11 | The meta model to describe master data models in the OIH must provide an identifier for the tenant which is the data's owner. 12 | 13 | ## Conflict Management Support 14 | 15 | - timestamps for _created_ and _last modified_ 16 | - alternatively versioning by revision numbers 17 | - or both? 18 | 19 | ## Extensibility per Tenant 20 | 21 | In case the master data model provided by the OIH is lacking of one or more fields or a specific tenant, and there is no sense in applying this extension to the global master data model, there should be a possibility to add those tenant specific fields only in the tenant's specific context. 22 | 23 | # Notation / Schema 24 | 25 | As of now, there are two important contemporary forms in which structured data is exchanged: 26 | 27 | - XML and 28 | - JSON. 29 | 30 | Both should - sooner or later - be applicable by the OIH at least at its outer boundaries. When it comes to the internals of the OIH, espacially the data hub, it is essential to decide for one of those alternatives, as the OIH will provide automatisms like conflict management, and the focus on one alternative will reduce implemenation efforts and risk. 31 | 32 | Decision: JSON! 33 | 34 | 35 | 36 | ## Schema Definition Language (SDL) 37 | 38 | Decision: [JSON-Schema](http://json-schema.org) (s. [https://github.com/openintegrationhub/Data-and-Domain-Models/issues/5](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/5) and [../MasterDataModels/README(.md/.pdf)](../MasterDataModels/README.md)) 39 | 40 | 41 | # Granularity 42 | 43 | - DDD: 44 | - Bounded contexts 45 | - Aggregates 46 | - loose coupling 47 | - multiple aggregates/entities per master data model 48 | 49 | (Done, s. [../MasterDataModels/README(.md/.pdf)](../MasterDataModels/README.md)) 50 | 51 | 52 | # Security / Authorization 53 | 54 | - ACLs/ACEs 55 | -------------------------------------------------------------------------------- /MasterDataModels/Products/DatamappingProducts.md: -------------------------------------------------------------------------------- 1 | # Data-Mapping of Products 2 | 3 | This document describes the evaluations of the data-mapping of the products 4 | within the Open Integration Hub. 5 | 6 | # Why is data-mapping necessary? 7 | 8 | One of the fundamental problems of the integration of data is the data-mapping. 9 | Data-mapping is the process which moves different elements of data between 10 | different models of data. There are different ways to resolve this task. 11 | 12 | A data-model is a model which describes the data and its elements of a specific 13 | domain, in this case the domain "Products". The integration of product-data is 14 | one of the main tasks of the whole OIH-Project. It's a fundamental and critical 15 | function of the Open Integration Hub. 16 | 17 | The data-mapping is necessary for the OIH, because most of the time the object 18 | models of product-data are similar, but in detail different. The data is similar, 19 | but the structure is different. You see data-sources which contains failures or 20 | dublettes or you for example can't see automatically if the specific element is 21 | a surname or not. Traditionally the mapping is hand-coded, where the data is 22 | copied between the objects. This is not very efficient and uses much resources. 23 | On the long run an algorithmic way would be more efficient. 24 | 25 | **Possible solutions for data-mapping of Products** 26 | 27 | Algorithmic data-mapping can be put in different ways in function. 28 | You can implement it via procedural code, you can use xslt-transformations or 29 | with graphical mapping-tools, which build the code for the transformation. 30 | 31 | With graphical tools you can draw lines between the fields of data structure. 32 | Intelligent tools are able to see the relations between those fields by their 33 | name or values. From the defined relations they are generating SQL, XSLT or 34 | programm code. These tools are most of the times part of etl-tools (Extrac, 35 | Transform, Load). 36 | 37 | For semantic mapping you can use metadata collections. These collections extend 38 | the automatic identification of the relations of the graphical tools to see 39 | possible synonyms. For example if a data source contains of a product that can be sold and/or purchased or can be produced. Then the semantic mapping tool can acknowledge, 40 | that this is describing the product and then get further informations which is different for a trading product instead of a product that has to be produced. 41 | 42 | A relative new field of research is the data driven mapping. It tries to foresee 43 | the mapping via heuristic evaluation and statistic methods of the data values 44 | of different data sources. The expectation is to see parts of the data, older 45 | collections of data or arithmetic relations or exceptions. 46 | -------------------------------------------------------------------------------- /MasterDataModels/Products/README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | In the following the master data model for the domain products is explained in detail. As for every Open Integration Hub Master Data Model, an UML class diagram, a JSON schema as well as a descrption table exists. 4 | 5 | **Table of Contents:** 6 | 7 | - [Introduction](#introduction) 8 | - [Basic Ideas](#basic-ideas) 9 | - [Considered Standards](#considered-standards) 10 | - [BiPro](#bipro) 11 | - [Oagis](#oagis) 12 | - [Operations](#operations) 13 | - [Content](#content) 14 | - [UML Diagram](#uml-diagram) 15 | - [JSON Schema](#json-schema) 16 | - [Description Table](#description-table) 17 | - [Additional Content](#additional-content) 18 | 19 | ## Basic Ideas 20 | 21 | ## Considered Standards 22 | 23 | ### BiPro 24 | 25 | Will follow soon. 26 | 27 | ### Oagis 28 | 29 | Will follow soon. 30 | 31 | ## Operations 32 | 33 | CRUD functionalities can be performed based on the model. 34 | 35 | ## Content 36 | 37 | ### UML Diagram 38 | 39 | ![MasterDataModelProductsV2](Assets/productModelV2.svg) 40 | 41 | ### JSON Schema 42 | 43 | - `Product` Schema: [product](../../src/main/schema/products/product.json) 44 | - Technical description of a product object 45 | 46 | ### Description Table 47 | 48 | In addition to the uml class diagram, this folder contains a [description table](ProductModelDescriptionTable.md) which includes the following information for each object: 49 | 50 | - Type 51 | - Properties 52 | - Short description 53 | - Example values 54 | - Enumeration options (if attribute is an enumeration) 55 | 56 | ## Additional Content 57 | 58 | - No additional content 59 | -------------------------------------------------------------------------------- /MasterDataModels/ReadmeTemplate.md: -------------------------------------------------------------------------------- 1 | The purpose of this document is to provide a template to consistently describe all **Open Integration Hub Master Data Models**. 2 | 3 | For a template conform example please look at the [Master Data Model Addresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Addresses/README.md). 4 | 5 | --- 6 | 7 | **Table of Contents** 8 | 9 | 10 | 11 | - [Introduction](#introduction) 12 | - [Basic Ideas](#basic-ideas) 13 | - [Basic Idea 1](#basic-idea-1) 14 | - [Basic Idea 2](#basic-idea-2) 15 | - [Considered Standards](#considered-standards) 16 | - [Standard 1](#standard-1) 17 | - [Standard 2](#standard-2) 18 | - [Operations](#operations) 19 | - [Content](#content) 20 | - [UML Diagram](#uml-diagram) 21 | - [JSON Schema](#json-schema) 22 | - [Description Table](#description-table) 23 | - [Additional Content](#additional-content) 24 | 25 | 26 | 27 | 28 | # Introduction 29 | 30 | In the following the master data model for the domain _{your domain}_ is explained in detail. As for every Open Integration Hub Master Data Model, an UML class diagram, a JSON schema as well as a descrption table exists. 31 | 32 | # Basic Ideas 33 | _Please describe the basic logic and ideas of the Master Data Model_ 34 | ## Basic Idea 1 35 | ... 36 | 37 | ## Basic Idea 2 38 | ... 39 | 40 | # Considered Standards 41 | _Please describe all other standards that were created during the creation process_ 42 | ## Standard 1 43 | ... 44 | 45 | ## Standard 2 46 | ... 47 | 48 | # Operations 49 | _Which functionalities can be performed on the model? Standard: CRUD_ 50 | 51 | # Content 52 | 53 | ## UML Diagram 54 | 55 | _Please provide the UML class diagram of the model._ 56 | 57 | ## JSON Schema 58 | 59 | _Please provide link(s) to the JSON schemas of the model._ 60 | 61 | ## Description Table 62 | 63 | _Please provide a link to the description table of the model._ 64 | 65 | # Additional Content 66 | 67 | _If existing, please provide additional content._ 68 | -------------------------------------------------------------------------------- /MasterDataModels/Versioning/Assets/change_request.xml: -------------------------------------------------------------------------------- 1 | 7VtLd5s6EP41XjqHhwF7GTuPLtp7cpJF26VsJpheQFwhYju//kogHkK4oTEmuCdZJGgQQsw337wgE3MV7u8JirffsAvBxNDc/cS8mRiGoWk6+8Mlh1wy141c4BHfzUV6JXjyX0EINSFNfRcSaSLFOKB+LAs3OIpgQyUZIgTv5GnPOJDvGiMPFMHTBgWq9Lvv0q14CsOp5F/A97bFnXV7kZ9Zo82/HsFpJO43Mczn7Cc/HaJiLfGgyRa5eFcTmbcTc0UwpvlRuF9BwHVbqC2/7u7I2XLfBCLa5QIBywsKUvHoqy2KmHIM7RH+SyGhYp/0UOiGbTnmh+He4+BfreMwuhLC5ZaGATuns8MXINRnKv2K1hA84MSnPo7YuTWmFIdsQsBPLEuFrXCASXaLQmXVGteB7/FrKY6ZFInRhj0ksEuWMRA/hOz4hj0fsxJ4qERLnNLAj2BVGotWCdkooShyEWEaWSaHcI35A3gQAUHsaKlqVCiZ7w32NZHQ8D1gdmNyYFPE2Wlp14IO+kKMd5VxWUK0rdlVIUPCnL1y6QpSdiBQbUfYVBC+gTjAB3D/fmQhOh+oc7uBqT4cpnMFUwVLcJlDE0NM6BZ7OELBbSVdZtCAK5RWg/cXUHoQPhmlFHOVlit8xRyobN5RJSY4JRuxj5nw3oh4IGYJJ8p3+FtFEwgQ9V9kl3yK2maK2h7hxYddB2cHeyqpTJdVttv6FJ5ilD31jpGnHxtT/IZjKTamGy1GNu/ByHRrFFbGtEcOP8T12eAnH1xZXS2w2HbdBHW9bxsUlz5gn22lBNDSFxKApVKLJfJNiasa2JTb6AbXOJzCyXA5LWgthkFrNpfpZtpaJ7SuCUGH2rSYT0i636ewiruu8xfSfHaQ7+C9pmOoTP8HK8ZDcx9YswkCif+K1tkEDrd4bjbbWk6sm7Z43gz7oe+6meF1SBlazKew+aZHLSsDsbtJPbtu87Talcl+JC1PxUonGtXUbqxqyyvg5+cETiW/0xLZREDTruOY4BfO6buj4W2kGR/Z4nCdJvWMTyqwPERhxw3/rUQwwvxPlQnCfhOkCQP1ftdPpDbnsqMfMsMvd3vhnr8IynXXbw7j+Z0iLhfwmeeL0ypajxAASnjNzRc27ID72TVhRx4/yuu1ELIN42f2K+I5a3MaM9aEs3JcKay9kGPXYsgMdtEa17RS35flDcdV/1pWIylxBvR4atvqEZjuXlGGRM6SJj+OlXhvcEAmTB+Ka/iaIRnR0g36nT4KQsQsWB6zNlUjJTqdVcKDhOR+VY3MVIUUslMTNEe697RYttcEraX3cJExuqU6K57k7NWZ+UYtne9TidHKQs2Q1DXYD13mFfvqrcyzFRv8CYlihiOs80r29FDn6bbdILzdjxtp1nkNo+rFjZjj78nB3qc/pNHPo5GirVvX5mEG6v9MrUYY0rv1f94DpFqxjxdIR0LyyiiGtUz0NIBNbRiAmynr+bqxplp6XAy+Tv/4DtRuNxr4duzfvgPf2fh7Lu2OuPOLu1YcB2rHDMfTls6pguPI2wK9NUk3iG62fuTVWwZhyj+6yYz1qNX8wYcQzQx3yC7pX/J+zGjJj3p/o34kP9LtN4jZtQSb6s03283uRo+uemyld+6PS+g7A79QkZ8NVHs3gde183lkNXN6Cpg/uzS3/Ofd2lb/C0mSfavYy0sqGcQBG7YztfXwwRw0ZBLWxu/KegvVjoKczvnKGk3B8Xb6DfnBJzv7ZqduDUjPseVGCj2dE+nZ8mr5o+hpWOejp1qVfoc1E9xhEn5StG+KluMBKGqpnveDKSoxtHNboWghjIGJ5hmZqL5ovffpl3T9ycK+WWgO+OG9ZYyChZ2YVrBKYlrfROucYXRQ3MiZcDkfI+rGYG02Nqz+WS33k9V/BJq3/wM= -------------------------------------------------------------------------------- /MasterDataModels/Versioning/Assets/realization.xml: -------------------------------------------------------------------------------- 1 | 3VnJctswDP0aH5PRYtnOMXaWdibteJJDmyMtwRJbSlApyku+vqBESZZlp9mcOM0hISGQBPAeuCA9dxKvriVLo28YgOg5VrDquRc9x7Ht4YD+aMm6lIxspxSEkgdGqRHc8QcwQstIcx5A1lJUiELxtC30MUnAVy0ZkxKXbbU5ivaqKQuhI7jzmehKf/BARcYLZ9jIvwAPo2ple3BWfpkx/3coMU/Mej3HnRc/5eeYVXMZR7OIBbjcELmXPXciEVXZilcTEDq2VdjKcVd7vtZ2S0jUUwYYsxdM5FBZXNil1lUsIKDQmC5KFWGICROXjXRc+At6Rot6kYoFNW1q/gKl1gZdliskUTPDDWJq9MhYuf5pxhede9059ahb2qON2OuiEWWYS99oGTcUkyEYLbcOL9EWMAZahlQkCKb4oj07M/wJa7166BQ5retYFdfPDJKG6Y7jtacoTTCjGiSosWFGIyrw2Y2V08HqFv7kkGlrztNU4kJjcE69e8qdbRiJaaluxqtQ5+zpLI2TUyPcxGwBUnHKhBs2AzHFjCuOCX2boVIYk4LQH8Y1zycoUBZLVExv5jgXPNRjlUZ6zEzPJ+CAhoxTkJz81+0LcpWSG6aNaIy5EjyBSZ3jViOkXqZYEjBJLo+zdTxD7UAICUgmatpoQ2D1OHG6lDADBlvIWqa/bHYEz4iijc2gku3iUAv9R6C2u1j/H3npdvOyf5C87NvvlpduB6upYMneBISVamFjt7FZRlzBXcqKiC0pVd+GzM5WPOyR12Gz7eyg8+gt6Nw/Cjq/jLL9LmXt154lTw1cN25f41RADIa0x8OvfoXxh/Br8In5Ze/YEwcH2RNHWxgdcE+0u5vipW4zBUdG3MGHEnd0FMRtzvniaK9P+peTevBe5/zIc1rwue4WLHs4fS4lW2+opVohe8Y62w+r7fvHsP+YPjVKC178GLA7zPmOHe6oMqc2KCEh4w9sVihothi/Sdsb97yLXdf07dt8zIOg4N0TXgJ7E9S83I0lvfpB3OLV6NHMPbFOh647aIX5xDNhfymtKhWczzN49YvNOrL0fqtr/I70Hh4kvc+84XsdWTve17ve0Z87pTaKTHtSii5To/aBeEQJ1b3nmVuFrlE41l3u+5Bl85zGX+29ZxxpBURGGM/ybLMC0qomhnR3WuoT41+FkQT1n6YoAitf5BlBd718mytTXQf9gMrIsMOAWxDAMrpWWnoSx7qAVOC6fCJZOKdfCSxLl7OCJp+LFs8vjEFyuJqYbTnvVhWjblMILzeL5r8N7uVf -------------------------------------------------------------------------------- /MasterDataModels/Versioning/DataModelChanges.md: -------------------------------------------------------------------------------- 1 | The following table shall sum up the possible changes of a master data model and serve as an input for the decisions that must be made for all open issues. 2 | 3 | |Use Case|Impacts on Transformers|Impacts on REST APIs|Impacts on Data Hub | Category |Shall Be Allowed?| 4 | |---|---|---|---|---|---| 5 | |Add object|+|+|+|minor |yes (see 6.)| 6 | |Add optional attribute|+|+|+| minor|yes| 7 | |Add mandatory attribute|+|+|+| major |? (see 1.)| 8 | |Add enumeration option|+|+|+|minor |yes| 9 | |Change object name|+|+|+|major |? (see 2. and 3.)| 10 | |Change attribute name|+|+|+|major |? (see 2. and 3.)| 11 | |Change enumeration option name|+|+|+| major|? (see 2.)| 12 | |Change attribute type (compatible)|+|+|+|major |? (see 4.)| 13 | |Change attribute type (incompatible)|+|+|+|major |no (see 4.)| 14 | |Change attribute: optional -> mandatory|+|+|+|major |? (see 1.)| 15 | |Delete object|+|+|+|major |no (see 5.)| 16 | |Delete attribute|+|+|+|major |no (see 5.)| 17 | 18 | _Note: All Use Cases marked with a `?` are outstanding and need a decision._ 19 | 20 | 1. If a new attribute shall be mandatory or an existing optional attribute shall become mandatory, then things are 21 | not that easy: APPs which use the old REST-APIs do not / could potentially not provide the mandatory attribute. A 22 | solution for this 23 | problem would be that an APP must provide the version number of the master data model version it wants to use and that the 24 | corresponding versions of Transformers / REST APIs could be easily accessed (at runtime). 25 | 26 | 2. APPs which use the old REST-APIs do not provide the new name or type of the object / attribute / enumeration option 27 | . A solution for this problem 28 | would be that an APP must provide the version number of the master data model version it wants to use and that the corresponding 29 | versions of Transformers / REST APIs could be easily accessed (at runtime). 30 | 31 | 3. Impacts on Data Hub: The name of the attribute or object in the data base object's schema must be changed. 32 | 33 | 4. Impacts on Data Hub: The type of the attribute in the data base object's schema must be changed and 34 | the attribute values in old data base objects must be converted to the new type. This is only possible if the 35 | conversion from the old data type to the new data type is compatible. 36 | 37 | 5. APPs which use old REST-APIs could provide the deleted attribute. Even if the old REST-APIs / Transformer versions 38 | could be accessed, there still remains the problem that the corresponding data column does not exist any more (if no versionized data tables are used). 39 | 40 | 6. Note: The new object must not have mandatory attributes, for the same reason as described in 1. 41 | 42 | 43 | **Note:** There are other documents in the repository with similiar content. 44 | Some of them are: 45 | 46 | 1. [VersioningMasterDataModels](VersioningMasterDataModel.md) 47 | 2. [ProcedureModelExtension](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/modelExtenstionProcedure/MasterDataModels/ProcedureModelExtension.md) 48 | 3. [SpecializedDataModelsExample](SpecializedDataModelsExample.md) 49 | -------------------------------------------------------------------------------- /MasterDataModels/Versioning/SpecializedDataModelsExample.md: -------------------------------------------------------------------------------- 1 | # Specialized Data Models - Example Workflow to Be Discussed 2 | 3 | ## Preliminary remarks 4 | 5 | In the following sections there is a sketch of an example workflow for the evolutionary process of changing and versioning a Specialized Data Model and a Master Data Model. 6 | 7 | The example described here shall serve as a basis for further discussions. 8 | 9 | **We should keep on clarifying some assumptions/questions of the former contribution first:** 10 | 11 | 12 | * **We should be aware of the fact, that the procedure model of versioning the Master Data Models could impact the procedure model of versioning Specialized Data Models and should therefore be discussed first.** 13 | 14 | * **This is an example for the versioning of Specialized Data Models and its possible consequences concerning the Master Data Models. That means the procedure described in Step 3 is only a special case of versioning a Master Data Model.** 15 | 16 | * Is there really only one specialized data model for a master data model, i.e. is the specialized data model specified on OIH level? Or could specialized data models be ISV-specific? The decision will have impacts e.g. on the questions whether properties of a specialized data model must be optional or who is allowed to change the data with which means. 17 | 18 | 19 | ## Example 20 | In our example ISV-X develops an APP-X for companies which deal in screws. Screws are products which have a lot of data, for instance: 21 | 22 | * **material**: steel, stainless steel, zinc plated steel, aluminium, ... 23 | * **screw head shape**: pan, flat, oval, ... 24 | * **screw drive**: slot, cross, Frearson, ... 25 | 26 | See also: 27 | 28 | Let's have a look at the specification of a special sort of screw, the Phillips Flat Head Countersunk: 29 | 30 | As you can see, screws usually have DIN and ISO specification. To fully specify a DIN-965 screw, a set of special measurements is necessary: 31 | * **d1, d2, L, k, m, t** 32 | 33 | ## Step 1: Creation / Modification of an Individual Field Mapping 34 | 35 | **Goal:** The APP-X of the ISV-X shall be connected with another APP-Y of ISV-Y. 36 | 37 | This could be done at first by integration with the means of an individual field mapping of the proprietary models, aside from the OIH models mapping, such as described in (mapping from ISV-1/APP-1 to ISV-N/APP-N): 38 | 39 | **Impacts:** 40 | * Both individual Transformers of ISV-X 41 | 42 | 43 | ## Step 2: Creation / Modification + New Version of a Specialized Data Model 44 | 45 | **Goal:** APP-X shall be integrated with a second APP, APP-Z. 46 | 47 | This is the moment to think about the creation or the modification of a Specialized Data Model. 48 | 49 | Some of the screw data could already be mapped to Master Data Model properties: 50 | 51 | **Extract of the Product Master Data Model** 52 | ``` 53 | { 54 | ..... 55 | "dinStandard": { "type": "string" }, 56 | "isRohsCompliant": { "type": "boolean" }, 57 | "netWeight": { "type": "number" }, 58 | "grossWeight": { "type": "number" }, 59 | "density": { "type": "number" }, 60 | "length": { "type": "number" }, 61 | "width": { "type": "number" }, 62 | "strength": { "type": "number" }, 63 | "innerDiameter": { "type": "number" }, 64 | "outerDiameter": { "type": "number" } 65 | ..... 66 | } 67 | ``` 68 | **Mapping:** 69 | * dinNumber --> dinStandard 70 | * d1 --> outerDiameter 71 | * d2 --> innerDiameter 72 | * L --> length 73 | * m --> width 74 | 75 | **Note:** The mapping "m --> width" is perhaps not the best idea, since the semantics of m is not really the width of a screw. 76 | **Question:** I wonder why there is no property for "depth"? 77 | 78 | But for the measurements *k* and *t* there are no appropiate mappings, also for the ISO standard number and for the material, screw head shape and screw drive. 79 | 80 | **So let's build a Specialized Data Model for this data:** 81 | ``` 82 | { 83 | "$schema": "http://json-schema.org/draft-04/schema#", 84 | "$id": "http://openintegrationhub.org/schemas/products/special-data-model.json", 85 | "title": "Special Data Model Product", 86 | "description": "Special Data Model for Product", 87 | "allOf": [ 88 | { 89 | "$ref": "http://openintegrationhub.org/schemas/products/product.json", 90 | } 91 | ], 92 | "properties": { 93 | "version": { "type": "integer" }, 94 | 95 | "screwProperties": { "type": "object", 96 | "properties": { 97 | "isoStandard": { "type": "string" }, 98 | "material": {"type": "string"}, 99 | "headShape": {"type": "string"} 100 | "drive":{"type": "string"} 101 | }, 102 | "screwMeasurements": { "type": "object", 103 | "properties": { 104 | "k": {"type": "number"}, 105 | "t": {"type": "number"} 106 | }, 107 | }, 108 | } 109 | ``` 110 | 111 | **The additional mappings would then be:** 112 | 113 | * isoNumber → screwProperties.isoStandard 114 | * material → screwProperties.material 115 | * screwHeadShape → screwProperties.headShape 116 | * screwDrive → screwProperties.drive 117 | * k → screwMeasurements.k 118 | * t → screwMeasurements.t 119 | 120 | **Note:** We simplified the assumptions for the data types. 121 | 122 | **Impacts:** 123 | * Specialized Data Model 124 | * Both "official" Transformers of ISV-X and ISV-Y 125 | * Data Hub data (if wanted/configured) 126 | 127 | ## Step 3: Modification + New Version of Master Data Model 128 | 129 | **Goal:** 130 | Let's say, a lot of ISVs also need the additional properties "isoStandard" and "material". 131 | So the OIH admin (or the ISVs) wants to extend the Product Master Data Model: 132 | 133 | **Extension of the Product Master Data Model:** 134 | ``` 135 | ..... 136 | "dinStandard": { "type": "string" }, 137 | "isRohsCompliant": { "type": "boolean" }, 138 | "netWeight": { "type": "number" }, 139 | "grossWeight": { "type": "number" }, 140 | "density": { "type": "number" }, 141 | "length": { "type": "number" }, 142 | "width": { "type": "number" }, 143 | "strength": { "type": "number" }, 144 | "innerDiameter": { "type": "number" }, 145 | "outerDiameter": { "type": "number" } 146 | ..... 147 | ``` 148 | 149 | Now the mapping of "isoStandard" and "material" has to be changed, i.e. all transformers which use these data have to be changed. Also a migration of Data Hub data has to take place. 150 | 151 | **Mapping:** 152 | * ISO → isoStandard 153 | * material → material 154 | 155 | **Note:** Here the structure of the data changed, but the names could also change. 156 | 157 | **Impacts:** 158 | * Master Data Model 159 | * Specialized Data Model 160 | * Transformers 161 | * Data Hub (if wanted/configured) 162 | 163 | **Note:** If the data in the Specialized Data Model are always unstructured "flat" data and the names of the data are kept, then things might get easier. 164 | 165 | 166 | 167 | 168 | 169 | -------------------------------------------------------------------------------- /Protocols/2017-03-23WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Philipp, Andreas, Jürgen, Frank, Elke, Dieter, Robin
4 | **Absent:** Josef 5 | 6 | # Topics 7 | ## Current Status 8 | 1. Address model has been expanded by anylazing different solutions and standards 9 | - Exemplary solutions were: 10 | - Salesforce 11 | - Exact 12 | - Weclapp 13 | - SageOne 14 | - Standards that were analyzed: 15 | - vCard 16 | - BiPro 17 | - Infosphere (partly) 18 | - The elaborations include an expanded [UML class diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/969645fe280641d62a9dcb085e2b7cf371d72279/MasterDataModels/Assets/OIHMasterDataModelAddresses_V2.png), a [tabular description](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/969645fe280641d62a9dcb085e2b7cf371d72279/MasterDataModels/AddressModelV2Description.md) and an initial Swagger documentation (not published yet) 19 | 2. Creation of an [initial procedure model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/1f7e46664b8f2a3b39326d43a30816e6009a9dc8/MasterDataModels/ProcedureModelExtension.md) to extend the Master Data Models 20 | - This procedure model also includes a [form](https://goo.gl/forms/OjPFdyQ7qvDLMQ442) to request model changes 21 | 3. Wice (Shterion) is working on implementing a rudimentary database component which represents the master data model to enable data synchronization via the address master data model 22 | 4. First versions [SnazzyContactsAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/SnazzyContactsAdapter) and [WiceCRMAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/WiceAdapter) are finished (including API documentation for SnazzyContacts and WiceCRM) and ready for quality checks. 23 | 5. First version of [SilverERPAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/SilverpContactsAdapter) exists. 24 | 6. [First ideas](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/SpecializedDataModels.md), [examples](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/SpecializedDataModelsExample.md) and [conceptional elaborations](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/VersioningMasterDataModel.md) were created to expand the procedure model 25 | 26 | ## Next Steps 27 | - [ ] Reconciliation between **Lutz**, **Hansjörg** and **Philipp** regarding the address master data model (Monday, 23.03.2018 11:15) 28 | - [ ] Conceptional elaborations for the procedur model **Elke** and **Lutz** 29 | - [ ] Documentation of the proprietary (SilverERP) data model **Dieter** and **Josef** 30 | - [ ] Work on implementing the database component on elastic.io **Shterion** 31 | -------------------------------------------------------------------------------- /Protocols/2017-10-16CommitteeInnovationAgenda.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/Protocols/2017-10-16CommitteeInnovationAgenda.pdf -------------------------------------------------------------------------------- /Protocols/2017-10-16CommitteeInnovationWorkshop.md: -------------------------------------------------------------------------------- 1 | @openintegrationhub-innovation **absent** @thorsten @daniel @hansjörg @selim **guest** @stephan @igor 2 | 3 | ## Outcome 4 | Agreement on our workload for this quarter (Q4) 5 | 6 | ## Topics (issues) 7 | 8 | ### Feedback tool onboarding @all [quick session] 9 | **Purpose:**
10 | * Feedback about GitHub & ZenHub 11 |
=> Commitment to tool chain 12 | 13 | **Discussion:**
14 | 15 | _Raphael_:
16 | - GitHub serves as a central unit to document findings/results and issues 17 | - The documentation on GitHub aims to foster the collaboration within the project 18 | - Creating issues can help, e.g. to reveal obstacles and solve them together with other project participants 19 | - Tickets/Issues evolve over time - it is a evolutionary process 20 | 21 | _Josef_:
22 | - Time issue -> Although only 5 'person days' per week are calculated, 5 people work on the project 23 | - Until this meeting, direct communication- instead of communication via GitHub - was chosen to avoid a waste of time 24 | - **Missing feeling for the granularity of the issues/tickets on GitHub** 25 | - Missing expectations of the other project participants about the issues/tickets hampered the use 26 | - An update call (one every two weeks) is sufficient enough to get an overarching overview 27 | - Intermediate-term scope is missing, but should not be as granular as the short-term scope in the Stand Up Calls every two weeks 28 | - **Shares Lutz' opinion, that it is sufficient enough to describe findings/results on GitHub** 29 | 30 | 31 | _Lutz_:
32 | - Documentation should describe: _What is it?_ and _What is it good for?_ 33 | - The effort is to high because of the great amount of tools (including tools from other projects) 34 | - **The issue creation to this point is to granular, it is sufficient enough to document the findings/results** 35 | - Coordination between teams working on the same topic works by itself 36 | - **Granularity of tickets/issues is missing** 37 | - GitHubs focus should lie on _what is in progress?_, _what should be done_, _what and how was something done?_. Means i.e. the internal communication takes place on GitHub and the reporting for the DLR is detached from this. 38 | 39 | _Igor_:
40 | - Contradicting opinion: Through the documentation is an overview created, which enhances the collaboration and helps to make the project successful. Documentation is essentiel. 41 | - Obstacles can not be detected without the documentation (and therefore can not be solved) 42 | - **Agrees to use GitHub / ZenHub and mark-down** 43 | - Elastic.io has not used GitHub to this point because of their internal coordination 44 | - Learning: Collaboration with different teams is much harder than expected, 45 | - Provided a first approach regarding the Data Hub concepts (See topic "Data Hub Concept - suggested by @igor") 46 | 47 | 48 | _Stephan:_
49 | - **Finding: The way and granularity of contributing on GitHub has to be clarified** 50 | 51 | ### Working with GitHub & ZenHub @raphael [quick session] 52 | **Purpose:**
53 | * Create an item (issue) 54 |
=> New issue example 55 | 56 | **Discussion:**
57 | - No need to create an issue during this meeting (Common sense) 58 | 59 | ### Committee of innovation @all [quick session] 60 | **Purpose:**
61 | * What's your expectation / understanding?
62 | => Common sense about our committee. 63 | 64 | **Discussion:**
65 | - In the innovation committee new ideas and innovations regarding the OIH are discussed 66 | - Distinction between persons which produce no (or only few) code (mainly conceptual work) and person which produce the majority of code 67 | 68 | 69 | ### Your contribution @all [be prepared] [openintegrationhub/innovation#1](https://github.com/openintegrationhub/innovation/issues/1) 70 | **Purpose:**
71 | - Innovation topics, market trends etc.
72 | => Agenda for the rest of the day 73 | 74 | **Discussion:**
75 | The following topics are derived from the [workshop preparation issue](https://github.com/openintegrationhub/innovation/issues/1).

76 | _Data Hub Concept by @igor_
77 | - During the meeting the functions of the [Prototype TIER 2](https://github.com/openintegrationhub/innovation/issues/2) were discussed. Through this discussion the tasks at the end of this protocol are derived. 78 | 79 | _Schema Definition Language by @raphael_
80 | - To Be Done (TBD) 81 | 82 | _Standard to describe API Design by @renat_
83 | - TBD 84 | 85 | _Standard for API Documentationby @renat_
86 | - TBD 87 | 88 | _Standard to describe Metamodels by @renat_
89 | - TBD 90 | 91 | ## Derived Tasks 92 | - The [Prototype TIER 2 issue](https://github.com/openintegrationhub/innovation/issues/2) will be revised and will result in an issue for both, the protoype TIER 1 and the prototype TIER 2. @josef 93 | - The [Integration Scenario with DataHub](https://github.com/openintegrationhub/architecture/blob/master/evaluations/dataIntegrationWithDataHub.md) is expanded, with the aim to make clear, which functionality the first and second iteration of the DataHub should provide (to every stakeholder). @igor 94 | 95 | ## Next Meeting 96 | - [x] **Date** - 29.11.2017 - 9:00 97 | - [x] **Host** - Cloud Ecosystem / X-Integrate 98 | - [x] **Address** - X-Integrate, Im Mediapark 5c, 50670 Köln 99 | - [x] **Attendees** - @openintegrationhub-innovation @openintegrationhub-architecture **Guest:** @shterion 100 | -------------------------------------------------------------------------------- /Protocols/2017-11-29Workshop.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Hansjörg, Lutz, Josef, Raphael, Susanne, Frank, Selim, Stephan, Andy, Philipp 4 | 5 | ## Discussion / Findings 6 | 7 | - Due to relevant coherences it is necessary to build `aggregates`. This will result in n sub models and schemata for a master data models 8 | - The greatest challenge is to keep the onboarding effort as low a possible 9 | - `OIH-Records` will be introduced. Aggergates and entities have to declare that they also are an OIH-record 10 | - The master data model has a tree structure with _one root_. 11 | - Aggregates represent logical business relationships in such a master data model. 12 | - Domain models are aggregates of a master data models 13 | - The core of the tree structure is the `OIH record` 14 | 15 | - A detailed definition of the expression `generic model` is provided in the file about [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md#31-general-requirements): 16 | 17 | "In this specific field of investigation, the master data model for addresses describes a generic standard of customer data for the management of addresses. 18 | 19 | Processing personal data, such as personally identifiable information, is a special subject of privacy rules and data protection laws. 20 | 21 | The master data model for the OIH should be: 22 | 23 | - compatible with business models in business-to-business and business-to-consumer. 24 | - generic but extendable for individual applications 25 | - used by the integration services and by the data hub 26 | - cover most of the integration scenarios 27 | - cover the privacy rules and data protection laws 28 | - de facto standard for the address integration scenarios for SME" 29 | 30 | - To this point YQ developed the adapter for the elastic.io platform 31 | - A `database` component shall act as a `DataHub` on the elastic.io platform. With this component the following scenario shall be realized: `SilverERP` --> `DataHub` --> `Snazzy Contacts`. In a first step the `DataHub` should only revice and centrally store the data and afterwards broadcast it so all following applications. 32 | - Currently the interface is prorpietary to elastic.io. In a later stage the interface must be generalized. 33 | - Currently it is not possible to trigger events through a component but everything is triggered by elastic.io (See timer component) 34 | 35 | ## Next Steps 36 | ### Derived Tasks 37 | - [ ] Suggest tools for creating UML-Diagrams **@Lutz** 38 | - [ ] Provide a schema for the creation of the `tree structure` **@Lutz** till 01.12.2017 39 | - [ ] Evaluate Lutz' suggestions **`@Josef + Hansjörg** 40 | - [ ] Provide first results on basis of Lutz' suggestions **@Josef + @Hansjörg** till 11.12.2017 41 | - [ ] Provide deliverables on basis of Lutz' suggestions (Tool + Schema) **@Josef & @Hansjörg** (Latest 31.12.2017) 42 | - [ ] Discuss options to enable `triggering` through other components than the timer component 43 | 44 | ### Next meeting / workshop 45 | - [ ] **Date:** 17.01.2018. **Location:** To be determined. 46 | -------------------------------------------------------------------------------- /Protocols/2017-12-11Telko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Josef, Hansjörg, Lutz, Raphael, Andreas, Frank, Andy, Philipp (minute taker) 4 | 5 | ## Election Workgroup Manager 6 | - Initial suggestion (Lutz) was rejected 7 | - **Raphael** takes over the manager position for the Data & Domain Model Workgroup 8 | 9 | ## Workshop Protocol (from 29.11.2017) 10 | - Accepted. Can be merged into the master branch 11 | 12 | ## Lutz' Suggestion for the Data Model 13 | Suggested structure/model see: [OIHDataModels](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/OIHDataModels/OIHDataModels.md) 14 | 15 | #### Lutz 16 | - The currently existing oih data model suggestion covers all existing use cases 17 | - To cover all future use cases, further domain & data models are needed (realizable with this suggested model) 18 | - Suggested model is applicable for the domains adresses and products 19 | - There won't be a perfect data model which covers all use cases 20 | - A pull synchronisation is only realizable with the smart data framework. If the smart data framework is not used, synchronization is only realizable via pushing. 21 | 22 | #### Josef 23 | - In the first step the two domains adresses and product should be covered (by a master data model). 24 | - This helps to create learnings and further use cases e.g. invoices can be defined 25 | 26 | ## Regulations 27 | - Regulations are needed for different conventions like output format, naming, etc. 28 | - Regulations can also be understood as guidelines, e.g. adapter guidelines 29 | 30 | ## Current Results 31 | - Raphael presented his outputs and ideas 32 | - Lutz: The ideas and questions are good but they delve to deep right now (basics need to be clarified). 33 | - Thus the questions and ideas aim at a later stage, but we have to keep them in mind. We won't be able to develop the perfect model till the end of the year. The results for the first milestone will be more like a first draft 34 | - Josefs' results are currently in a textual form because of the missing UML modeling tool. The existing results can easily be transferred into an UML diagram. 35 | - The results are not the final model but a first draft 36 | - The results will be published on GitHub to provide insights for all project members 37 | - Hansjörg expanded the [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md#423-person-specific-requirements) by chapter 4.2.3 38 | - Missing: Privacy- and digital rights management 39 | - A vizual representation such as the one by YQ can be derived from the existing MasterDataModelAdresses file 40 | 41 | ## Next Steps 42 | - [ ] Lutz and Josef will have a discussion about the regulations 43 | - [ ] Next **appointment** on **15.12.2017 at 10:30 am** 44 | -------------------------------------------------------------------------------- /Protocols/2017-12-11WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Josef, Hansjörg, Lutz, Raphael, Andreas, Frank, Andy, Philipp (minute taker) 4 | 5 | ## Election Workgroup Manager 6 | - Initial suggestion (Lutz) was rejected 7 | - **Raphael** takes over the manager position for the Data & Domain Model Workgroup 8 | 9 | ## Workshop Protocol (from 29.11.2017) 10 | - Accepted. Can be merged into the master branch 11 | 12 | ## Lutz' Suggestion for the Data Model 13 | Suggested structure/model see: [OIHDataModels](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/OIHDataModels/OIHDataModels.md) 14 | 15 | #### Lutz 16 | - The currently existing oih data model suggestion covers all existing use cases 17 | - To cover all future use cases, further domain & data models are needed (realizable with this suggested model) 18 | - Suggested model is applicable for the domains adresses and products 19 | - There won't be a perfect data model which covers all use cases 20 | - A pull synchronisation is only realizable with the smart data framework. If the smart data framework is not used, synchronization is only realizable via pushing. 21 | 22 | #### Josef 23 | - In the first step the two domains adresses and product should be covered (by a master data model). 24 | - This helps to create learnings and further use cases e.g. invoices can be defined 25 | 26 | ## Regulations 27 | - Regulations are needed for different conventions like output format, naming, etc. 28 | - Regulations can also be understood as guidelines, e.g. adapter guidelines 29 | 30 | ## Current Results 31 | - Raphael presented his outputs and ideas 32 | - Lutz: The ideas and questions are good but they delve to deep right now (basics need to be clarified). 33 | - Thus the questions and ideas aim at a later stage, but we have to keep them in mind. We won't be able to develop the perfect model till the end of the year. The results for the first milestone will be more like a first draft 34 | - Josefs' results are currently in a textual form because of the missing UML modeling tool. The existing results can easily be transferred into an UML diagram. 35 | - The results are not the final model but a first draft 36 | - The results will be published on GitHub to provide insights for all project members 37 | - Hansjörg expanded the [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md#423-person-specific-requirements) by chapter 4.2.3 38 | - Missing: Privacy- and digital rights management 39 | - A vizual representation such as the one by YQ can be derived from the existing MasterDataModelAdresses file 40 | 41 | ## Next Steps 42 | - [ ] Lutz and Josef will have a discussion about the regulations 43 | - [ ] Next **appointment** on **15.12.2017 at 10:30 am** 44 | -------------------------------------------------------------------------------- /Protocols/2017-12-15WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Andreas G., Lutz, Hansjörg, Josef, Raphael, Philipp (minute taker) 4 | 5 | **Absent:** Josef 6 | 7 | ## Workshop Protocol (from 11.12.2017) 8 | [2017-12-11Telko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-11Telko.md) - accidentally merged already due to [DecisionsMade.md](https://github.com/openintegrationhub/Data-and-Domain-Models/pull/21) 9 | 10 | - ... 11 | 12 | ## Results for the 1st milestone 13 | [Provide deliverables on basis of Lutz' suggestions (Tool + Schema)](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/19) 14 | 15 | ### Lutz 16 | - Wasn't able to provide a json schema until now because of illness 17 | - JSON Schema has priority no.1 from now on 18 | - Provided a [Data Model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) which includes the description of the OIH datasets. 19 | 20 | ### Hansjörg 21 | - Provided a [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) on basis of the previous elaborations and the provided by Lutz. 22 | - Lutz: Field (String, enumartion etc.) so specify the sort of the address. 23 | - Lutz: The Fields like _street_, _streetNumber_, _unit_, etc. can be modeled as attributes within the addresses 24 | - The idea behind the object `relations` shall be generic 25 | 26 | ## Regulations for the 1st milestone - official 27 | TBD [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) 28 | 29 | - What is the purpose of the `regulations`? What exactly is meant by `regulations`? 30 | - Define regulations per domain and/or define them for all models (such as UML, JSON etc.) 31 | - Regulations for the different domains have to be written down 32 | - Overarching regulation: `Header (OIH Dataset)` is set for all domains 33 | 34 | 35 | ## Regular Meetings - calls 36 | Fixed GoToMeeting every two weeks - when? 37 | 38 | - To be determined 39 | 40 | ## 1st Workshop in 2018 41 | Alternative date at the 3rd KW'18 - possible? 42 | 43 | - To be determined 44 | 45 | ## Next Steps 46 | - [ ] Provide a JSON Schema **Lutz** till **early 19.12.2017** 47 | - [ ] Reconcilation of Hansjörg's results and afterwards provide the results on GitHub **Lutz, Hansjörg, Josef (Suggested)** till **15.12.2017** 48 | - [ ] [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) by @lashauer @hschmidthh @JosefBraeuer till **15.12.2017** 49 | - [ ] Write down concrete attributes and update UML diagram **Hansjörg** till **15.12.2017** 50 | - [ ] Supplement from a subsequent converstion: the UML diagrams for addresses and products will be converted into the provisioned JSON 'tree structure' **Hansjörg, Josef** till **late 19.12.2017** 51 | - [ ] Remove ZenHub broadcast functionality about its Board activities - for Slack **Raphael** till **15.12.2017** 52 | - [ ] Next appointment **19.12.2017** at **10:00 am** 53 | -------------------------------------------------------------------------------- /Protocols/2017-12-15WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Andreas G., Lutz, Hansjörg, Josef, Raphael, Philipp (minute taker) 4 | 5 | **Absent:** Josef 6 | 7 | ## Workshop Protocol (from 11.12.2017) 8 | [2017-12-11Telko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-11Telko.md) - accidentally merged already due to [DecisionsMade.md](https://github.com/openintegrationhub/Data-and-Domain-Models/pull/21) 9 | 10 | - ... 11 | 12 | ## Results for the 1st milestone 13 | [Provide deliverables on basis of Lutz' suggestions (Tool + Schema)](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/19) 14 | 15 | ### Lutz 16 | - Wasn't able to provide a json schema until now because of illness 17 | - JSON Schema has priority no.1 from now on 18 | - Provided a [Data Model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) which includes the description of the OIH datasets. 19 | 20 | ### Hansjörg 21 | - Provided a [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) on basis of the previous elaborations and the provided by Lutz. 22 | - Lutz: Field (String, enumartion etc.) so specify the sort of the address. 23 | - Lutz: The Fields like _street_, _streetNumber_, _unit_, etc. can be modeled as attributes within the addresses 24 | - The idea behind the object `relations` shall be generic 25 | 26 | ## Regulations for the 1st milestone - official 27 | TBD [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) 28 | 29 | - What is the purpose of the `regulations`? What exactly is meant by `regulations`? 30 | - Define regulations per domain and/or define them for all models (such as UML, JSON etc.) 31 | - Regulations for the different domains have to be written down 32 | - Overarching regulation: `Header (OIH Dataset)` is set for all domains 33 | 34 | 35 | ## Regular Meetings - calls 36 | Fixed GoToMeeting every two weeks - when? 37 | 38 | - To be determined 39 | 40 | ## 1st Workshop in 2018 41 | Alternative date at the 3rd KW'18 - possible? 42 | 43 | - To be determined 44 | 45 | ## Next Steps 46 | - [ ] Provide a JSON Schema **Lutz** till **early 19.12.2017** 47 | - [ ] Reconcilation of Hansjörg's results and afterwards provide the results on GitHub **Lutz, Hansjörg, Josef (Suggested)** till **15.12.2017** 48 | - [ ] [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) by @lashauer @hschmidthh @JosefBraeuer till **15.12.2017** 49 | - [ ] Write down concrete attributes and update UML diagram **Hansjörg** till **15.12.2017** 50 | - [ ] Supplement from a subsequent converstion: the UML diagrams for addresses and products will be converted into the provisioned JSON 'tree structure' **Hansjörg, Josef** till **late 19.12.2017** 51 | - [ ] Remove ZenHub broadcast functionality about its Board activities - for Slack **Raphael** till **15.12.2017** 52 | - [ ] Next appointment **19.12.2017** at **10:00 am** 53 | -------------------------------------------------------------------------------- /Protocols/2017-12-19WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Jürgen, Andy, Philipp (minute taker) 4 | 5 | **Absent:** Andreas G. 6 | 7 | ## Workshop Protocol (from 15.12.2017) 8 | [2017-12-15WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-15WorkgroupTelko.md) - accidentally merged already due to [DecisionsMade.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DecisionsMade.md) 9 | 10 | - Accepted by all 11 | 12 | ## Final results for the 1st milestone 13 | [Provide deliverables on basis of Lutz' suggestions (Tool + Schema)](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/19) by @hschmidthh @JosefBraeuer till **15.12.2017** 14 | 15 | [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) by @lashauer @hschmidthh @JosefBraeuer till **15.12.2017** 16 | 17 | ### Lutz 18 | - [x] JSON Schema 'tree structure' **by @lashauer till early 19.12.2017** 19 | - Provided a basis schema: [OihDataRecordSchema](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/oih-data-record.schema.json) 20 | - Provided an example for the order example: [Order Example](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/examples/schema/order.schema.json) 21 | - Both schemas are work in progress and will be expanded e.g. by _description field_ 22 | - Would like to provide snippets and explanations inline (in the markdown file) and refer to the rest of the schema 23 | - [ ] General regulations for generic data models **by @lashauer till 19.12.17** 24 | - Will provide regulations according to the needs of WICE and YQ 25 | 26 | ### Hansjörg 27 | - [x] Generic data model addresses in the shape of an UML class diagram (attached) **by @hschmidthh till 19.12.17** 28 | * Write down concrete attributes and update UML diagram **by @hschmidt till 15.12.2017** 29 | - [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) Lutz: Field (String, enumeration etc.) to specify the sort of the address. 30 | - [x] Specific regulations for the generic data model addresses **by @hschmidthh till 19.12.17** 31 | - [ ] Generic data model addresses in the shape of a JSON schema **by @hschmidthh till late 19.12.17** 32 | 33 | #### UML Diagram 34 | - Classes like `phone` or `emails` are encapsulated to enable reusability, as e.g. a person can have more than one phone number and email 35 | - Categorization of e.g. phone numbers are done by categorizing the person 36 | - Base model is finished 37 | - Model will be expanded in later stages (e.g. adding attributes) 38 | 39 | #### Regulations 40 | - Regulations for creating a new model are written down in [RulesAndRegulations.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/RulesandRegulations.md) 41 | - Lutz/Raphael: Specific regulations and explanations (e.g. why is the categorization done for a person and not a phone number itself) is needed 42 | - Josef: These information are descriptions but not necessarily regulations. The information should be part of the MasterDataModel descriptions 43 | 44 | #### JSON-Schema 45 | - JSON File needs to be and will be created manually (Visual Paradigms complexity for converting the UML diagram into xml is to high) 46 | 47 | ### Josef 48 | - [x] Generic data model products in the shape of an UML class diagram (attached) **by @JosefBraeuer till 19.12.17** 49 | - Provided a UML-Schema and will upload the result on GitHub 50 | - [ ] Specific regulations for the generic data model products **by @JosefBraeuer till 19.12.17** 51 | - [ ] Generic data model products in the shape of a JSON schema **by @JosefBraeuer till late 19.12.17** 52 | 53 | ## Regular Meetings - calls 54 | **Postponed:** Fixed GoToMeeting every two weeks - **when?** 55 | 56 | ## 1st Workshop in 2018 57 | **Postponed towards Doodle:** Alternative date at the 3rd KW'18 - **location?** 58 | 59 | ## Next Steps 60 | - [ ] Reconciliation of the base structure of the JSON Schema by WICE **Lutz and Hansjörg** till **late 19.12.2017** 61 | - [ ] Provide general regulations on basis of the preferences by WICE and YQ **Lutz** till **late 19.12.2017** 62 | - For this purpose one file will be created with a set of general regulations 63 | - [ ] Upload the UML diagram on GitHub **Josef** till **late 19.12.2017** 64 | - [ ] Upload JSON Schema and regulations on GitHub **Josef** till **late 19.12.2017** 65 | - [ ] Upload JSON Schema on GitHub **Hansjörg** till **late 19.12.2017** 66 | - [ ] Reconciliation of fix appointment for the 1st workshop in 2018 **Raphael** 67 | - [ ] Next appointment on **21.12.2017** at **10:00 am** 68 | -------------------------------------------------------------------------------- /Protocols/2017-12-19WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Jürgen, Andy, Philipp (minute taker) 4 | 5 | **Absent:** Andreas G. 6 | 7 | ## Workshop Protocol (from 15.12.2017) 8 | [2017-12-15WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-15WorkgroupTelko.md) - accidentally merged already due to [DecisionsMade.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DecisionsMade.md) 9 | 10 | - Accepted by all 11 | 12 | ## Final results for the 1st milestone 13 | [Provide deliverables on basis of Lutz' suggestions (Tool + Schema)](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/19) by @hschmidthh @JosefBraeuer till **15.12.2017** 14 | 15 | [Provide the regulations on how to design a generic domain model](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/22) by @lashauer @hschmidthh @JosefBraeuer till **15.12.2017** 16 | 17 | ### Lutz 18 | - [x] JSON Schema 'tree structure' **by @lashauer till early 19.12.2017** 19 | - Provided a basis schema: [OihDataRecordSchema](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/oih-data-record.schema.json) 20 | - Provided an example for the order example: [Order Example](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/examples/schema/order.schema.json) 21 | - Both schemas are work in progress and will be expanded e.g. by _description field_ 22 | - Would like to provide snippets and explanations inline (in the markdown file) and refer to the rest of the schema 23 | - [ ] General regulations for generic data models **by @lashauer till 19.12.17** 24 | - Will provide regulations according to the needs of WICE and YQ 25 | 26 | ### Hansjörg 27 | - [x] Generic data model addresses in the shape of an UML class diagram (attached) **by @hschmidthh till 19.12.17** 28 | * Write down concrete attributes and update UML diagram **by @hschmidt till 15.12.2017** 29 | - [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) Lutz: Field (String, enumeration etc.) to specify the sort of the address. 30 | - [x] Specific regulations for the generic data model addresses **by @hschmidthh till 19.12.17** 31 | - [ ] Generic data model addresses in the shape of a JSON schema **by @hschmidthh till late 19.12.17** 32 | 33 | #### UML Diagram 34 | - Classes like `phone` or `emails` are encapsulated to enable reusability, as e.g. a person can have more than one phone number and email 35 | - Categorization of e.g. phone numbers are done by categorizing the person 36 | - Base model is finished 37 | - Model will be expanded in later stages (e.g. adding attributes) 38 | 39 | #### Regulations 40 | - Regulations for creating a new model are written down in [RulesAndRegulations.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/RulesandRegulations.md) 41 | - Lutz/Raphael: Specific regulations and explanations (e.g. why is the categorization done for a person and not a phone number itself) is needed 42 | - Josef: These information are descriptions but not necessarily regulations. The information should be part of the MasterDataModel descriptions 43 | 44 | #### JSON-Schema 45 | - JSON File needs to be and will be created manually (Visual Paradigms complexity for converting the UML diagram into xml is to high) 46 | 47 | ### Josef 48 | - [x] Generic data model products in the shape of an UML class diagram (attached) **by @JosefBraeuer till 19.12.17** 49 | - Provided a UML-Schema and will upload the result on GitHub 50 | - [ ] Specific regulations for the generic data model products **by @JosefBraeuer till 19.12.17** 51 | - [ ] Generic data model products in the shape of a JSON schema **by @JosefBraeuer till late 19.12.17** 52 | 53 | ## Regular Meetings - calls 54 | **Postponed:** Fixed GoToMeeting every two weeks - **when?** 55 | 56 | ## 1st Workshop in 2018 57 | **Postponed towards Doodle:** Alternative date at the 3rd KW'18 - **location?** 58 | 59 | ## Next Steps 60 | - [ ] Reconciliation of the base structure of the JSON Schema by WICE **Lutz and Hansjörg** till **late 19.12.2017** 61 | - [ ] Provide general regulations on basis of the preferences by WICE and YQ **Lutz** till **late 19.12.2017** 62 | - For this purpose one file will be created with a set of general regulations 63 | - [ ] Upload the UML diagram on GitHub **Josef** till **late 19.12.2017** 64 | - [ ] Upload JSON Schema and regulations on GitHub **Josef** till **late 19.12.2017** 65 | - [ ] Upload JSON Schema on GitHub **Hansjörg** till **late 19.12.2017** 66 | - [ ] Reconciliation of fix appointment for the 1st workshop in 2018 **Raphael** 67 | - [ ] Next appointment on **21.12.2017** at **10:00 am** 68 | -------------------------------------------------------------------------------- /Protocols/2017-12-21WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Frank, Philipp (minute taker) **Absent:** Andreas G. 4 | 5 | ## Workshop Protocol (from 19.12.2017) 6 | * Agreeing [2017-12-19WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-19WorkgroupTelko.md) 7 | 8 | - Agreed on protocol. Will be merged into master. 9 | 10 | ## Walkthrough results on GitHub 11 | - [x] JSON schema [addresses - organization](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/organization.json) **by Hansjörg** 12 | - This schema decribes the object organization 13 | - Arrays of objects to represent the multiplicities e.g. an organization can have varying numbers of addresses 14 | - [x] JSON schema [addresses - person](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/person.json) **by Hansjörg** 15 | - This schema decribes the object person 16 | - [x] JSON schema [addresses - relation](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/relation.json) **by Hansjörg** 17 | - This schema decribes the object relation 18 | - Used to describe the different relation types e.g. organization to organization 19 | - [x] JSON schema [addresses - sharedDefinitions](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/sharedDefinitions.json) **by Hansjörg** 20 | - The schema includes definitions which are used in the three other JSON schemas, e.g. category 21 | - [x] JSON schema [products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/products/product.json) **by Josef** 22 | - Create consistent wording between UML and JSON 23 | - [x] [Regulations](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md#rules-and-regulation-for-mdms) **by Lutz** 24 | - Suggestion by Lutz: Always describe the first letter of a class in uppercase 25 | - Regulations which need to be fulfilled in order to create a new master data model that is contributed to the open integration hub 26 | - [DataModels.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) has been expanded and includes rules and regulations (some of them are derived from _Hansjörgs_ [RulesandRegulations.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/RulesandRegulations.md) 27 | - Mandatory if a dataset is pushed into the open integration hub: _ApplicationDataRecord_ 28 | - Snippets are used to explain and illustrate certain statements 29 | 30 | ## Provision results of our 1st milestone 31 | * Current results overview [of the Board](https://github.com/openintegrationhub/Board/blob/de265ec062beb0a293629bc5aa67320fb73de776/Milestones.md#result-3---generic-datamodel-for-addresses-and-products-including-guidelines-and-decision-processes) 32 | * Give [direct access](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MilestoneOne.md) through our repo page 33 | - Provision an entry page to our MS1 results, for our repo - use permanent links. 34 | 35 | ## Align the files and folders naming syntax 36 | - Source Code (currently json schemas) is located within a **src** folder in the root 37 | - All files (excluding source code files) will be named in _Camel Case_ format 38 | 39 | ## 1st Workshop in 2018 40 | * We stick with the 17th Jan. '18 - **Hafenamt** 41 | 42 | ## Contribute to the next milestone 43 | - Expanding the prototype by including a smart data framework (datahub) component on the elastic.io platform 44 | - Test models with real data and adjust the model 45 | - Feedback by the architects & developers for further discussions 46 | - Adjust the existing results to the feedback 47 | 48 | ## Next Steps 49 | - [ ] Create consistent wording between UML and JSON **Josef** till **late 21.12.2017** 50 | - [ ] Create consistent wording across all master data model files **Hansjörg, Lutz, Josef** till **21.12.2017** 51 | - [ ] Find a date for regular status calls - postponed till Andreas G. is back from vacation 52 | - [ ] Exporting the final results for milestone 1 into the needed format latest **03.01.2018** 53 | - [ ] Next appointment on **02.01.2018** at **14:00 am** 54 | - [ ] Next workshop takes place on the **17th of January 2018** at **Altes Hafenamt - Cloud Ecosystem** 55 | -------------------------------------------------------------------------------- /Protocols/2017-12-21WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Frank, Philipp (minute taker) **Absent:** Andreas G. 4 | 5 | ## Workshop Protocol (from 19.12.2017) 6 | * Agreeing [2017-12-19WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-19WorkgroupTelko.md) 7 | 8 | - Agreed on protocol. Will be merged into master. 9 | 10 | ## Walkthrough results on GitHub 11 | - [x] JSON schema [addresses - organization](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/organization.json) **by Hansjörg** 12 | - This schema decribes the object organization 13 | - Arrays of objects to represent the multiplicities e.g. an organization can have varying numbers of addresses 14 | - [x] JSON schema [addresses - person](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/person.json) **by Hansjörg** 15 | - This schema decribes the object person 16 | - [x] JSON schema [addresses - relation](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/relation.json) **by Hansjörg** 17 | - This schema decribes the object relation 18 | - Used to describe the different relation types e.g. organization to organization 19 | - [x] JSON schema [addresses - sharedDefinitions](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/sharedDefinitions.json) **by Hansjörg** 20 | - The schema includes definitions which are used in the three other JSON schemas, e.g. category 21 | - [x] JSON schema [products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/products/product.json) **by Josef** 22 | - Create consistent wording between UML and JSON 23 | - [x] [Regulations](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md#rules-and-regulation-for-mdms) **by Lutz** 24 | - Suggestion by Lutz: Always describe the first letter of a class in uppercase 25 | - Regulations which need to be fulfilled in order to create a new master data model that is contributed to the open integration hub 26 | - [DataModels.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) has been expanded and includes rules and regulations (some of them are derived from _Hansjörgs_ [RulesandRegulations.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/RulesandRegulations.md) 27 | - Mandatory if a dataset is pushed into the open integration hub: _ApplicationDataRecord_ 28 | - Snippets are used to explain and illustrate certain statements 29 | 30 | ## Provision results of our 1st milestone 31 | * Current results overview [of the Board](https://github.com/openintegrationhub/Board/blob/de265ec062beb0a293629bc5aa67320fb73de776/Milestones.md#result-3---generic-datamodel-for-addresses-and-products-including-guidelines-and-decision-processes) 32 | * Give [direct access](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MilestoneOne.md) through our repo page 33 | - Provision an entry page to our MS1 results, for our repo - use permanent links. 34 | 35 | ## Align the files and folders naming syntax 36 | - Source Code (currently json schemas) is located within a **src** folder in the root 37 | - All files (excluding source code files) will be named in _Camel Case_ format 38 | 39 | ## 1st Workshop in 2018 40 | * We stick with the 17th Jan. '18 - **Hafenamt** 41 | 42 | ## Contribute to the next milestone 43 | - Expanding the prototype by including a smart data framework (datahub) component on the elastic.io platform 44 | - Test models with real data and adjust the model 45 | - Feedback by the architects & developers for further discussions 46 | - Adjust the existing results to the feedback 47 | 48 | ## Next Steps 49 | - [ ] Create consistent wording between UML and JSON **Josef** till **late 21.12.2017** 50 | - [ ] Create consistent wording across all master data model files **Hansjörg, Lutz, Josef** till **21.12.2017** 51 | - [ ] Find a date for regular status calls - postponed till Andreas G. is back from vacation 52 | - [ ] Exporting the final results for milestone 1 into the needed format latest **03.01.2018** 53 | - [ ] Next appointment on **02.01.2018** at **14:00 am** 54 | - [ ] Next workshop takes place on the **17th of January 2018** at **Altes Hafenamt - Cloud Ecosystem** 55 | -------------------------------------------------------------------------------- /Protocols/2018-01-02WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Frank, Philipp (minute taker) **Absent:** Andreas G. 4 | 5 | ## Workshop Protocol (from 21.12.2017) 6 | * Has been accepted on GitHub [2017-12-21WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-21WorkgroupTelko.md) 7 | 8 | ## Schema definitions 9 | * Example excerpt [shared-definitions.json](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/35#issuecomment-353558851) on how to distinguish multiple network IDs 10 | - Current type string for `social` doesn't restrict the input e.g. it can be an url, network name, etc. There will be a lot of different inputs. Therefore a restriction is not applicable. 11 | - The suggestion below [- see issue 35 (comment by Raphael) -](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/35) is a proper way to model the entity social, so that there are loose restrictions but completeness is ensured. 12 | _Suggestion:_ 13 | 14 | ``` 15 | "Social": { 16 | "type": "object", 17 | "properties": { 18 | "network" : { 19 | "type" : "string", 20 | "description": "Provision name of social network" 21 | }, 22 | "id": { 23 | "type": "string", 24 | "description": "Provision social network ID" 25 | } 26 | }, 27 | ``` 28 | 29 | ## Unify/Merge VisualPradigm projects 30 | - Visual Paradigm _projects_ need to be part of the open integration hub project (not part of the single partner projects/repos), to enhance collaboration. 31 | - The solution finding process for this issue is moved to the workshop on the 17.01.2018 32 | - Provide a suggestion how to solve/handle this issue **Lutz** 33 | 34 | ## Workshop agenda planning 35 | * Expanding the prototype by including a smart data framework (data hub) component on the elastic.io platform 36 | - It must be clarified which functionalites can be implemented on the elastic.io platform / boundaries of the elastic.io platform must be clarified. (Keyword: Adapter) 37 | - _Josef:_ The "data hub component" is not problematic. Elastic.io needs to be asked for support, when it comes to the mapping of tree structures (aggregates) 38 | - A call with Igor needs to be arranged prior to the workshop to discuss the next steps of the prototype 39 | * Test models with real data and adjust the model 40 | * Explicit feedback by the architects & developers for further discussions 41 | - Roadmap for the next milestone (30.06.2018) 42 | - What needs to be done / provided? 43 | - What is the output of the "prototype 0.5" 44 | - ... 45 | 46 | ## Report to the DLR 47 | - Delete TOCs 48 | - JSON-Schemas will be reported as .json files 49 | 50 | ## Next Steps 51 | - [ ] Provide a suggestion how to solve/handle the visual paradigm projects **Lutz** till **17.01.2018** 52 | - [ ] Arrange call with Igor **Raphael** till **16.01.2018** 53 | - [ ] Next appointment on **17.01.2018** at **09:00 am** at **Cloud Ecosystem - Altes Hafenamt** 54 | -------------------------------------------------------------------------------- /Protocols/2018-01-02WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Josef, Raphael **Guests:** Frank, Philipp (minute taker) **Absent:** Andreas G. 4 | 5 | ## Workshop Protocol (from 21.12.2017) 6 | * Has been accepted on GitHub [2017-12-21WorkgroupTelko.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/Protocols/2017-12-21WorkgroupTelko.md) 7 | 8 | ## Schema definitions 9 | * Example excerpt [shared-definitions.json](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/35#issuecomment-353558851) on how to distinguish multiple network IDs 10 | - Current type string for `social` doesn't restrict the input e.g. it can be an url, network name, etc. There will be a lot of different inputs. Therefore a restriction is not applicable. 11 | - The suggestion below [- see issue 35 (comment by Raphael) -](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/35) is a proper way to model the entity social, so that there are loose restrictions but completeness is ensured. 12 | _Suggestion:_ 13 | 14 | ``` 15 | "Social": { 16 | "type": "object", 17 | "properties": { 18 | "network" : { 19 | "type" : "string", 20 | "description": "Provision name of social network" 21 | }, 22 | "id": { 23 | "type": "string", 24 | "description": "Provision social network ID" 25 | } 26 | }, 27 | ``` 28 | 29 | ## Unify/Merge VisualPradigm projects 30 | - Visual Paradigm _projects_ need to be part of the open integration hub project (not part of the single partner projects/repos), to enhance collaboration. 31 | - The solution finding process for this issue is moved to the workshop on the 17.01.2018 32 | - Provide a suggestion how to solve/handle this issue **Lutz** 33 | 34 | ## Workshop agenda planning 35 | * Expanding the prototype by including a smart data framework (data hub) component on the elastic.io platform 36 | - It must be clarified which functionalites can be implemented on the elastic.io platform / boundaries of the elastic.io platform must be clarified. (Keyword: Adapter) 37 | - _Josef:_ The "data hub component" is not problematic. Elastic.io needs to be asked for support, when it comes to the mapping of tree structures (aggregates) 38 | - A call with Igor needs to be arranged prior to the workshop to discuss the next steps of the prototype 39 | * Test models with real data and adjust the model 40 | * Explicit feedback by the architects & developers for further discussions 41 | - Roadmap for the next milestone (30.06.2018) 42 | - What needs to be done / provided? 43 | - What is the output of the "prototype 0.5" 44 | - ... 45 | 46 | ## Report to the DLR 47 | - Delete TOCs 48 | - JSON-Schemas will be reported as .json files 49 | 50 | ## Next Steps 51 | - [ ] Provide a suggestion how to solve/handle the visual paradigm projects **Lutz** till **17.01.2018** 52 | - [ ] Arrange call with Igor **Raphael** till **16.01.2018** 53 | - [ ] Next appointment on **17.01.2018** at **09:00 am** at **Cloud Ecosystem - Altes Hafenamt** 54 | -------------------------------------------------------------------------------- /Protocols/2018-01-17Workshop.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | **Attendees:** Lutz, Raphael, Andy, Robin, Stephan, Frank, Renat, Philipp 3 | **Absent:** Andreas, Josef 4 | 5 | ## Tasks of the Workgroup 6 | - The workgroup helps to realize the POC 1 - POC 3 from the [roadmapV1](https://github.com/openintegrationhub/Architecture/blob/roadmap/Roadmap/RoadmapV1.md) 7 | - Analytical approach to improve the standard data model (configuration) 8 | - Evaluating the standard data model by comparing it to existing standards (EDIFACT, BiPRO, InfoSphere, etc.) 9 | - Deriving mapping rules to map the "OIH standard" against existing Standards 10 | - Technical implementation is done by the _architecture workgroup_. See [repository architecture workgroup](https://github.com/openintegrationhub/Architecture) 11 | - Rules and regulations of the data models 12 | - How do the data models evolve? What is the process to decide on suggested changes (Versioning) - for example? 13 | - How shall new data models be developed 14 | - Documentation for the implementation of transformer (mapping) 15 | - The workgroup helps to achieve the results of milestone 2 by contributing to the "Access to the OIH platform 0.5" and "Document procedure model for integration cloud provider" 16 | 17 | ## Current Status of the Models 18 | - Presentation of the results for milestone 1 19 | - Derived information for the _architecture workgroup:_ The architecture must consider that multiple data models (will) exist 20 | 21 | ## Roadmap 22 | - Currently the POC 1 is not finished because the integration between SilverERP and Snazzy Contacts is not working 23 | - Difference between POC 1 and POC 2 is the application of the adapter quality guidelines on the SilverERP and Snazzy Contacts adapters 24 | - A documentation of the current status of POC 1 is missing yet (See _derived tasks_) 25 | - Documentation of the meta models is not part of the API 26 | 27 | ## Intital Specs of the Smart Data Framework 28 | See the current status of the specs under [DataHub.md](https://github.com/openintegrationhub/Microservices/blob/master/DataHub.md) 29 | 30 | - Raw data is syntactically transformed data 31 | - Decoupling between adapter and transformer 32 | - Adapter can talk to the transformer and/or to other adapters. Thus semantic transformation via the transformer and individual integrations are enabled 33 | - (Adapter holds syntactically transformed data). Not mandatory: ISV doesn't have to upload the data into the raw data storage. 34 | - **Meta Data Management API** uploads the information about the metadata (list of objects) 35 | - **Data Management API** uploads the actual data (data records) 36 | 37 | Within the scope of this topic the following illustrations was drawn: 38 | 39 | ![SmartDataFramework](Assets/SmartDataFramework.svg) 40 | 41 | ## Further Thoughts 42 | - Synchronization of roles & rights / user & user roles has to be enabled by the open integration hub. It will most likely be realized by an additional domain such as addresses and products 43 | - The identities Basaas wants to synchronize are not stored within the identity management but will be realized through the aforementioned additional domain 44 | - Various aspects of the synchronization of user & roles are needed. See derived tasks "exchange ideas regarding the synchronization of user & roles" 45 | Distinction between identity management of the open integration hub (minimal functionality to manage identities) and the domain "roles & right / user & roles" 46 | 47 | ## Next Steps / Derived Tasks 48 | - [ ] Elaborate common structure for the documentation of the standard data model (JSON-Schema, UML diagrams, textual description) **Raphael + Lutz** 49 | - [ ] Expand and further describe the superordinate structure for the domain models (see _OIHDataRecord_) **Raphael + Lutz** 50 | - [ ] Elaborate/expand rules and regulations for the evolution of standard data models (How do the data models evolve?, How shall new models be created, how often are new versions created, ...) **Raphael + Lutz** 51 | - [ ] Consider the "Meta-Meta Model" (Definition used by **Renat**) with respect to the capabilities of the JSON Schema (E.g. types like date, currency, etc.) 52 | - [ ] Compare the standard data model (configuration) with existing standards (EDIFACT, BiPRO, InfoSphere, etc.) **Raphael** 53 | - [ ] Document the current status of the POC 1 (The following steps break down the concrete tasks) **Andy + Josef** 54 | - [ ] Provide an API documentation / interface documentation - **public** 55 | - [ ] Create JSONata expression (mapping) 56 | - [ ] Create a mapping table 57 | - [ ] Document which elastic.io components where used and why 58 | - [ ] Compare the documentations of YQ and Wice and unify them 59 | - [ ] For POC 2: Apply the adapter quality guidelines on the adapters by YQ and Wice **Philipp** 60 | - [ ] Decide on technical realization of the connectors **Franz** 61 | - [ ] (Technical) realization of the integration node from [POC 2](https://github.com/openintegrationhub/Architecture/blob/roadmap/Roadmap/RoadmapV1.md#poc-2--point-to-point-integration-of-isv-applications-using-connectors) **Franz + Igor** 62 | - [ ] (Technical) realization of the smart data framework with master data management (mdm) **Franz + Igor** 63 | - [ ] Exchange ideas regarding the synchronization of user & roles **Lutz + Selim** 64 | -------------------------------------------------------------------------------- /Protocols/2018-02-23WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 23.02.2018 2 | 3 | **Attendees:** Elke, Andreas (IESE), Josef 4 | 5 | ## Updates on next steps 6 | * Upload SilverERP Adapter on GitHub **by Josef** 7 | * Done. Upload pending. 8 | * Commit to the OData documentation standard for public REST APIs - recommended **by Andy & Dieter** 9 | * Examined 10 | * Accepted 11 | * Induction phase 12 | * Build and share JSONata expressions - as technical mappings **by Shterion & Josef** 13 | * Not yet discussed 14 | * Discussion until next regular call (09.03.2018) 15 | * Convict and share that proprietary models mapping - as mapping table **by Andy & Josef** 16 | * Not yet started. 17 | * Exists issue? **@Raphael** 18 | * Document your findings of the development and runtime of the adapters at elastic.io **by Shterion & Josef** 19 | * Documentation by Shterion available 20 | * Not clear wheter already uploaded 21 | * Document the assessment of limitations for specialized models under consideration of versioning **by Elke** 22 | * Ideas added to corresponding issue 23 | * Review requested **@All** 24 | * Plan to challenge the standard data points under realistic conditions **by Raphael** 25 | * ? 26 | * Collect the data points according to actually transmitted data at integration scenarios **by Raphael** 27 | * Survey design in progress 28 | -------------------------------------------------------------------------------- /Protocols/2018-02-23WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 23.02.2018 2 | 3 | **Attendees:** Elke, Andreas (IESE), Josef 4 | 5 | ## Updates on next steps 6 | * Upload SilverERP Adapter on GitHub **by Josef** 7 | * Done. Upload pending. 8 | * Commit to the OData documentation standard for public REST APIs - recommended **by Andy & Dieter** 9 | * Examined 10 | * Accepted 11 | * Induction phase 12 | * Build and share JSONata expressions - as technical mappings **by Shterion & Josef** 13 | * Not yet discussed 14 | * Discussion until next regular call (09.03.2018) 15 | * Convict and share that proprietary models mapping - as mapping table **by Andy & Josef** 16 | * Not yet started. 17 | * Exists issue? **@Raphael** 18 | * Document your findings of the development and runtime of the adapters at elastic.io **by Shterion & Josef** 19 | * Documentation by Shterion available 20 | * Not clear wheter already uploaded 21 | * Document the assessment of limitations for specialized models under consideration of versioning **by Elke** 22 | * Ideas added to corresponding issue 23 | * Review requested **@All** 24 | * Plan to challenge the standard data points under realistic conditions **by Raphael** 25 | * ? 26 | * Collect the data points according to actually transmitted data at integration scenarios **by Raphael** 27 | * Survey design in progress 28 | -------------------------------------------------------------------------------- /Protocols/2018-03-23WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Lutz, Hansjörg, Philipp, Andreas, Jürgen, Frank, Elke, Dieter, Robin
4 | **Absent:** Josef 5 | 6 | # Topics 7 | ## Current Status 8 | 1. Address model has been expanded by anylazing different solutions and standards 9 | - Exemplary solutions were: 10 | - Salesforce 11 | - Exact 12 | - Weclapp 13 | - SageOne 14 | - Standards that were analyzed: 15 | - vCard 16 | - BiPro 17 | - Infosphere (partly) 18 | - The elaborations include an expanded [UML class diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/969645fe280641d62a9dcb085e2b7cf371d72279/MasterDataModels/Assets/OIHMasterDataModelAddresses_V2.png), a [tabular description](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/969645fe280641d62a9dcb085e2b7cf371d72279/MasterDataModels/AddressModelV2Description.md) and an initial Swagger documentation (not published yet) 19 | 2. Creation of an [initial procedure model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/1f7e46664b8f2a3b39326d43a30816e6009a9dc8/MasterDataModels/ProcedureModelExtension.md) to extend the Master Data Models 20 | - This procedure model also includes a [form](https://goo.gl/forms/OjPFdyQ7qvDLMQ442) to request model changes 21 | 3. Wice (Shterion) is working on implementing a rudimentary database component which represents the master data model to enable data synchronization via the address master data model 22 | 4. First versions [SnazzyContactsAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/SnazzyContactsAdapter) and [WiceCRMAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/WiceAdapter) are finished (including API documentation for SnazzyContacts and WiceCRM) and ready for quality checks. 23 | 5. First version of [SilverERPAdapter](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/SilverpContactsAdapter) exists. 24 | 6. [First ideas](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/SpecializedDataModels.md), [examples](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/SpecializedDataModelsExample.md) and [conceptional elaborations](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/776d87934893aeeca33181c9c95943533ac86a93/VersioningMasterDataModel.md) were created to expand the procedure model 25 | 26 | ## Next Steps 27 | - [ ] Reconciliation between **Lutz**, **Hansjörg** and **Philipp** regarding the address master data model (Monday, 23.03.2018 11:15) 28 | - [ ] Conceptional elaborations for the procedur model **Elke** and **Lutz** 29 | - [ ] Documentation of the proprietary (SilverERP) data model **Dieter** and **Josef** 30 | - [ ] Work on implementing the database component on elastic.io **Shterion** 31 | -------------------------------------------------------------------------------- /Protocols/2018-04-06WorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Hansjörg, Jürgen, Philipp, Dennis (minute taker), **Absent:** Lutz, Josef, Andreas 4 | 5 | ## Decisions made: 6 | - [ ] Philipp will be added as a comitter to the workgroup (election is pending) 7 | - [ ] New Workgroupleader will be Hansjörg (election is pending) 8 | - [x] New document will be created: template for further MasterDataModels documentation 9 | 10 | ## Tasks and next steps 11 | - Philipp: 12 | - Call with Hansjörg to clean up the ZenHub board (09.04.18) 13 | - Call with Hansjörg to discuss the progress with YQ (09.04.18) 14 | - Updates JSON schemes and documentation 15 | - Communicates need for quality checks of snazzyContact and wiceCRM to connectors workgroup 16 | - Creates new document „MasterDataModel-template“: criteria-set up and initial structuring of the new template for further domains (in cooperation with Dennis) 17 | 18 | - Hansjörg: 19 | - Gives feedback in Slack that he is – until further notice - the new workgroup leader 20 | - Delivers technically content for the „MasterDataModels-template“ 21 | 22 | - Dennis: 23 | - Creates new document „MasterDataModel-template“: criteria-set up and initial structuring of the new template for further domains (in cooperation with Philipp) 24 | 25 | - Shterion: 26 | - Develops data base components on elastic.io approximately until the next call on 20.04 27 | 28 | #### In a subsequent meeting the following topics have been agreed upon between Philipp, Josef and Dieter: 29 | 30 | - Documentation of the master data model for the domain products: 31 | - Have the two standards bipro & infosphere been considered? If **yes**: how? If **no**: why and why not? 32 | - Disambiguation: What is a **product** in the context of the _MasterDataModelProducts_ ? 33 | - Create a section for _FAQs_: 34 | - How is the following case covered by the _MasterDataModelProducts_: An article is a purchase article as well as a production item? 35 | - Finish the _MasterDataModelProducts_ description table. 36 | 37 | - Dieter: 38 | - Will work on the topic till the 04.05.2018 39 | -------------------------------------------------------------------------------- /Protocols/2018-04-06WorkgroupTelko.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Hansjörg, Jürgen, Philipp, Dennis (minute taker), **Absent:** Lutz, Josef, Andreas 4 | 5 | ## Decisions made: 6 | - [ ] Philipp will be added as a comitter to the workgroup (election is pending) 7 | - [ ] New Workgroupleader will be Hansjörg (election is pending) 8 | - [x] New document will be created: template for further MasterDataModels documentation 9 | 10 | ## Tasks and next steps 11 | - Philipp: 12 | - Call with Hansjörg to clean up the ZenHub board (09.04.18) 13 | - Call with Hansjörg to discuss the progress with YQ (09.04.18) 14 | - Updates JSON schemes and documentation 15 | - Communicates need for quality checks of snazzyContact and wiceCRM to connectors workgroup 16 | - Creates new document „MasterDataModel-template“: criteria-set up and initial structuring of the new template for further domains (in cooperation with Dennis) 17 | 18 | - Hansjörg: 19 | - Gives feedback in Slack that he is – until further notice - the new workgroup leader 20 | - Delivers technically content for the „MasterDataModels-template“ 21 | 22 | - Dennis: 23 | - Creates new document „MasterDataModel-template“: criteria-set up and initial structuring of the new template for further domains (in cooperation with Philipp) 24 | 25 | - Shterion: 26 | - Develops data base components on elastic.io approximately until the next call on 20.04 27 | 28 | #### In a subsequent meeting the following topics have been agreed upon between Philipp, Josef and Dieter: 29 | 30 | - Documentation of the master data model for the domain products: 31 | - Have the two standards bipro & infosphere been considered? If **yes**: how? If **no**: why and why not? 32 | - Disambiguation: What is a **product** in the context of the _MasterDataModelProducts_ ? 33 | - Create a section for _FAQs_: 34 | - How is the following case covered by the _MasterDataModelProducts_: An article is a purchase article as well as a production item? 35 | - Finish the _MasterDataModelProducts_ description table. 36 | 37 | - Dieter: 38 | - Will work on the topic till the 04.05.2018 39 | -------------------------------------------------------------------------------- /Protocols/2018-05-29CollaborationAndDocumentsCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Peter, Nils, Matthias, Benoit, Robin, Philipp **Absent:** - 4 | 5 | ## Workgroup Manager Election 6 | 7 | - Philipp will be the new workgroup manager for the _Collaboration and document models_ workgroup. 8 | 9 | ## Regular Call 10 | 11 | - The regular workgroup call will take place every 2nd tuesday from 10:00 - 11:00 12 | 13 | ## Status Updates 14 | ### Agindo 15 | - Current model on paper 16 | - Internal meeting on Monday on e-mail and calendar 17 | - User administration solution comparisons are missing 18 | - ScopeVisio & CenterDevice have already been viewed 19 | - Structure e.g. rights system at Office365 much clearer than at SV & CD 20 | - SAPbyDesign would be an option 21 | - However very prefabricated rolls 22 | - Will be consulted again in the near future 23 | - Generally defined part for all industries 24 | - Specification for different industries 25 | - At the next workgroup call, the model is digitized and can be used for discussion. 26 | 27 | ### ELO 28 | 29 | - Various standards already viewed CIMS interface 30 | - Contact for DocuWare still needed 31 | - Fork for ELO & Agindo to work together on problems internally 32 | 33 | ## Next Steps 34 | - [ ] Revise the current model and present the first draft at the next workgroup call (12.06) **Peter** 35 | - [ ] Expand existing model and present the first draft at the next workgroup call (12.06) **Nils, Matthias, Benoit** 36 | - [ ] Create a fork for ELO & Agindo to internally work on common problems **Nils & Peter** 37 | - [ ] Set up regular workgroup call and send out invitations **Philipp** 38 | - [ ] Refer to Frank for a contact to DocuWare **Philipp** 39 | -------------------------------------------------------------------------------- /Protocols/2018-06-12CollaboratioAndDocumentsCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Hansjörg, Jürgen, Philipp, Dennis (minute taker), **Absent:** Lutz, Josef, Andreas 4 | 5 | ## Protocol 6 | 7 | ## Agindo 8 | - Absent because of important appointments 9 | 10 | ## ELO 11 | - First draft for object model 12 | - Differs from the CIMS model in multiple points 13 | - Datamodel for types is missing yet 14 | - Reconciliation next week to further work on the current version 15 | - Revised version will be published on GitHub 16 | 17 | ## Next Steps 18 | - [ ] Prepare world café for summer connection event **Nils** & **Peter** 19 | -------------------------------------------------------------------------------- /Protocols/2018-07-17CommonWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Philipp, Elke, Andreas, Franz 4 | 5 | ## Protocol 6 | 7 | ## Housekeeping 8 | - Philipp was unanimously chosen as the workgroup manager 9 | - Workgroup Call will take place every 2nd monday at 14:00 - 15:00 10 | - Group will discuss topics regarding 11 | - conventions 12 | - oihdatarecord (core model) 13 | - versioning 14 | - other superordinated topics 15 | 16 | ## Versioning 17 | - Everyone reads the current documentation to have a common base to start the discussion 18 | - Question: Do we need the "Impacts on..." column within the ModelChanges.md? 19 | - Thresholds may need to be reconsidered 20 | 21 | # OIHDataRecord 22 | - Franz reads into the OIHDataRecord 23 | - A transactionID could be useful to identify transactions made on a specific data record 24 | - Does the oihUid apply to both response and request for an update? 25 | 26 | # Conventions 27 | - Do we allow elements & attributes? Discussion postponed to next meeting 28 | 29 | ## Next Steps 30 | - [ ] Talk to Lutz about transactionIDs within the oihdatarecord **Elke** 31 | - [ ] Read into the versioning documentation **all** 32 | - [ ] Reconsider thresholds for incorporating proposed model changes **all** 33 | -------------------------------------------------------------------------------- /Protocols/2018-07-24UserTenantsRightsWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Philipp, Elke, Andreas, Franz 4 | **Absent:** 5 | 6 | ## Protocol 7 | 8 | # Housekeeping 9 | - Please make sure that the Workgroup Manager creates a protocol for every regular call 10 | - Template can be found under [protocol template](TEMPLATE.md) 11 | 12 | 13 | ## WorkgroupManger 14 | - Hans was elected unanimously as the workgroup manager 15 | 16 | # Scope 17 | - History: 18 | - Derived from usecases: I want to create a dataset in a target system. Every dataset/resource has an owner. We need to transfer the owner 19 | - Basaas wants to create superordinated User/Tenants which need to be mapped to the owner of the datasets in the connected systems 20 | - User, Tenants & Right stucture is needed within Open Integration Hub 21 | - Expectation Basaas: Derive UseCases/UserStories and start with a simple model that is iteratively expanded 22 | - Expectation Wice: Adress model does explicit not cover rights 23 | - Thoughts ELO: Central repository where Credentials are shared is a typical solution within integration scenarios 24 | - Central user mapping because everything else needs a lot of management effort 25 | - Creation of a 3rd party key for identifying the users across systems 26 | 27 | - 3 dimensions of user, tenants, rights & groups 28 | 29 | **Scope:** Focus on synchronizing tenants, user & groups 30 | 31 | ## Next Steps 32 | - [ ] Collection of UseCases & UserStories **Responsibility: All** 33 | -------------------------------------------------------------------------------- /Protocols/2018-07-30CommonWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Philipp, Elke, Andreas, Franz 4 | 5 | ## Protocol 6 | 7 | # OIHDataRecord 8 | - It likely that an additional "warpper" is needed e.g. "oihmessage" 9 | - oihmessage would include the oihdatarecord and an oihheader 10 | - oihheader would include additional information such as a transactionId, a request time and possibly a "tenantID" (wording is not fix yet and needs to be revised) 11 | 12 | # Conventions 13 | - Do we allow elements & attributes? Discussion postponed to next meeting. Idea derived from XML. 14 | 15 | --> No differentiation between elements and attributes in JSON schemas/objects. Therefore no need to decide on this question. 16 | 17 | ## Versioning 18 | - Postponed 19 | 20 | ## Next Steps 21 | - [ ] Create graphical overview of oihmessage and oihheader 22 | -------------------------------------------------------------------------------- /Protocols/2018-07-30DocumentsWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | **Attendees:** Dirk (REWOO), Tobias (REWOO), Martin (Dropscan), Nils (ELO), Philipp (CES) 2 | 3 | # Document Model Feedback 4 | 5 | **Current Model:** [Master Data Model Documents](https://github.com/openintegrationhub/Data-and-Domain-Models/tree/master/MasterDataModels/Documents) 6 | 7 | - Cardinalities are missing 8 | - Will be added 9 | - Subresource object should have a link to the _version_ object not to the _document_ object 10 | - Link will be changed, so subresources can be defined for different versions of a document 11 | - Should ACL have a link to _version_ instead of _object_? 12 | - ACL has a link to _object_ to cover different cases e.g. giving permissions for a complete folder (would not be possible if ACL has a link to _version_ instead of _object_) 13 | - Meaning of _relation_? 14 | - Relation is meant to describe the relation between two documents e.g. order and invoice 15 | 16 | # Sending Binary Data 17 | - How can an application send documents via the open integration hub? 18 | 19 | 1. Send complete files via Open Integration Hub (High traffic / payload) 20 | 2. Send an hashed url which can be public and/or limited to a certain timespan 21 | - Document could be downloaded via the url 22 | 23 | - Discussion about a proxy to sign URLs to avoid security issues. Can the **Open Integration Hub** cover this taks? 24 | 25 | # Modification Object 26 | - Nils suggests a modification object to store information about creation/modifcation time and creator/modifier (and lockedBy information) 27 | 28 | # Tasks 29 | - [ ] Adjust UML Diagram according to agreed changes 30 | - [ ] Discuss topic regarding creation of URLs within the architecture group 31 | - [ ] Discuss topic regarding modification object within the common data model aspects group 32 | 33 | # Notes 34 | - As most of the participants are on vacation the next two weeks, the next call will take place in 4 weeks (27.08.18) 35 | 36 | -------------------------------------------------------------------------------- /Protocols/2018-08-13CommonWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Philipp, Elke, Andreas, Franz 4 | 5 | ## Protocol 6 | 7 | # Versioning 8 | - A graphical overview of the decision process workflow could help to get a quick overview of the process 9 | - Thresholds for incorporating changes into a data model 10 | - Decisions should be made by Committer not by connected applications. Otherwise there would be a communication overhead and the process would take to long. 11 | - Decision process guidelines have to be more precise 12 | 13 | # OihMessage 14 | - OihMessage needs the oihMessage attribute changed into oihMessageHeader 15 | - Modification object should be more generic 16 | - Split into userId, Type (Creation, Modification) and Timestamp 17 | 18 | # Conventions 19 | - Common attribute table must be revised to check whether it is appropriate or not 20 | 21 | ## Next Steps 22 | - [ ] Create graphical overview of [decision process workflow](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Versioning/VersioningMasterDataModel.md#workflows) **andreas** 23 | - [ ] Change [threshold table](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Versioning/VersioningMasterDataModel.md#decision-process-guidelines) of decision process **philipp** 24 | - [ ] Define decision process more precisely **philipp** 25 | - [ ] Revise [OIHMessage and Modification object](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/d866cc99c172285f3f73bef810e24782f1758d24/MasterDataModels/Assets/OihMessageWithModifcation.png) **philipp** 26 | - [ ] Review [Release Cylce part](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Versioning/VersioningMasterDataModel.md#release-cycles) **Franz, Elke & Andreas** 27 | - [ ] Review changes and additions from all 5 tasks above **all** 28 | -------------------------------------------------------------------------------- /Protocols/2018-08-27CommonWorkgroupCall_Documents.md: -------------------------------------------------------------------------------- 1 | ## Protocol - 27.08.2018, Documents Workgroup Call 2 | 3 | **Attendees:** Nils, Folker, Arne, Dirk, Dennis 4 | 5 | ### Question: 6 | 7 | ``` 8 | Maybe this will make it hard for implementors to automically map and exchange simple meta data between different systems. 9 | An alternative approach would be, to have classes for the "most commonly used" document types (e.g. "Image", "Mail", "Word Processor", 10 | "Audio", "Video") which already have the most important meta information as properties (e.g. "Resolution" and "Color Depth" for images, 11 | "Sender", "Recipient", "Subject" ... for mails and so on). All kinds of documents not fitting into these categories could still use the 12 | generic "Document" class and describe their custom-properties solely by the meta-model. This solution wouldn't look as elegant as the 13 | currently suggested generic approach , but would make it presumably easier to use the model and to search for documents, meeting some 14 | simple requirements (e.g. "give me all mails with Joe Doe as sender"). Don't get me wrong: I'm totally fine with the generic approach, 15 | I just think we should be sure about the implications. By the way: the SubResource-class doesn't have a metadata-property. 16 | So we would be restricted to the set of predefined attributes for them, right? 17 | ``` 18 | 19 | ### Discussions: 20 | - "Create classes for the most commonly used document types: e.g. "Image", "Mail", "Word Processor", "Audio", "Video"" 21 | - Dirk: not enough attributes in the "document" object. This way, a lot of mapping would be necessary 22 | - Nils: geo-id as a solution for mapping problem not possible: implementation-costs would rise, models need to be self-sufficient 23 | 24 | - Idea: use a pre-defined bunch of attributes for each sub class of a parent class 25 | - Idea: separation of normal and technical metadata models 26 | 27 | ### Next Steps 28 | - [ ] Further discussion of the ideas above **All** 29 | - [ ] Create Excel sheet to discuss further standard metadata models **Dennis** 30 | - [ ] Solve issue: redye standalone objects' color of the standard master data model into yellow, following the contribution guidelines **Nils** 31 | - [ ] Define and add further possible attributes in the Excel sheet [Discussion - Standard Metadata Models](https://docs.google.com/spreadsheets/d/1cm6fJFQqVmNusaQIIFaUK7CnMInM1LSz3m1tAz0FV4g/edit?usp=sharing) **All** 32 | - [ ] Review changes and additions from all 4 tasks above **All** 33 | -------------------------------------------------------------------------------- /Protocols/2019-08-21UserTenantsRightsWorkgroupCall.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** Philipp, Hansjörg, Hans 4 | 5 | # Housekeeping 6 | - Please add more use cases [-> google doc](https://docs.google.com/document/d/1B_4wSOBe-_Xbws6fjlk9s0xV1F6zA5BmXvNmRCulr_s/edit?usp=sharing) 7 | 8 | # Topics 9 | **Tenant/User (T/U) in general** 10 | 1. investigated references and concepts already discussed or developed within OIH, found a few references 11 | * [MetaModel](../MasterDataModels/MetaModel.md) 12 | * [OihMessage](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/oihHeader/MasterDataModels/Assets/OihMessage.svg) 13 | 2. IAM service organizes users as members of distinct tenants 14 | * [OIH IAM Service](https://github.com/openintegrationhub/openintegrationhub/tree/master/services/iam) 15 | 16 | First conclusions 17 | - T/U Rarely referenced nor specified in a generic way 18 | - IAM implements simple T/U to authorize account management 19 | - -> design T/U Data Model to equalize existing concepts 20 | 21 | **Rights & Permissions** 22 | 23 | Discussed following scenarios 24 | 25 | 1. 26 | - Service A has access management 27 | - Service B spares access control, all data is public 28 | - Sensitive data will be transferred from A to B and is henceforth public 29 | 2. 30 | - Organization provides a pipeline to transfer data from Service A to Service B 31 | - Members with access to flow will transfer data without holding individual rights 32 | 33 | Consequential issues 34 | - Do we have to find intersections between different access rights and derive suitable permissions? Optional or mandatory? 35 | - Could we store tokens for different users, flows, tenants - delegate access management to every service involved? 36 | 37 | 38 | 39 | ## Next Steps 40 | - Further discussion on topics 41 | -------------------------------------------------------------------------------- /Protocols/MeetingAgenda.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openintegrationhub/Data-and-Domain-Models/5115f926ec088bdbab7c0c3b916d72b19f18071d/Protocols/MeetingAgenda.docx -------------------------------------------------------------------------------- /Protocols/TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Protocol 2 | 3 | **Attendees:** _names_
4 | **Absent:** _names_ 5 | 6 | ## Protocol 7 | 8 | # Topic1 9 | - ... 10 | - ... 11 | 12 | ## Topic1.1 13 | - ... 14 | - ... 15 | 16 | # Topic2 17 | - ... 18 | - ... 19 | 20 | # Topic3 21 | - ... 22 | - ... 23 | 24 | ## Topic3.1 25 | - ... 26 | - ... 27 | 28 | ### Topic3.1.1 29 | 30 | ## Next Steps 31 | - [ ] Create protocol **Responsibility: _name_** 32 | - [ ] ... 33 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | Open Integration Hub (OIH) 3 |

4 | 5 | Open source framework for easy data synchronization between business applications. 6 | 7 | Visit the official [Open Integration Hub homepage](https://www.openintegrationhub.org/) 8 | 9 | ## Introduction 10 | 11 | [![License](https://img.shields.io/badge/License-Apache%202.0-yellow.svg)](LICENSE) 12 | 13 | The Open Integration Hub enables data synchronization across a variety of applications. This requires unified data structures — the master data models of the Open Integration Hub. These master data models can make your life easier, but are optional. You can always just do a 1:1 mapping or use your own data models. The models are developed and maintained by the community, so please do not hesitate to give feedback, suggest changes or propose new models. 14 | 15 | ## Join the Community 16 | 17 | Do you have questions, ideas, feedback or just want to chat about integration? Please join our growing developer community on [Slack](https://join.slack.com/t/openintegrationhub/shared_invite/zt-mba97vn9-xus3ZbVxnMr2oQwGegIk5Q)! 18 | 19 | ## Contribution 20 | 21 | ### Getting Started 22 | 23 | Within the scope of the master data models of the Open Integration Hub you can contribute in two different ways. You can either request/propose a change to an already existing model or contribute a new model for an currently not existing domain. 24 | 25 | #### Propose a Model Change 26 | 27 | An existing model can be change in different ways. The possibility exists to add or remove something from the model or to change an existing part, such as an attribute. 28 | 29 | If you want to propose a model change please open an issue here or against the [monopreo](https://github.com/openintegrationhub/openintegrationhub/issues). 30 | 31 | The unified process for changing a model is explained in the following: 32 | 33 | 1. Fill out the request for model change 34 | 2. Submit the proposal 35 | 3. The relating workgroup will check the proposal according to fix rules 36 | 4. If the proposal is approved the change will be incorporated into the model 37 | 5. A new model version will be published within the next release 38 | 39 | **Change Request Flow:** 40 | 41 | ![Change Request](MasterDataModels/Versioning/Assets/change_request.svg) 42 | 43 | **Realization of Request Sub-Task:** 44 | 45 | ![Realization of Request](MasterDataModels/Versioning/Assets/realization.svg) 46 | 47 | #### Contribute a new Model 48 | 49 | If you want to contribute a new model for a currently not yet existing domain, please consider the following steps: 50 | 51 | Before you start please read the [**Introduction into Open Integration Hub master data models**](MasterDataModels/README.md) and [**How to contribute a new data model**](CONTRIBUTING.md#contributing-a-new-data-model). 52 | 53 | ### Contribution Guidelines 54 | 55 | Before you contribute please read our [contribution guidelines](CONTRIBUTING.md). 56 | 57 | ### Code of Conduct 58 | 59 | To see how members of the community are expected to behave, please read the [code of conduct](CODE_OF_CONDUCT.md). We apply the code of conduct defined by the Contributor Covenant, which is used across many open source projects, such as [NodeJS](https://github.com/nodejs/node), [Atom](https://github.com/atom/atom) and [Kubernetes](https://github.com/kubernetes/kubernetes). 60 | 61 | ## Content 62 | 63 | ### Folders 64 | 65 | - [Decisions](Decisions): This folder contains all outstanding/made decisions by the workgroup categorized by open and closed decisions 66 | - [MasterDataModels](MasterDataModels): This folder contains general information about the data models, an explanation of the OIHDataRecord and all currently existing master data models 67 | - [Protocols](Protocols): Contains meeting protocols of the workgroup meetings 68 | - [src](src): All JSON schemes can be found here. This includes JSON schemes for all existing master data models, the overarching OIHDataRecord and a generic example as a starting point for writing JSON schemes for the relating data model 69 | 70 | ### Documents 71 | 72 | - [CONTRIBUTING](CONTRIBUTING.md): Gathers any rule considering the contribution for the Open Integration Hub project 73 | - [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md): Contains an explanation of the expected behavior of the community members, following the code of conduct defined by the Contributor Covenant 74 | -------------------------------------------------------------------------------- /src/examples/schema/order.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "http://openintegrationhub.org/examples/schemas/order.json", 4 | "title": "Order", 5 | "properties": { 6 | "orderNumber": { 7 | "type": "string" 8 | }, 9 | "customerNumber": { 10 | "type": "integer" 11 | }, 12 | "shippingAddressUid": { 13 | "type": "integer" 14 | }, 15 | "billingAddressUid": { 16 | "type": "integer" 17 | }, 18 | "date": { 19 | "type": "string", 20 | "format": "date-time" 21 | }, 22 | "lineItems": { 23 | "type": "array", 24 | "items": { 25 | "type" : "object", 26 | "properties" : { 27 | "position" : { "type" : "integer", "minimum" : 1 }, 28 | "articleUid" : { "type" : "string" }, 29 | "description" : { "type" : "string" }, 30 | "quantity" : { "type" : "number" }, 31 | "cost" : { "type" : "number" }, 32 | "amount" : { "type" : "number" } 33 | }, 34 | "required" : [ "position", "description", "amount" ] 35 | }, 36 | "minItems": 1 37 | }, 38 | "total": { 39 | "type": "number" 40 | }, 41 | "creditCardPaymentInfo": { 42 | "type": "object", 43 | "properties": { 44 | "cardNumber": { 45 | "type": "integer" 46 | }, 47 | "expirationMonth": { 48 | "type": "integer", 49 | "minimum": 1, 50 | "maximum": 12 51 | }, 52 | "expirationYear": { 53 | "type": "integer" 54 | }, 55 | "cardHolder": { 56 | "type": "string" 57 | } 58 | }, 59 | "required": [ 60 | "cardNumber", 61 | "expirationMonth", 62 | "expirationYear", 63 | "cardHolder" 64 | ] 65 | } 66 | }, 67 | "required": [ 68 | "orderNumber", 69 | "customerNumber", 70 | "date", 71 | "lineItems", 72 | "total" 73 | ] 74 | } -------------------------------------------------------------------------------- /src/main/schema/addresses/V1/organization.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/draft-04/schema#", 3 | "$id": "http://openintegrationhub.org/schemas/addresses/organization.json", 4 | "title": "Organization", 5 | "description": "Master Data Model for Addresses to use in the Open Integration Hub", 6 | "allOf": [ 7 | { 8 | "$ref": "../../oih-data-record.json" 9 | } 10 | ], 11 | "properties": { 12 | "organizationName": { "type": "string" }, 13 | "categories": { 14 | "type": "array", 15 | "items": { 16 | "$ref": "shared-definitions.json#definitions/Category" 17 | } 18 | }, 19 | "addresses": { 20 | "type": "array", 21 | "items": { 22 | "$ref": "shared-definitions.json#definitions/Address" 23 | } 24 | }, 25 | "phoneNumbers": { 26 | "type": "array", 27 | "items": { 28 | "$ref": "shared-definitions.json#definitions/Phone" 29 | } 30 | }, 31 | "faxNumbers": { 32 | "type": "array", 33 | "items": { 34 | "$ref": "shared-definitions.json#definitions/Fax" 35 | } 36 | }, 37 | "eMailAddresses": { 38 | "type": "array", 39 | "items": { 40 | "$ref": "shared-definitions.json#definitions/EMail" 41 | } 42 | }, 43 | "socials": { 44 | "type": "array", 45 | "items": { 46 | "$ref": "shared-definitions.json#definitions/Social" 47 | } 48 | }, 49 | "urls": { 50 | "type": "array", 51 | "items": { 52 | "$ref": "shared-definitions.json#definitions/Url" 53 | } 54 | } 55 | }, 56 | "required": ["organizationName"] 57 | } 58 | -------------------------------------------------------------------------------- /src/main/schema/addresses/V1/person.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/draft-04/schema#", 3 | "$id": "http://openintegrationhub.org/schemas/addresses/person.json", 4 | "title": "Person", 5 | "description": "Master Data Model for Addresses to use in the Open Integration Hub", 6 | "allOf": [ 7 | { 8 | "$ref": "../..//oih-data-record.json" 9 | } 10 | ], 11 | "properties": { 12 | "title": { "type": "string" }, 13 | "salutation": { "type": "string" }, 14 | "firstName": { "type": "string" }, 15 | "middleName": { "type": "string" }, 16 | "lastName": { "type": "string" }, 17 | "gender": { "type": "string" }, 18 | "birthday": { "type": "string" }, 19 | "categories": { 20 | "type": "array", 21 | "items": { 22 | "$ref": "shared-definitions.json#definitions/Category" 23 | } 24 | }, 25 | "addresses": { 26 | "type": "array", 27 | "items": { 28 | "$ref": "shared-definitions.json#definitions/Address" 29 | } 30 | }, 31 | "phoneNumbers": { 32 | "type": "array", 33 | "items": { 34 | "$ref": "shared-definitions.json#definitions/Phone" 35 | } 36 | }, 37 | "faxNumbers": { 38 | "type": "array", 39 | "items": { 40 | "$ref": "definitions.json#definitions/Fax" 41 | } 42 | }, 43 | "eMailAddresses": { 44 | "type": "array", 45 | "items": { 46 | "$ref": "shared-definitions.json#definitions/EMail" 47 | } 48 | }, 49 | "socials": { 50 | "type": "array", 51 | "items": { 52 | "$ref": "shared-definitions.json#definitions/Social" 53 | } 54 | }, 55 | "urls": { 56 | "type": "array", 57 | "items": { 58 | "$ref": "shared-definitions.json#definitions/Url" 59 | } 60 | } 61 | }, 62 | "anyOf": [ 63 | { "required": ["firstName"] }, 64 | { "required": ["lastName"] } 65 | ] 66 | } 67 | -------------------------------------------------------------------------------- /src/main/schema/addresses/V1/relation.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/draft-04/schema#", 3 | "$id": "http://openintegrationhub.org/schemas/addresses/relation.json", 4 | "title": "Relation", 5 | "description": "Master Data Model for Addresses to use in the Open Integration Hub", 6 | "allOf": [ 7 | { 8 | "$ref": "../../oih-data-record.json" 9 | } 10 | ], 11 | "oneOf": [ 12 | { "$ref": "#/definitions/OrganizationToOrganizationRelation"}, 13 | { "$ref": "#/definitions/OrganizationToPersonRelation"}, 14 | { "$ref": "#/definitions/PersonToPersonRelation"} 15 | ], 16 | "properties": { 17 | "label": { "type": "string" }, 18 | "labelType": { "type": "string" } 19 | }, 20 | "definitions": { 21 | "Organization": { 22 | "$ref": "organization.json" 23 | }, 24 | "Person": { 25 | "$ref": "person.json" 26 | }, 27 | "OrganizationToOrganizationRelation": { 28 | "properties": { 29 | "firstOrganization" : { 30 | "$ref": "#/definitions/Organization" 31 | }, 32 | "secondOrganization" : { 33 | "$ref": "#/definitions/Organization" 34 | } 35 | }, 36 | "required": ["firstOrganization", "secondOrganization"] 37 | }, 38 | "OrganizationToPersonRelation": { 39 | "properties": { 40 | "organization" : { 41 | "$ref": "#/definitions/Organization" 42 | }, 43 | "person" : { 44 | "$ref": "#/definitions/Person" 45 | } 46 | }, 47 | "required": ["organization", "person"] 48 | }, 49 | "PersonToPersonRelation": { 50 | "properties": { 51 | "firstPerson" : { 52 | "$ref": "#/definitions/Person" 53 | }, 54 | "secondPerson" : { 55 | "$ref": "#/definitions/Person" 56 | } 57 | }, 58 | "required": ["firstPerson", "secondPerson"] 59 | } 60 | } 61 | } 62 | -------------------------------------------------------------------------------- /src/main/schema/addresses/V1/shared-definitions.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/draft-04/schema#", 3 | "$id": "http://openintegrationhub.org/schemas/addresses/shared-definitions.json", 4 | "title": "SharedDefinitions", 5 | "description": "Shared Definitions for the Master Data Model for Addresses to use in the Open Integration Hub", 6 | 7 | "definitions": { 8 | "Address": { 9 | "type": "object", 10 | "properties": { 11 | "street": { 12 | "type": "string" 13 | }, 14 | "streetNumber": { 15 | "type": "string" 16 | }, 17 | "unit": { 18 | "type": "string" 19 | }, 20 | "zipCode": { 21 | "type": "string" 22 | }, 23 | "town": { 24 | "type": "string" 25 | }, 26 | "district": { 27 | "type": "string" 28 | }, 29 | "region": { 30 | "type": "string" 31 | }, 32 | "country": { 33 | "type": "string" 34 | } 35 | } 36 | }, 37 | "Phone": { 38 | "type": "object", 39 | "properties": { 40 | "phoneNumber": { 41 | "type": "string" 42 | } 43 | } 44 | }, 45 | "Fax": { 46 | "type": "object", 47 | "properties": { 48 | "faxNumber": { 49 | "type": "string" 50 | } 51 | } 52 | }, 53 | "EMail": { 54 | "type": "object", 55 | "properties": { 56 | "eMail": { 57 | "type": "string" 58 | } 59 | } 60 | }, 61 | "Social": { 62 | "type": "object", 63 | "properties": { 64 | "network": { 65 | "type": "string", 66 | "description": "Provision name of social network" 67 | }, 68 | "id": { 69 | "type": "string", 70 | "description": "Provision social network ID or username" 71 | } 72 | }, 73 | "Url": { 74 | "type": "object", 75 | "properties": { 76 | "url": { 77 | "type": "uri" 78 | } 79 | } 80 | }, 81 | "Category": { 82 | "type": "object", 83 | "properties": { 84 | "categoryName": { 85 | "type": "string" 86 | } 87 | } 88 | } 89 | } 90 | } 91 | } 92 | -------------------------------------------------------------------------------- /src/main/schema/addresses/organizationV2.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/organizationV2.json", 4 | "title": "Organization", 5 | "type": "object", 6 | "allOf": [ 7 | { 8 | "$ref": "../oih-data-record.json" 9 | } 10 | ], 11 | "properties": { 12 | "name": { 13 | "type": "string", 14 | "description": "Name of the organization", 15 | "example": "Great Company" 16 | }, 17 | "logo": { 18 | "type": "string", 19 | "description": "Logo of the organization", 20 | "example": "http://example.org/logo.png" 21 | }, 22 | "addresses": { 23 | "type": "array", 24 | "items": { 25 | "$ref": "sharedDefinitionsV2.json#/definitions/Address" 26 | } 27 | }, 28 | "contactData": { 29 | "type": "array", 30 | "items": { 31 | "$ref": "sharedDefinitionsV2.json#/definitions/contactData" 32 | } 33 | }, 34 | "categories": { 35 | "type": "array", 36 | "items": { 37 | "$ref": "sharedDefinitionsV2.json#/definitions/category" 38 | } 39 | }, 40 | "calendars": { 41 | "type": "array", 42 | "items": { 43 | "$ref": "sharedDefinitionsV2.json#/definitions/calendar" 44 | } 45 | } 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /src/main/schema/addresses/personV2.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/personV2.json", 4 | "title": "Person", 5 | "description": "Describes a natural person", 6 | "type": "object", 7 | "allOf": [ 8 | { 9 | "$ref": "../oih-data-record.json" 10 | } 11 | ], 12 | "properties": { 13 | "title": 14 | { 15 | "type": "string", 16 | "description": "Title of the person", 17 | "examples": [ 18 | "Dr." 19 | ] 20 | }, 21 | "salutation": 22 | { 23 | "type": "string", 24 | "description": "Salutation of the person", 25 | "examples": [ 26 | "Mr." 27 | ] 28 | }, 29 | "firstName": 30 | { 31 | "type": "string", 32 | "description": "Given name of the person", 33 | "examples": [ 34 | "Max" 35 | ] 36 | }, 37 | "middleName": 38 | { 39 | "type": "string", 40 | "description": "Middle name of the person", 41 | "examples": [ 42 | "Schneider" 43 | ] 44 | }, 45 | "lastName": 46 | { 47 | "type": "string", 48 | "description": "Surname of the person", 49 | "examples": [ 50 | "Schneider" 51 | ] 52 | }, 53 | "gender": 54 | { 55 | "type": "string", 56 | "enum": ["male", "female", "intersexual",""], 57 | "description": "Gender of the person" 58 | }, 59 | "birthday": 60 | { 61 | "type": "string", 62 | "description": "Birthday of the person" 63 | }, 64 | "notes": 65 | { 66 | "type": "string", 67 | "description": "Individual notes for the person" 68 | }, 69 | "displayName": 70 | { 71 | "type": "string", 72 | "description": "Displayed name for the person within the application", 73 | "examples": [ 74 | "mscheinder", 75 | "heNiha" 76 | ] 77 | }, 78 | "language": 79 | { 80 | "type": "string", 81 | "description": "First language of the person" 82 | }, 83 | "nickname": 84 | { 85 | "type": "string", 86 | "description": "Nickname of the person", 87 | "examples": [ 88 | "maxschn", 89 | "silSchaef" 90 | ] 91 | }, 92 | "jobTitle": { 93 | "type": "string", 94 | "description": "Job title of the person", 95 | "examples": [ 96 | "Sales manager", 97 | "Software architect" 98 | ] 99 | }, 100 | "photo": 101 | { 102 | "type": "string", 103 | "description": "Photo related to the person", 104 | "examples": [ 105 | "http://example.org/photo.jpg" 106 | ] 107 | }, 108 | "anniversary": 109 | { 110 | "type": "string", 111 | "description": "Anniversary of the person" 112 | }, 113 | "addresses": 114 | { 115 | "type": "array", 116 | "description": "Addess data of of the person", 117 | "items": { 118 | "$ref": "sharedDefinitionsV2.json#/definitions/Address" 119 | } 120 | }, 121 | "contactData": { 122 | "type": "array", 123 | "items": { 124 | "$ref": "sharedDefinitionsV2.json#/definitions/contactData" 125 | } 126 | }, 127 | "calendars": { 128 | "type": "array", 129 | "items": { 130 | "$ref": "sharedDefinitionsV2.json#/definitions/calendar" 131 | } 132 | }, 133 | "categories": { 134 | "type": "array", 135 | "items": { 136 | "$ref": "sharedDefinitionsV2.json#/definitions/category" 137 | } 138 | } 139 | } 140 | } 141 | -------------------------------------------------------------------------------- /src/main/schema/addresses/relationsV2.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/relationsV2.json", 4 | "title": "Relationship", 5 | "description": "Describes the relationship between a person and an organization", 6 | "type": "object", 7 | "allOf": [ 8 | { 9 | "$ref": "https://raw.githubusercontent.com/philecs/philecs/master/oih-data-record.json" 10 | } 11 | ], 12 | "anyOf": [ 13 | { 14 | "$ref": "#/definitions/OrganizationToPersonRelationship" 15 | }, 16 | { 17 | "$ref": "#/definitions/PersonToPersonRelationship" 18 | }, 19 | { 20 | "$ref": "#/definitions/OrganizationToOrganizationRelationship" 21 | } 22 | ], 23 | "definitions":{ 24 | "OrganizationToPersonRelationship":{ 25 | "type": "object", 26 | "description": "Describes the relationship between a person and an organization", 27 | "properties": { 28 | "organizationOihUId": { 29 | "type": "string", 30 | "description": "Unique identifier of the organization" 31 | }, 32 | "personOihUId": { 33 | "type": "string", 34 | "description": "Unique identifier of the person" 35 | }, 36 | "function": { 37 | "type": "string", 38 | "description": "Function of the person within the organization", 39 | "examples": [ 40 | "Software architect" 41 | ] 42 | }, 43 | "department": { 44 | "type": "string", 45 | "description": "Department the person works at", 46 | "examples": [ 47 | "sales" 48 | ] 49 | } 50 | } 51 | }, 52 | "PersonToPersonRelationship": { 53 | "type": "object", 54 | "description": "Describes the relationship between two persons", 55 | "properties": { 56 | "personOneOihUId": { 57 | "type": "string", 58 | "description": "Unique identifier of the first person" 59 | }, 60 | "personTwoOihUId2": { 61 | "type": "string", 62 | "description": "Unique identifier of the second person" 63 | } 64 | } 65 | }, 66 | "OrganizationToOrganizationRelationship": { 67 | "type": "object", 68 | "description": "Describes the relationship between two organizations", 69 | "properties": { 70 | "organizationOneOihUId": { 71 | "type": "string", 72 | "description": "Unique identifier of the first organization" 73 | }, 74 | "organizationTwoOihUId2": { 75 | "type": "string", 76 | "description": "Unique identifier of the second organization" 77 | } 78 | } 79 | } 80 | }, 81 | "properties": { 82 | "label": { 83 | "type": "string", 84 | "description": "Describes the type of relationship", 85 | "examples": [ 86 | "employee", 87 | "same person", 88 | "colleague", 89 | "same organization" 90 | ] 91 | } 92 | } 93 | } 94 | -------------------------------------------------------------------------------- /src/main/schema/addresses/sharedDefinitionsV2.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/sharedDefinitionsV2.json", 4 | "title": "SharedDefinitions", 5 | "description": "Shared Definitions for the Master Data Model for Addresses to use in the Open Integration Hub", 6 | "definitions": { 7 | "Address": { 8 | "type": "object", 9 | "properties": { 10 | "street": { 11 | "type": "string", 12 | "description": "Street of the address", 13 | "examples": [ 14 | "Hohestr." 15 | ] 16 | }, 17 | "streetNumber": { 18 | "type": "number", 19 | "description": "Street numer of the address", 20 | "examples": [ 21 | "3" 22 | ] 23 | }, 24 | "unit": { 25 | "type": "string", 26 | "description": "", 27 | "examples": [ 28 | "a", 29 | "f" 30 | ] 31 | }, 32 | "zipCode": { 33 | "type": "string", 34 | "description": "Zipcode/postalcode of the address", 35 | "examples": [ 36 | "50667" 37 | ] 38 | }, 39 | "city": { 40 | "type": "string", 41 | "description": "City of the address", 42 | "examples": [ 43 | "Cologne" 44 | ] 45 | }, 46 | "district": { 47 | "type": "string", 48 | "description": "District of the address", 49 | "examples": [ 50 | "Alstadt-Sued" 51 | ] 52 | }, 53 | "region": { 54 | "type": "string", 55 | "description": "Region of the address", 56 | "examples": [ 57 | "NRW" 58 | ] 59 | }, 60 | "country": { 61 | "type": "string", 62 | "description": "Country of the address", 63 | "examples": [ 64 | "Germany" 65 | ] 66 | }, 67 | "countryCode": { 68 | "type": "string", 69 | "description": "Countrycode of the address' country", 70 | "examples": [ 71 | "DE" 72 | ] 73 | }, 74 | "primaryContact": { 75 | "type": "string", 76 | "description": "Name of the primary contact of the address", 77 | "examples": [ 78 | "Hermann Schmitz" 79 | ] 80 | }, 81 | "label":{ 82 | "type": "string", 83 | "description": "Can be used to label the address", 84 | "default": "primary", 85 | "examples": [ 86 | "primary", 87 | "secondary" 88 | ] 89 | } 90 | }, 91 | "additionalProperties": false 92 | }, 93 | "contactData": { 94 | "type": "object", 95 | "description": "Phone information", 96 | "properties": { 97 | "value": { 98 | "type": "string", 99 | "description": "Value of the contact data", 100 | "examples": [ 101 | "example@test.de", 102 | "0123456789" 103 | ] 104 | }, 105 | "type": { 106 | "type": "string", 107 | "description": "Type of the contact data", 108 | "examples": [ 109 | "phone", 110 | "email", 111 | "url", 112 | "fax", 113 | "social media" 114 | ] 115 | }, 116 | "label":{ 117 | "type": "string", 118 | "description": "Used to specify the contact data with a label", 119 | "default": "", 120 | "examples": [ 121 | "businessMobile", 122 | "support", 123 | "homepage", 124 | "privateFax", 125 | "linkedin" 126 | ] 127 | }, 128 | "description":{ 129 | "type": "string", 130 | "description": "Can be used for a categorization of same types of contact data or for additional information", 131 | "default": "primary", 132 | "examples": [ 133 | "primary", 134 | "secondary" 135 | ] 136 | } 137 | } 138 | }, 139 | "category": { 140 | "type": "object", 141 | "description": "Category of the person / organization", 142 | "properties": { 143 | "name": { 144 | "type": "string", 145 | "description": "Name of the category the person / organization belongs to", 146 | "examples": [ 147 | "customer", 148 | "supplier", 149 | "prospect" 150 | ] 151 | }, 152 | "label": { 153 | "type": "string", 154 | "description": "Used to label the category", 155 | "examples": [ 156 | "a customer" 157 | ] 158 | } 159 | } 160 | }, 161 | "calendar": { 162 | "type": "object", 163 | "description": "Phone information", 164 | "properties": { 165 | "calendar": { 166 | "type": "string", 167 | "description": "URI to the calendar of the person", 168 | "examples": [ 169 | "http://www.example.com/calA" 170 | ] 171 | }, 172 | "busyCalendar": { 173 | "type": "string", 174 | "description": "URI to get see when the person is available/blocked", 175 | "examples": [ 176 | "http://www.example.com/busy/janedoe" 177 | ] 178 | }, 179 | "requestCalendar": { 180 | "type": "string", 181 | "description": "URI to request an appointment with the person", 182 | "examples": [ 183 | "janedoe@example.com" 184 | ] 185 | }, 186 | "label":{ 187 | "type": "string", 188 | "description": "Used to label the calendar", 189 | "default": "primary", 190 | "examples": [ 191 | "primary", 192 | "secondary" 193 | ] 194 | } 195 | } 196 | } 197 | } 198 | } 199 | -------------------------------------------------------------------------------- /src/main/schema/collaboration/calendarEvent.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema":"http://json-schema.org/schema#", 3 | "$id":"https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/collaboration/calendarEvent.json", 4 | "title":"CalendarEvent", 5 | "description":"Describes the CalendarEvent", 6 | "type":"object", 7 | "allOf":[ 8 | { 9 | "$ref":"../oih-data-record.json" 10 | } 11 | ], 12 | "properties":{ 13 | "collaborationElement":{ 14 | "description":"CollaborationElement Data", 15 | "allOf": [ 16 | { 17 | "$ref":"collaborationElement.json" 18 | } 19 | ] 20 | }, 21 | "contacts":{ 22 | "type":"array", 23 | "description":"Contacts Data", 24 | "items":{ 25 | "$ref":"#/definitions/Contact" 26 | } 27 | }, 28 | "location":{ 29 | "type":"string", 30 | "description":"Name of the location", 31 | "examples":[ 32 | "Room 123" 33 | ] 34 | }, 35 | "start":{ 36 | "type":"string", 37 | "format":"date", 38 | "description":"startdate of the event", 39 | "examples":[ 40 | "2018-01-01" 41 | ] 42 | }, 43 | "end":{ 44 | "type":"string", 45 | "format":"date", 46 | "description":"enddate of the event", 47 | "examples":[ 48 | "2018-12-18" 49 | ] 50 | } 51 | }, 52 | "definitions":{ 53 | "Contact":{ 54 | "type":"object", 55 | "properties":{ 56 | "name":{ 57 | "type":"string", 58 | "description":"Name of the contact", 59 | "examples":[ 60 | "John Doe" 61 | ] 62 | }, 63 | "eMail":{ 64 | "type":"string", 65 | "description":"E-mail of the contact", 66 | "examples":[ 67 | "john.doe@email.com" 68 | ] 69 | }, 70 | "calendars":{ 71 | "type":"array", 72 | "description":"EventDetails Data", 73 | "items":{ 74 | "$ref":"#/definitions/calendar" 75 | } 76 | }, 77 | "calendars":{ 78 | "type":"object", 79 | "properties":{ 80 | "calendars":{ 81 | "type":"string", 82 | "description":"URI to the person's calendar", 83 | "examples":[ 84 | "http://cal.example.com/calA" 85 | ] 86 | }, 87 | "requestCalendar":{ 88 | "type":"string", 89 | "description":"URL to request an appointment with the person", 90 | "examples":[ 91 | "janedoe@example.com" 92 | ] 93 | }, 94 | "status":{ 95 | "type":"string", 96 | "description":"Identification of the thread", 97 | "examples":[ 98 | "http://www.example.com/busy/janedoe" 99 | ] 100 | } 101 | } 102 | } 103 | } 104 | } 105 | } 106 | } 107 | -------------------------------------------------------------------------------- /src/main/schema/collaboration/collaborationElement.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema":"http://json-schema.org/schema#", 3 | "$id":"https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/collaboration/collaborationElement.json", 4 | "title":"CollaborationElement", 5 | "description":"Describes the Collaboration Element", 6 | "type":"object", 7 | "properties": { 8 | "from":{ 9 | "type":"string", 10 | "description":"E-Mail of sender", 11 | "examples":[ 12 | "john.doe@email.com" 13 | ] 14 | }, 15 | "to":{ 16 | "type":"string", 17 | "description":"E-mail of receiver", 18 | "examples":[ 19 | "jane.doe@email.com" 20 | ] 21 | }, 22 | "cc":{ 23 | "type":"string", 24 | "description":"E-mail of the contact in copy", 25 | "examples":[ 26 | "janet.doe@email.com" 27 | ] 28 | }, 29 | "bcc":{ 30 | "type":"string", 31 | "description":"E-mail of the contact in blind copy", 32 | "examples":[ 33 | "jonathan.doe@email.com" 34 | ] 35 | }, 36 | "subject":{ 37 | "type":"string", 38 | "description":"Subject line of the e-mail", 39 | "examples":[ 40 | "RE: Your Question" 41 | ] 42 | }, 43 | "date":{ 44 | "type":"string", 45 | "format":"date", 46 | "description":"Date", 47 | "examples":[ 48 | "2018-01-01" 49 | ] 50 | }, 51 | "day":{ 52 | "type":"string", 53 | "description":"Day of the week", 54 | "examples":[ 55 | "Monday" 56 | ], 57 | "enum":[ 58 | "Monday", 59 | "Tuesday", 60 | "Wednesday", 61 | "Thursday", 62 | "Friday", 63 | "Saturday", 64 | "Sunday" 65 | ] 66 | }, 67 | "time":{ 68 | "type":"string", 69 | "format":"time", 70 | "description":"Timestamp", 71 | "examples":[ 72 | "10:10:10" 73 | ] 74 | }, 75 | "messageID":{ 76 | "type":"string", 77 | "description":"Unique ID of the E-Mail" 78 | }, 79 | "language":{ 80 | "type":"string", 81 | "description":"Language of the e-mail content", 82 | "examples":[ 83 | "en" 84 | ] 85 | }, 86 | "authentication":{ 87 | "type":"string", 88 | "description":"Authentication Result", 89 | "examples":[ 90 | "spf=pass smtp.mailfrom=email.com" 91 | ] 92 | }, 93 | "mimeVersion":{ 94 | "type":"number", 95 | "description":"Version of MIME", 96 | "examples":[ 97 | 1.3 98 | ] 99 | }, 100 | "format":{ 101 | "type":"string", 102 | "description":"Format of the email content", 103 | "examples":[ 104 | "HTML" 105 | ] 106 | }, 107 | "content":{ 108 | "type":"string", 109 | "description":"Content of the e-mail", 110 | "examples":[ 111 | "Dear John, please find attached" 112 | ] 113 | }, 114 | "attachments":{ 115 | "type":"array", 116 | "description":"attachment information of the element", 117 | "items":{ 118 | "$ref":"#/definitions/Attachment" 119 | } 120 | } 121 | }, 122 | "definitions":{ 123 | "Attachment":{ 124 | "type":"object", 125 | "properties":{ 126 | "type":{ 127 | "type":"string", 128 | "description":"Datatype of the attachment", 129 | "examples":[ 130 | "JPG" 131 | ] 132 | }, 133 | "size":{ 134 | "type":"string", 135 | "description":"Datasize of the e-mail attachment", 136 | "examples":[ 137 | "54 KB" 138 | ] 139 | } 140 | } 141 | } 142 | } 143 | } 144 | -------------------------------------------------------------------------------- /src/main/schema/collaboration/email.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema":"http://json-schema.org/schema#", 3 | "$id":"https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/collaboration/email.json", 4 | "title":"EMail", 5 | "description":"Describes the EMail", 6 | "type":"object", 7 | "allOf":[ 8 | { 9 | "$ref":"../oih-data-record.json" 10 | } 11 | ], 12 | "properties":{ 13 | "collaborationElement":{ 14 | "description":"CollaborationElement Data", 15 | "allOf":[ 16 | { 17 | "$ref":"collaborationElement.json" 18 | } 19 | ] 20 | }, 21 | "threads":{ 22 | "type":"array", 23 | "description":"thread information of the e-mail", 24 | "items":{ 25 | "$ref":"#/definitions/Thread" 26 | } 27 | } 28 | }, 29 | "definitions":{ 30 | "Thread":{ 31 | "type":"object", 32 | "properties":{ 33 | "threadName":{ 34 | "type":"string", 35 | "description":"Name of the Thread", 36 | "examples":[ 37 | "Subject of the E-Mail" 38 | ] 39 | }, 40 | "topic":{ 41 | "type":"string", 42 | "description":"Identification of the thread" 43 | } 44 | } 45 | } 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /src/main/schema/collaboration/task.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema":"http://json-schema.org/schema#", 3 | "$id":"https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/collaboration/task.json", 4 | "title":"Task", 5 | "description":"Describes the Task", 6 | "type":"object", 7 | "allOf":[ 8 | { 9 | "$ref":"../oih-data-record.json" 10 | } 11 | ], 12 | "properties":{ 13 | "collaborationElement":{ 14 | "description":"CollaborationElement Data", 15 | "allOf":[ 16 | { 17 | "$ref":"collaborationElement.json" 18 | } 19 | ] 20 | }, 21 | "subject":{ 22 | "type":"string", 23 | "description":"Subject of the Task", 24 | "examples":[ 25 | "Subject of the task" 26 | ] 27 | }, 28 | "startdate":{ 29 | "type":"string", 30 | "format":"date-time", 31 | "description":"Date when the task starts", 32 | "examples":[ 33 | "2018-01-01T10:10:10Z" 34 | ] 35 | }, 36 | "enddate":{ 37 | "type":"string", 38 | "format":"date-time", 39 | "description":"Date when the task is closed", 40 | "examples":[ 41 | "2018-03-01T10:10:10Z" 42 | ] 43 | }, 44 | "reminderdate":{ 45 | "type":"string", 46 | "format":"date-time", 47 | "description":"Date when the task completion should be reminded", 48 | "examples":[ 49 | "2018-02-01T10:10:10Z" 50 | ] 51 | }, 52 | "content":{ 53 | "type":"string", 54 | "description":"description of the Task", 55 | "examples":[ 56 | "To create a datamodel we have to analyze different systems..." 57 | ] 58 | }, 59 | "status":{ 60 | "type":"string", 61 | "description":"status of the Task", 62 | "enum":[ 63 | "started", 64 | "in progress", 65 | "completed" 66 | ], 67 | "examples":[ 68 | "completed" 69 | ] 70 | }, 71 | "urgency":{ 72 | "type":"string", 73 | "description":"urgency of the Task", 74 | "examples":[ 75 | "very high", 76 | "high", 77 | "medium", 78 | "low" 79 | ] 80 | }, 81 | "categories":{ 82 | "type":"array", 83 | "items":{ 84 | "$ref":"#/definitions/Category" 85 | } 86 | } 87 | }, 88 | "definitions":{ 89 | "Category":{ 90 | "type":"object", 91 | "properties":{ 92 | "type":{ 93 | "type":"string", 94 | "description":"category of the task or subtask", 95 | "examples":[ 96 | "Implementation" 97 | ] 98 | } 99 | } 100 | } 101 | } 102 | } 103 | -------------------------------------------------------------------------------- /src/main/schema/collaboration/taskToTaskRelation.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema":"http://json-schema.org/schema#", 3 | "$id":"https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/collaboration/taskToTaskRelation.json", 4 | "title":"taskToTaskRelation", 5 | "description":"Describes the relation between two tasks", 6 | "type":"object", 7 | "allOf":[ 8 | { 9 | "$ref":"../oih-data-record.json" 10 | } 11 | ], 12 | "properties":{ 13 | "sourceTaskUiid": { 14 | "type": "string", 15 | "description": "Unique identifier of the organization" 16 | }, 17 | "targetTaskUiid": { 18 | "type": "string", 19 | "description": "Unique identifier of the person" 20 | }, 21 | "label":{ 22 | "type": "string", 23 | "description": "Describes the relation between source task and target task", 24 | "examples":[ 25 | "isSubtask", 26 | "isBlockedBy", 27 | "isBlocking" 28 | ] 29 | } 30 | } 31 | } 32 | -------------------------------------------------------------------------------- /src/main/schema/documents/extended/Document.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/documents/extended/Document.json", 4 | "title": "Folder", 5 | "type": "object", 6 | "allOf": [{ 7 | "$ref": "Object.json" 8 | }], 9 | "properties": { 10 | "currentVersion": { 11 | "$ref": "sharedDefinitions.json#/definitions/Version" 12 | } 13 | }, 14 | "subResources": { 15 | "type": "array", 16 | "items": { 17 | "$ref": "sharedDefinitions.json#/definitions/SubResource" 18 | } 19 | } 20 | } 21 | -------------------------------------------------------------------------------- /src/main/schema/documents/extended/Folder.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/documents/extended/Folder.json", 4 | "title": "Folder", 5 | "type": "object", 6 | "allOf": [{ 7 | "$ref": "Object.json" 8 | }], 9 | "properties": {} 10 | } 11 | -------------------------------------------------------------------------------- /src/main/schema/documents/extended/Object.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/documents/extended/Object.json", 4 | "title": "Object", 5 | "description": "Objects describe base properties that are used by documents, folders or additional implementations.", 6 | "type": "object", 7 | "allOf": [{ 8 | "$ref": "../../oih-data-record.json" 9 | }], 10 | "properties": { 11 | "label": { 12 | "type": "string", 13 | "description": "Name of the object", 14 | "examples": ["Invoice #2018061023"] 15 | }, 16 | "description": { 17 | "type": "string", 18 | "description": "Additional information describing the object", 19 | "examples": ["Invoice was sent on March 28th"] 20 | }, 21 | "baseType": { 22 | "type": "string", 23 | "enum": ["document", "folder"], 24 | "description": "Base type of the object", 25 | "examples": ["document"] 26 | }, 27 | "parentUid": { 28 | "type": "string", 29 | "description": "Id of the parent element if hierarchically organized", 30 | "examples": ["291ecb5e-cd8f-46fd-ae0d-40b5e280f23a"] 31 | }, 32 | "path": { 33 | "type": "string", 34 | "description": "Path from root to the objects parent", 35 | "examples": ["/Invoices/Company Corp./2018/"] 36 | }, 37 | "metadata": { 38 | "type": "object", 39 | "description": "Map that contains all metadata as specified by: specification of generic metadata." 40 | }, 41 | "policies": { 42 | "type": "array", 43 | "items": { 44 | "$ref": "sharedDefinitions.json#/definitions/Policy" 45 | } 46 | } 47 | } 48 | } 49 | -------------------------------------------------------------------------------- /src/main/schema/documents/extended/Relation.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/documents/extended/Relation.json", 4 | "title": "Object", 5 | "description": "Relation between two objects in the system.", 6 | "type": "object", 7 | "allOf": [{ 8 | "$ref": "../../oih-data-record.json" 9 | }], 10 | "properties": { 11 | "label": { 12 | "type": "string", 13 | "description": "Name of the relation", 14 | "examples": ["Relates to"] 15 | }, 16 | "type": { 17 | "type": "string", 18 | "enum": ["link", "reference"], 19 | "description": "Type of the relation", 20 | "examples": ["link" ] 21 | }, 22 | "targetUid": { 23 | "type": "string", 24 | "description": "target object", 25 | "examples": ["9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 26 | }, 27 | "sourceUid": { 28 | "type": "string", 29 | "description": "source object", 30 | "examples": ["9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 31 | } 32 | } 33 | } 34 | -------------------------------------------------------------------------------- /src/main/schema/documents/extended/sharedDefinitions.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/documents/extended/sharedDefinitions.json", 4 | "title": "SharedDefinitions", 5 | "description": "Shared Definitions for the Master Data Model for Documents to use in the Open Integration Hub", 6 | "definitions": { 7 | "Version": { 8 | "type": "object", 9 | "properties": { 10 | "label": { 11 | "type": "string", 12 | "description": "Label of the document version. Most likely used for version numbering.", 13 | "examples": ["1.0.1"] 14 | }, 15 | "comment": { 16 | "type": "string", 17 | "description": "Version comment by the author", 18 | "examples": ["Rescanned document due to bad quality"] 19 | }, 20 | "creation": { 21 | "$ref": "../../oih-data-record.json#/definitions/Modification", 22 | "description": "Timestamp and user that created the document version" 23 | }, 24 | "isLatestVersion": { 25 | "type": "boolean", 26 | "description": "Flag that indicates if this is the latest version of the document", 27 | "examples": [true] 28 | }, 29 | "isMajorVersion": { 30 | "type": "boolean", 31 | "description": "Flag that indicates if this is a major version of the document", 32 | "examples": [false] 33 | }, 34 | "size": { 35 | "type": ["integer"], 36 | "description": "Filesize of the document version in bytes", 37 | "examples": [2097152] 38 | }, 39 | "mimeType": { 40 | "type": "string", 41 | "description": "Mimetype of the file content. refer to http://www.iana.org/assignments/media-types/media-types.xhtml", 42 | "examples": ["image/png"] 43 | }, 44 | "url": { 45 | "type": "string", 46 | "description": "Download url for the document version.", 47 | "examples": ["http://myservice.com/api/document/get/9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 48 | }, 49 | "uid": { 50 | "type": "string", 51 | "description": "Id of the document version", 52 | "examples": ["9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 53 | }, 54 | "type": { 55 | "type": "string", 56 | "enum": ["image", "mail", "word", "audio", "video"], 57 | "description": "Type of the document version.", 58 | "examples": ["image"] 59 | }, 60 | "extension": { 61 | "type": "string", 62 | "description": "Type of the documents extension.", 63 | "examples": ["png"] 64 | }, 65 | "properties": { 66 | "type": "array", 67 | "items": { 68 | "$ref": "#/definitions/DocumentProperty" 69 | } 70 | }, 71 | "subResources": { 72 | "type": "array", 73 | "items": { 74 | "$ref": "#/definitions/SubResource" 75 | } 76 | } 77 | } 78 | }, 79 | "Policy": { 80 | "type": "object", 81 | "description": "Policies can describe how objects are handled by the system. Invoices, for example, must be stored in a tamper-proof environment in order to comply with local law. Therefore policies can be used to define retention or deletion policies.", 82 | "properties": { 83 | "type": { 84 | "type": "string", 85 | "enum": ["retention", "deletion", "backup", "encryption", "storage"], 86 | "description": "Type of the policy", 87 | "examples": ["retention"] 88 | }, 89 | "value": { 90 | "type": "string", 91 | "description": "Description of the policy" 92 | }, 93 | "uid": { 94 | "type": "string", 95 | "description": "Id of the policy", 96 | "examples": ["291ecb5e-cd8f-46fd-ae0d-40b5e280f23a"] 97 | } 98 | } 99 | }, 100 | "DocumentProperty": { 101 | "type": "object", 102 | "description": "Document properties can describe additional information depending on the documents type. e.g. Systems that allow processing images can add the image size (width/height) in pixels.", 103 | "properties": { 104 | "type": { 105 | "type": "string", 106 | "description": "Type or identifier of the property", 107 | "examples": ["width"] 108 | }, 109 | "value": { 110 | "type": ["string", "integer"], 111 | "description": "value of the property", 112 | "examples": [1920] 113 | } 114 | } 115 | }, 116 | "SubResource": { 117 | "type": "object", 118 | "description": "Sub resources can be used in order to provide additional information. DMS/ECM/EIM systems usually provide additional functionality like extracting fulltext content or generating preview images of the document.", 119 | "properties": { 120 | "type": { 121 | "type": "string", 122 | "enum": ["rendition", "marker", "fulltext", "attachment"], 123 | "description": "Type of the sub resource", 124 | "examples": ["rendition"] 125 | }, 126 | "info": { 127 | "type": "string", 128 | "description": "Additional information or description of the subresource", 129 | "examples": ["small"] 130 | }, 131 | "size": { 132 | "type": ["integer"], 133 | "description": "Filesize of the document version in bytes", 134 | "examples": [2097152] 135 | }, 136 | "mimeType": { 137 | "type": "string", 138 | "description": "Mimetype of the sub resource content. refer to http://www.iana.org/assignments/media-types/media-types.xhtml", 139 | "examples": ["image/png"] 140 | }, 141 | "url": { 142 | "type": "string", 143 | "description": "Download url for the sub resource", 144 | "examples": ["http://myservice.com/api/document/subresource/get/9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 145 | }, 146 | "uid": { 147 | "type": "string", 148 | "description": "Id of the sub resource", 149 | "examples": ["9bd1f8dd-5040-4b19-bbc9-c5cbb9c8d4b8"] 150 | } 151 | } 152 | } 153 | } 154 | } 155 | -------------------------------------------------------------------------------- /src/main/schema/oih-data-record.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/schema#", 3 | "$id": "https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/oih-data-record.json", 4 | "title": "OIHDataRecord", 5 | "type": "object", 6 | "properties": { 7 | "oihUid": { 8 | "type": "string", 9 | "description": "Uniquely identifies a record within a OIH instance. This identifier is provided by the respective OIH instance, or, at least, the OIH defines how the identifier is assigned (e.g. a random UUID given by a connector. TDB!)." 10 | }, 11 | "oihCreated": { 12 | "$ref": "#/definitions/Modification" 13 | }, 14 | "oihLastModified": { 15 | "$ref": "#/definitions/Modification" 16 | }, 17 | "modificationHistory": { 18 | "type": "array", 19 | "items": { 20 | "$ref": "#/definitions/Modification" 21 | } 22 | }, 23 | "oihApplicationRecords": { 24 | "type": "array", 25 | "items": { 26 | "$ref": "#/definitions/ApplicationDataRecord" 27 | }, 28 | "description": "Each application record maps the OIH data record to a corresponding record in an application or service which is integrated via the OIH.", 29 | "minItems": 1 30 | } 31 | }, 32 | "required": [ 33 | "oihApplicationRecords" 34 | ], 35 | "definitions": { 36 | "ApplicationDataRecord": { 37 | "type": "object", 38 | "description": "An application data record identifies the corresponding record of an OIH data record within an application or service which os connected to an OIH instance", 39 | "properties": { 40 | "applicationUid": { 41 | "type": "string", 42 | "description": "Identifies the application or service the record belongs to within the OIH." 43 | }, 44 | "recordUid": { 45 | "type": "string", 46 | "description": "The record's UID within the respective application." 47 | }, 48 | "created": { 49 | "$ref": "#/definitions/Modification" 50 | }, 51 | "lastModified": { 52 | "$ref": "#/definitions/Modification" 53 | }, 54 | "modificationHistory": { 55 | "type": "array", 56 | "items": { 57 | "$ref": "#/definitions/Modification" 58 | } 59 | } 60 | }, 61 | "required": [ 62 | "applicationUid", 63 | "recordUid" 64 | ] 65 | }, 66 | "Modification": { 67 | "type": "object", 68 | "description": "Object for tracking modifications", 69 | "properties": { 70 | "userId": { 71 | "type": "string", 72 | "description": "unique identifier of the modifier" 73 | }, 74 | "type": { 75 | "type": "string", 76 | "description": "type of modification", 77 | "examples":[ 78 | "modification", 79 | "locked" 80 | ] 81 | }, 82 | "timestamp": { 83 | "type": "string", 84 | "format": "date-time", 85 | "description": "Date-Time of the modification" 86 | } 87 | } 88 | } 89 | } 90 | } 91 | -------------------------------------------------------------------------------- /src/xml/DataRecordOrderExample.xml: -------------------------------------------------------------------------------- 1 | U2FsdGVkX18KFaqNNvL9bI2SLgSn69qKAb1zEgs+XaIPLXxVhN7PM2ag14iUXQO8d9cV4a7JZEV6UX4V0j99b+NUtWPuz8KAPPONX5a7gNC5YZtRxBQSLi90V0XAkqOuHQ+TBZxOwetgAUG+9SuagAOKEtCyOMY2zccSBZGJ3VV1ydvfH4o1YFt8QSd6rW5XM3eYXuYve/qvQtY+lHRnf92Vwf73RrF0L70JYQkx9LITOHE6xxZo2Y5daoNOQvsDwJDd6i6R25YiGxvOxscsLO8IhuPnFbypeVYHXv7xFaKuV7sXjMd/lfEXZKC9uhfeX4vT39TTt6AIX7I5ptl5YTQCMwPuREo/7zeeC4aLWjz0wwZ+6zXV56MvmRHRh7/TTxzQC2AEduCvPoT6U8yfiyqsFFk507deJ+lKK7hVMpkq7kA9QTJcsz+JlyLOm+SYNprMh1ao7rcOFfQnvanRLZCfH2lFHpvg/VRp+kL70rkS+iVD8JHGrFkae7QhD1zAH63opCxaIyjzHouO8LVNseg+BU25utdZpKuVHiWn3k6lvO82sy8WYrey3cNXrei78MktZthuz3W2yBz1FqdWqctDpb0RaWL4mYXMZGKsz7ypGaTGfu89Pf1bjuDkUi+JIOteCWDzNSJWczJM6dv9gqMGGZK2QyIEFxr7e9I4O9/GYwt0jwbmKNqOdHhFRhOprfzs2JGHDd4p+ZRktNwj3rXfGG65sjQXuF0B6WsYqzb2Wq4RLSgZzUAJvumyUf3Agf0mKL5B5N76AXCd62n0CirRQzrJBSd1+tkkkIM+9jtnL7LhsSo3qiGhhaN3EWGw9mFhJTZNj+Cpqon/7ZPUgjBWSR+3p03KYEVnRtF3Uykd88zw13PcDZ5ixW7qSZ2QTTe89cSUmNob7vsQ0hKnYBN6LYrQsLbGMgyiaNc2GxZkuHFRpccIv4Ut8vESdqrMxq+umPFYR59Vj556DJtNX4IaOxYUFXbTtL7syHTWEojm0zHsnZbpcGtGohpOHMkDA+huqFiu4YpZZnO89cRRoodnrigHFv6xQzdmcDPi7bHLdLSoE0nv+P5mHCA2mPhnVPR0J2cqa5Ee3+DGkOuKmQawkM9lSSyKCkumo2nkR/GePZz12nCfBqEjaNzVxr2gtXhuPgsLHcQIKPq8RcnK0CKCVQH6Q3o4c/M5kXcmZlnwvP2sOKNinYA5/+YkFUc4SvPJQwk6kt9akJn0NRzlfUY9FeKbMrD2ehcXjc4GLxnIeqRKYGnr86T/kva4bVFbSzJQTLXIYTk3UFc7VEclb9yzN7xeJdrYyzHkpPMdBRL8PvQ+mo/Ib2/SPBFeg58Y7O+pCSER20BqeX++ec4T2ytjFzJSo96Hh022QGu9DcNRILW7AUwNwNcKxDTAISl3HJ3/D3+cVd5HLapwGT1XRd12vpf/nVK/tZUU4jQz/FUdlDZlmPRjhvde4SW/DY58PpvakPsNVn5+xj/l9SZoQnizrgK/Wz0QkzVSQ2eg3ErHinnGghg9tK5FMSM0T5QwkaJk9OX2/h/VeNK0Ui1NDy0ftbbYRC/zv6HhvmW1w6f+BTk0ZoR8wiuZ1nOZjeSItqs6gc+OJF0VS+yVcBE//RQ29wliGPOtSK1RX5mlE98WES+0iTQA6zjV4hPXcGCdN3e//H+4hl1EwJHu7y1yfGWj3yFZSqNdzTQOtmx2mjAuez4IfVANJljjqpkduzlpvp7rY86UjygS6tV5uzTTu0YGyCVxl5fUX7gfmyERsyMlfzD1JYr4JHqpFaUo0BEht61yHduY+BvAHIwKjPX/ZBpN22CAsqrfq+K2G4NiFlBsG4/A7PnutmxiZTPSnhNHJg5SO1YRCMCEi94jDoWZ9FMDCGvyewAR/COOFH/q8fhLF0eNsfBTuTfvWjyZSbdw07ZfcvMwrhZLT1Xt2yoZXYhNYrA2cbor+3ER2RjrhvUiWeryyABJnx4SlxMC7DDveLcWpVQfcdHklQ8/Fw34ikXsvEBbs+FC2RPP4Ys8FD0jrFA4+IpQrM/WcM3jScABU9SZBMaNlaHoyLq3XVdLMRCcwr+54I1f/41ePi85YirXBr6QZoGJ6h7Hl/zX8vDZzXwZdT5Mi95tCI0QBpJhIbly0ylnNb3uXpuVTJ6Fzii+tXDwFh7ldPerTfC/7QELD2cnxCOcyRf19ekIK+Tod8W7KWGlv7HKzHzRuVw+87Oa//cUh9vNpC/vLywkZYYEtEwrS+9MKc/9uTv59ZzpZ8Dg23kADQ0FKxbnowMVXrn8iUBYUUZfd53llmnyr7Q8RQKsCwg0n3cFm42LT5DsJkgsWz6EXccdFgyiiPlma9+k2k+of8F+DSZUHuCeek/HMD1hzOtTzlLe5c+2E6B8MicBLS9i6AbxcJfG501rHz9sZncoKEiNym8yp5qWfA3ldC3MppQKWD/IYEFy2+6EDlwSd9B8/dmG2ojj8Itp59iRw8Y0cK1RNZpUYrzU313gh6SB2rTeu3uozF1qs+0xSK8igBEzPidkmFH/FWvmyeXIDL3xD7/MxOscSXSOVwNqKKEkRY038IArm8N/Dj1U40i4oHJISL1/tyIdxdMtSrkoWyYPnVgch9RX+0m1fBaF068P4AIe97qahlHRTb22JBZZ0/QRm1u3cUjlBqoSC4lm7OR+KIh7nvFMGiF2DguO1CTvDLQO2D8AwbhrVEdl337cnlx6KzlC9SBXFSSqawRgpL+xIvdJCYHoCOwIH5Oy0teHfysmBINHuV+ElujufvQjYpu181gNA2zn3n/muBTtxzFKI0byzYOgMwJsnyHjVz6vE0L0y7j4w8RRxt2z6wTHBHVByaBoByR7YXp4ay9Af1G33M4uV4PRTCZzAnyKWFyc01c7U+6CCs0ATQheV+Y3hP4cQJ0bHx51rriaK1Xd/eeE3a1PmJiodQu/j3HxnePiZCfxsUeonaOJESC65mBDhoxKiFWeGvRBfSTiyzCDbpjRkElxgwrWOFcemHTBQe8CGbxKp718xgk0xkDZdooIim2/g9dMW3pJKu6qB96zC0jENivYtuijTZkGmcG0ZSuBsBP0WH4LivIx+j84G40F3FV7PdPl/X4d5/aw4snp0hmhuRvl//usBBHcFXqSPmL2ruS3evL7SWFHF3+FRPMnN579v2e+r4edGjfuJXb3zZahm65teSzoOvHkAqo5Ymx3URSuPDhVHeGEKX/iXfuoMvQrCoahd1Rht7xI6wDUeH0WUVPh+KKfFCH5PEBu3KGVkTu2ulJ+PP5B+nIDd7hEemHrYPvH4fQYCBjztHb2Dl6nU/jJTumGehuV0OBW/xGg2QsifPqccaiU1AGtkt2nGMqzRv5FgXJgynpdSpWg1ntvuxo6KeOOZkLCTcUbr4o7QiNcmpILedry1UHAvHKTPeAF9GX2MulFcaXmu5RKuRlZDz5Bl0q6eKaD2W5+43GkDndHEhFPkzQZuikJ6oi5g+xIWIA88Vpy7P9COIukKnKov1L8BaeprN1yIPTH/vwqy4MWdMVVaT+oq/aEfvqMfrOyiP8ju6orEscOnr+48FKhB4FIkHukd5GSser8gJQxBLTPtkUwZx77AB64tHrN/iD9KvchXpEHT42qaTTdpeLTbL9Kcnd8zb/3ZwDLxs4nmSaaDQYclQYIcvikvsZO3HA4wu3/xN9pOzYf7MAcNvrq9O1ZwJ6iiEnWYvkYVIY20+HTWSwhE9NeStRQRZ+pXhsxffKJsIL2aMUKUaNmlqpIz2CAsPGuAGhpGlG8OQJaFxSge3ZZplnDEpqTmQ== -------------------------------------------------------------------------------- /src/xml/OIH collaboration.xml: -------------------------------------------------------------------------------- 1 | 3cU2Fsd0GVkX1p8r3hRPO0Bmy7FAhFZeqIxxnS2HSZ7nkh5/dsk4o=I8oisSw5U2FsdGVkX1+xQ8Wgf797Bz7XVrFnXYIX5kb5l08/r2QgEXQeZNfQ/IN6R1Nc7dLybNzkrr4XlgHUNUKLVx2a8MHAmVIZjKsT6m6sDs+qfh2ORCp/+SdalKhXtjI+yE4fw9kb4yoWBwyLxJd+m5DhCq5FmjSIxsQeiMcdfkEKcmQ8vLHeOASVq9uWzEk5ggn+hD8e+TEdKFiHuejae+PTT901Cb12yUwmAHRL81d98bj0V9baR1T3ysj29InolLHtdbrRDXI51pXzNy3IrKzNC+rJz+46dOC9iEsLOjaieJVd3G5eYOz88ou1mXoutUNyF27h4nY7Or1Ig46Q8d2X0IjUX60uhuuVm59iRs/VTfW8ouLFLVgySwjJJAuEIDIh3QvFjhE4kl7HPgzxEfCUzsqj3As4vkM4XtYmQ/wW3WFtsbZEOOnCM2kbkmOpUt/7SoDcwgiAsPWI5W1n62gd3JxB9hkLlshDp9ozmS0Bofm6h5MaaZt6Vjdk2L3PdXibAIhUZMyrD15niaiZAyO77MaoCnfzx6jmo7SBlzqbEzShOR6rdbn2QFvAZKhAgZ3rMPbDmyJcP4hT9hzFSm6b7PeOx+YIObY8neiEoQ1sqIw7er+0tsk3o4Df3zA3eTb+ZUhE96HMVef3/pH35ZX3/tDlocJ/C15/OwNKNo/zdWq7HoO6cpS0zoudgB1EhN8294gODzEZKVX5qWzUEoZu0PQfPbPnXZfQ7A+fNpnQ1FVSk0i3qpbMRU9A21K66uIBtoihdNZVLCtAnWwiLSA+CGngVnPFkwqtajawpOFdTLEcp0/jR0kcFoNvwQccp1iqCAEzB91ff5iLtvnoXdgcI6qRmVRhGdT/pqw/S2as584UFELHushohbC40Xk6PNZ6DJbizuqQX84JdrEIGZfd4nzUAarWQZGhvuONqBgbHD5kffGw1iIgLn0UslcH53halhkNmIjrBBTblthtIPD8yM+Yw+PmzDmydMPwSJgX54jWmGcvXJyAo41qN7fwwpmnrQUmVrgKE4zU0sZPnr+O+KufXqjUfHZIqRBJ7VWDn4wzaOjqQMMe3Mgk6idda981QTwRkx7IWdBqCy7FBVoZ8FFwLWZKqK9Ws0pDB+kCFvi4t9WPzke5WZuJ51l2xMbBOdh2v4p3+NF8mIhgY6dyDVOvOKMFIXaelnAkT54o+XVqH6r1ZtyuZm92Qa7ZmLHBhCBWEVEuiTJry4K8J4xcWww6SeP497C8mWzjMIvDHs13j8M2C4mWAWS8yRpBnoNHZhfY9xrxwrULkKXKgLB7VD4Z9GHp0ZfD8Ht2cMbkpLdSZ+frDhaF7xlaMSC51R4PFlmdjxjcnK4s+YvWU2VCLzEU4s/QLodXXRx2Sk4lOPI5JHDcby8NyQuiDWE1K2l5Wh23BhT2A3gwGER09ZK596sWmVciuqkNSDp5QLR2GRJsGVjsGS0i1SNW8R+ZR6/o7JE+xPEl+XEB5y2/IgEqtQr1/3UKI0YkdS/C7RUwF81HNjRtw+6SEvH7IURn+skryuFQqnlG/o3CqWDw9czw0pEr5xRmAIg/0zo1moRps4WWqPI6vSNffUVNn8Z1VQx3exTmFnR3u9hbUv9LMo8E0zkMsFMz3viOamrnGgHdXZJv51emUHOGhd7v3CFXdda8S98695GTxISp9bgw2lfs7ziJR/Buh9tfGgDVjejdHzmVHgoNfz7marbl2Ih68GO7URzZF2kYtqwntDKHGdF1feoGUNxTXYqfaWJBwKDFHTf7d4+GrMfkWyGufoc/VptUm3x/GXt4U4TX0RUpI65cVEI0uAuiGCU+jBazKygcUMx2eXCN0MvXYDc1/5/gtaUf3+3YpqJMVUD7fPZeQ6btCEM4rz11LeHY4wo9JxH5x5eyi2RWqsfQP/ey57MIIZD+7X7uEomrR0sD2NeCBySAgFJZnlCMYfpQU/Hiae6NqiD2teYyUoYmqp7Eb5nNuUX/Xh3HBWkOVi7RfLL83pX7xUlv8hGplIyLnOcvw/W+F92tbchmO5qr6HbRUguTtiSjJ+4IxwDwA8sK4VDBXHtRQpImlFLOh5XayXzyZkejfgKu7SWJJa0uBBS9HcaaFISA3Wu593bgkR8WxiWDxusxUOxxsucyMz29qRc/g9go4WSWu7JlXQJoAJetBBwga8dcVVUSNQpvkjHQIZmkR94F3dTXh/lvEq0w8gNBf/29YZm+R7Pwy+qplHMs2PCixPsYU/L8OilUE5yhS/dXB2E4473T/L06/zg2d2idVQFbse06kIHPnabmMTOghsBvB45rSwaHEdaFxvfYm2ZQPWnarM4VQxCLAzTVcM7ejWCsFkjjl+1fBBpLJFx+WEpoEvwmECpLrrgAbBG8r6/xHlubXvM2pyvq0jbhkPKVs3YopU6R5QJsbz2Tmu9Z22m1IgaB1OwOyH+FFMpAseDGuSNCr9kvXNssaYOYirEr6+qx2Fbb/BSh5Fpt7THsL3+8nK8ED53Yl5vmFC/VxLkVXiW/O20AiL100TuSZAyPBXtOca+4C/D1iagqZQVlO9shdGQF5pa9qsMT0qq7gqko/+3Y2t8dInjFkyoHrr2MKuxxP8LO4+RsEARtp7j8PjqjUIz0XJW+QFh/+jSHuz3mC68vE1Nv6gH0DZMZNeilltlsR8/DzjqbvqJWKqTnUodJ0oacOEasLrEociwkdIZlUCJImxueckFV1PMj5NFeLcUZE6Cpv9A56ZioPhYHgxzp1a7RSotPp98QxPX1IMX/2ticmDTINmJ/vJpkfMrq/HhERQ7U2gscIWY25JEZwnY3e4cQ7q3QC5pVqp7VPruZBw1pWiGc7XDjFEAQKB5kf5/IG/vmPWX98Rj/uIT/PcvM6SmRpIA0fUnXMV2zOHRnQk7nCN/FYV6yFNwi1PlFS3DLTo8waaNG+ZvWyHBswtwZquvf3K18I2JiOP4dqaeQbF0tGVvfH+kjZxfLq993PS6pkFNp5wfS6NH2g6MX2ziAELGEfBdQYH2vsO32wf3nn2C/2Zm8X85EmDrLHfHKBVv6XOA+Zukslwq2qRrNsqcpJknMNeT6MQt6jbVVwL0pvGEwPaPFHSAM4QFpuo0jTYM/+wLcXm1BwJqlXHzz6NZ0opacGFry3ROCYYV4Eb6end7ESC8QTuHiV6L+ny2lXXIsBPNQlv8myg2BW4cqBZw7HJ7/z+zoWyOGlr+Oq8nPruCXmIhP/WY2afvAkI3p5J0ruLu6iIA2bRIonnWIwwbq3zvEA/TgvSXWkSjHoKd16jiSXB71Z4+s66ZBwZRL3s+v8KvC0FpmGL/cnl15+fuI5jkG3WXgs9Pm5+gkoS9wRGsl3gsTqjqYB3jZSSrrH/y0WB+VeUpXHgKTbGTFR+4eJEoB9peXtyzmjVYG/NND9OeQ2xZSgPFv93VkO68J7C+sNhQrFIS7cLHWzv4PIUXN4V4q5VqcEz6Zv5Z6K2U3KPykZem8djBHMVHdGTnB2SIsVoa5/xc17se4U4ZHDA0QdHNuT2r52sZ3v343AphHeV4a2i6XR/vK3ZVzZykAhx3Tg5A6XetejaEE2BCnWls/+8Ab/THSC1sdysV0heRibXOjA3bmLqXq0t8UWqPmkCUJBPvxN+4KYAiG8noRFKagU0piwqVjGcuX3EAw3OZLoJFYKF/Xrbn+YAPFtYlgJYe+ubA/M6GkOXkT0mRFmJs9HwDe3Ido6smN0HMMAgBQPMzCeK6B6D+Jnpfuat6KRtr0JQyzYHfjLfwhucqz9IBjdDOHh7h0/aRGLCkf2UoileGNdedHnLJgsIncaFNa3UsngF+TrbHwNssy8g7z2pLjNMyuX3iBoxc3ou5MUibjPW+H2zRCgQR59U+LXe6ssL7WO45HvuxuCAg2gGLREwRPq2mCXXdS1Pd9MWsacZglXw42h+1ANzNWTpnA22vaQV0EhEpXV03UpQ7mCYz514fg4kieIeBixex2zagUag1AtXZy6ZSS9WOZ2zT75rZodygXddx7aPeEP3X47YXRp8lbwtZvmUk4ZexSvTtqlIHNzymDtCKSukoaqHQT382LyofddDK6euBD4g2gfZGadPLBuJxPZqKSbmO3leS0EtlPiUBo1RDHIrotw8X2bszN2MY+qOCPliRBbdrasNoNmU+BtAMYSGl/n40b+0JpBMJYlyiReoW0UQvRWgqlirUQvAK9YnU8C41zSDsCmGtr+59uFuXlGOVqipozuTOqZSmvV7Oiyj2tiW457Hvfx0BMeIvDuiwoWFZtfL7e8o/G614T0CCEBasPy5fxQw+wFUfUISXbqlZ1eqQk/K9mov6PsGuf84C9dsGsGQYI83T8SV4B74Y14Lt7Y1ig8lIpPuIF0POwgJ9xGYa72VYdF0Drdn+NeJQuWrwz5MUuFxvKvGuLRXxzCE+E61ZzH+HLu8ZWTu2YM+3KErOIO9AOWc0jQ2WNYCajFKCU0Vh809zyY6uSFqIS1CUFc9oxe6HAvkN6s9mhYIgxRbQLExbcHNMiKlJP/6r4gtoQxElYszEWrYgYWOAVkcjPmskO5A4dvvIwM2n1rXR8kVtZWEkBWydc7jyvfRRILUCdpOiBHeEqdfDtqyg/DKrOvCZaE9WheSuoWeINcFTrsFbR09drFrPhozKIIQmTLuK60qNRzdtVCX+WfGzT0KUo3bRwaSO4DIa9wtoHtVqfJEE6UOAStooQXdNyBJ+x1+cPdvWLp/IAipiiE3/vd3ckfDMMDM4jAF8scu/hvFjaW6Fv40uVhiDzh3fmQF/vz0aSSiM55Inve0x44+/Rg3GEhQD1N4uYuo/V3mmnJLspxJYy0AKhsOl2X7JJ6JoA81i2TgrhOPegAcexmyixnJpQOFVpk4Pml4Ksg094bRTUa+K5NjNBplRYQE5VtYdz/EKXPVOFIosXHVrGUbR/V73ZIuZXA8oQzppswTTWqhfKyDpekNBx0Fdt+kxyITw3eRchzFy6vRuuHC/Tz3SxTaNagwwoXfPKXbNCM2aHyOJp8KLrInR/gy5qLsacRQ82dbNVu9N0N8WDgZydFnWmALYBzt8J9/qcv7M0Ur3kWLHFIGvv6+bwyTT43XX9IF4DKGz2AXxIwxeyCp/HDu6vHClzeicwI2qvR4BZJKMbqclphD5g9ojDWqzRU8/mLOrbFLjvqSf4SU874Tvm3uCy8Bt9+8IDNlnzaiJJy5Jf/HFFMSS1buwPPc0 -------------------------------------------------------------------------------- /src/xml/OihDataRecord.xml: -------------------------------------------------------------------------------- 1 | U2FsdGVkX1/C4uLvo1/oxkaoL2kiGbdXBNfB0W8zPkOI5KhOvYgQrueIzVHCzdfvUVP6z3WF9PrNO24TunDPbEt5be93U8X7/vlfSyQGf0xaDY/OEPike7f4j+JS3uMcavaWpFszBb6Pr9zrASDVtIBkj45q/MGns8ODFijgjqF7+jztVeodHu9HT702L0lvX4bT5a4sNToN8N7lAdPloGG2UV7rSUxS97j37PtnCmyd353veFVPI8Jzre1ZHSv07/gPzOlgIagkKShcWja6+pWd6zT9xb42AYOfqN3jJv6PHrZPaqW7EYn6OsWciqpGz/Pu3eJVPkjv+CKmAWSC0aHfVj5p/TyeNOBjwQ//XSGGxvQfkrLDQZ1OPRYpBtbMrIR+HIsJgsnpFHDALdGchLbodMToFn/egWkPuRb5uLxmdctIn7g/1KrZ2VqAArkeqT7OM/K6imun7U94/EYwy/ogm1k7JdtSYPG7PcMzkAVmPqYZBJpqv7QfOOwIC0PzEQ4lz1tR5ImbLcwhVMy1y0IdfLMCa0E/bvSO+/34rR2lqyTztJqO8+bRbWWSK0brLcI47l9WWTk2ZDOGObhs3zReRCv0R5o9Appgf8pY7LKy9l6OKY4rx+zSew2k/7CY4HgB/xwlrajaVLIqs5RqanqWTt8H5jodlcBxiupf1aBSkpp2qbx9rg2ULXH2hOEiGX8YkrJVZISnx51q25i+FZ0z+4bXk2M/3PQUfuQ69MMSDAc73v5v4HLkF2xR7AqxTl+8k6Wra7j/iUtYyldQKzb57NmYsotalnFts5KiEgb8Ywe2Z4WgOXWE/0FaPW3V2ZJOR7H1dlDTLhS0dXTUiaBmPBKpcOsq6baFlIlwQa3Q1cEMBaxGpFR1IqIWoltYxTMQQ8O4DbVgnb8hqBHaE1qECkN1OeJEql7EAXieO74E0Bdg7g0pI0GKAdVVOk4DWCpCdOm3mTHsZuU9rkt5KSioObjHyWjrsV6vkA0pkF5dj9PfHgld0SgTnkPds37/wCYnvpgsUe4cKmSNZmYt82G7XdhMoBPJwkC1jYRYw0Gqd/7+EAkzw0c5vs/Q4egWAnH5NvmTfeaN0KOKl6aFsGssYKyZsx3qSAAlhOqEbfliyBb6yR4CoRyFH/leuZ8fZX6jN3lPZgfzWWzqc1SG7dAkJbncEZvfiXHFggePhBSf+BnqpdRxaN6/+0v5Z2MMr2tM96YArUPge5YuYVAkTJBxfqTFxMXSNVnIp3bW2gC3KRbAYPn5VF688cBJFS3JIMJDlATiKYZaQTAaIswvveDSMwy1jdknJH5zR9DxYqFt8yfHV4HG888Ia4HSRgcw6WR2Es3SVutZihitEkdqfTPYE0b0txh+7DMGut8oMTyGiqxW9TYJLn+VINcfwaJ409qLvaTlyQPhQe7tFr96iHdILe2RbxK/9s7etZi8mKUG6xzkrRw+IWp7iwmYN22oKd/vX6bNaTnKEC1QnzVktMLS3qttl9h6OljJUJBZFDiQUnzYvx0sZBKDuW5/VJ0A/TaIdjSNEZLvOpYR6r9hjUyxWChZxncu1ejiA4nAqIdz3UgGTfQJLlMQTdPmG5aqVDBsS18v+CcF1etAEMTYKMTA/S7bJoJlber0cdsWDUZLQzItqc1b+C2q3DdsvQ5pyP453LD3n7R1F+2R3lRPJncblsLp9GYdVYWyMlT9WmsIVMyk6gsuvXFdKao/l6p2hIsvkoe2ybB+BNH2Lr6mJK0T8BkVsjTWZHkcgDmkzSdSVji8py+kVYpaXMVnPYtpm6rdH5/3UeIGKjCZTnYaHjc8LXsgZkGOtpdAxXK/fo8p4SHpRR8O5MHqflRSd8lud6PC6SVRYAHRtdqXAnb4JuOrdX4R7jDmIa41u4m7ltnf0vjUNagRbbb7ygBGCc8RDdvw0GoggPr4HxN3NV1fyG0ylBY6gzhswqUZZ6OwbI7IGdnpJcOh96Q+YjIbh8tyiKBdokcNGX3YxeOcNiSyAo2pv6J1q/u/9jBcJI3dgopJoy5PM6wY5ccL+Rd2F4U2Z+QBOEGRrO9x8XMTPYY0ZMLlTCBOuRWI4p68PReP6ZNdtsAW/nfe52Z+CHHKmNWxA2RPkv+WvVMFIDUhoKeGcPQbaIywb9iLG+AclIT4NzrUNgr+BozwOZofK+nFRceF9TqqrPIHoyrnmZOKA1DxNWBkMrMWIC0OfA5dTHtO0Np4vMFe9mh+ozEzyJZgSI7wDeyAzkUzz4T3nFdzTxeSdLQOb/mqw7HHPIt4UeMi3si+k5ERnNL0FyL0SXYo/Bc5856Yl2s9GIMdlG7exiHoRpg2P0zSWu1AWRFEtky43njO6qwsUd2XCLSohVrmgxO591hZadDB6zaIpsTJHVFSonQBFMTISPnRPh3afxYfHGwPJKocxf0OINt3Izi0heIVY+neZTFmiZFpq02gvQcW2Qt0tmxCArvAuI4BOmvQsjinZZbD8YX94x/yZyAdEvw0ovrEuEX5eayFkej2u4Nknavb2ey9zAMEzX3cr7o4UG7lwMHlPw6CI+u2cQd7B/v89UXxpTPRyofRn2aoQniIjhAFY2Ikanhev04kVX64JGh12ZFydCTVesnonUl/R0xUmynV9X2AqveTdHUUaH0rEy3c5oSLfqLRflz+AwukfvY= --------------------------------------------------------------------------------