white paper . doc - alternativeplatforms.files.wordpress.com · web viewcore digital...

Alternative Platforms – White Paper

© Alternative Platforms, 2018

Abstract

Alternative platforms is an open environment for developing decentralized systems cheaply and efficiently. They are called alternative because they will enable individuals to control with whom, when and what they communicate and as such they will also present an alternative to the current platforms that control individual persons rather than individual persons being in control of them1.

Alternative platforms do this by providing digital infrastructure for developing simple personal communication tools (PCTs) that enable:

- Presenting information visible to other systems/platforms (e.g. info with whom, what and when the individual using a PCT wants to communicate);

- Searching for information visible on other systems/platforms (e.g. whether a retailer provides efficient privacy protection of customer data); and

- Exchanging information with other systems.

Inevitably, Alternative Platforms will enable other non-PCTs to do the same – to present information, search for information regardless if it is presented by a PCT or any other system and exchange information with other systems.

In addition, Alternative platforms will simplify development of online systems for many different processes; all such platforms will have embedded communication with PCTs and with other platforms using the same published open standards. Alternative platforms will also enable smooth interconnection with other platforms.

The following are the principles of Alternative platforms:

1. Alternative platforms will not have a central place of administration or control. There is no obligatory central registration of alternative platforms, there is no central place where all the information about all alternative platforms are held. There is no central authority monitoring or supervising alternative platforms.

2. Individual alternative platforms are independent and have a form of an open platform/system based on published open structures. Nevertheless, the Alternative platforms technology might also be used for connecting open platforms with closed private systems that have central admin;

3. Alternative platforms will enable people to set-up easily with whomever they want to communicate, in their own language. This information will be „visible“ in the appropriate form (encrypted or not, in a standard or private format etc.) on the PCT of the individual person, who is using Alternative Platforms. It can be read by other systems of providers or institutions; existing people-focused systems like browsers, anti-spam and anti-virus tools will also be able to work with such information;

1 Alternative platforms has been inspired by the VRM (Vendor Relationship Management) initiative.

4. Alternative platforms will also provide the same possibilities to providers and institutions, utilizing the same concepts and same open standards;

5. Alternative platforms will also enable efficient re-use of existing code for other companies’ or institutions’ platforms working in different areas;

6. Alternative platforms will use all the existing internet infrastructure, they do not necessitate developing new internet or new communication, addressing or other environments;

7. Alternative platforms are equal as smart contracts in their aspiration to implement all or almost all variants of certain legal relationships (contracts). While smart contracts are connected with blockchain technology, alternative platforms are technology neutral.

8. Alternative platforms will enable efficient security protection against malware; and

9. Alternative platforms will be able to share their statistical anonymous data with other alternative platforms and in return they will have a right to access aggregated statistics.

Personal communication tools as key starting point

Amongst the key applications of Alternative platforms are personal communication tools (PCTs). PCTs can: (i) search for information displayed by other systems in a format visible to Alternative platforms (e.g. whether a retailer enables effective privacy protection of customer data); (ii) present information visible to other systems which understand Alternative platforms format with whom, what and when the PCT wants to exchange data; and (iii) send and receive relevant data. PCTs control:

(i) what info is made available to other systems and their users; (ii) what info is requested from other systems; (iii) who is allowed access for communication purposes; (iv) what info can be communicated; and (v) when the communication can occur.

This information can be set-up by users of PCTs and will be available to all other platforms in an open published Alternative platforms‘ format.

Same rules as for PCTs will be used for B2B, B2G and G2C/B platforms. All alternative platforms will communicate using the same communication standard.

Identifying structural similarities in different processes or smart contracts

Alternative platforms are based on identifying structural similarities between unrelated processes (e.g. online dispute resolution (ODR) and shipping). These similarities are called Constellations and have various graphical shapes (see below). Each Constellation has a number of Masks describing in detail possible variants of a process or Constellation.

Once a structural similarity is recognized, it is possible to re-use portions of open code created for one process inside other processes that may have been developed for very different systems. Due to

the open-source technology, it should be possible to develop only a small number of initial Constellations and let the environment be continuously expanded for concrete projects by anybody interested. Initial Constellations have been designed to implement processes of online dispute resolution (ODR) because of the author’s close familiarity with ODR processes and also because ODR empowers individuals.

Alternative platforms can be connected with other Alternative platforms or through any other platform or system, due to its totally open and flexible character.

Alternative platforms relate closely to blockchain-based smart contracts. Both are understood equally as horizontal online systems which implement all, or almost all variants of legal relationships (contracts). Smart contracts are based on the blockchain technology while alternative platforms are technologically neutral.

Advantages of Constellations:

- Re-using digital code already developed and proven in practice for structurally similar processes;

- Easy modification and further development of online platforms due to open standards, growing pool of available Constellations and developers with practical know-how and experience working with Alternative platforms;

- Developing personal communication tools of new generation for integration with horizontal platforms including smart contracts;

- Possibility to interconnect with many other online platforms using the same open standard, including building fully or party automated processes;

- Possibility to globally exchange anonymized statistical data for the benefit of all the users of Alernative platforms (including but not limited to constructing AI tools).

Business model

Business model of Alternative platforms is based on proceeds from the following services:

- Turn-key projects;- Consultancy;- Support;- Operation of associated online market of modules based on Alternative platforms. Although

the basic modules of Alternative platforms will be free, users will pay for the following: (i) access to online market for re-use of already existing code; and (ii) placing their module(s) on online market for reselling to others;

- Users who will share their anonymous data for statistical purposes will get basic aggregated data for free; users will pay for downloading (from the online market) a module for sharing their anonymous data as well as for advanced AI modules; and

- Comprehensive address list will be for free for those who publish their addresses within Alternative platforms; nevertheless users will pay for services of search engines available from the online market.

The first Constellations were created for online dispute resolution (ODR) platforms because ODR is the area of know-how and expertize of the author of Alternative platforms. ODR will serve as a test-bed and prove of concept of Alternative platforms.

1. Concept of Alternative platforms

Alternative platforms is a concept of an open-source environment for design and development of many variations of online platforms. All diverse platforms will be independent but can be inter-connected because all will implement the same open standard.

Alternative platforms are horizontal platforms, there will be no central place from which all the alternative platforms would be controlled.

Alternative Platforms will be based on the following:

- sharing structures or constellations which are common for more than one general process which is to be implemented by an online platform; and

- open standards and open-source software implementing the standards.

2. Constellations

A Constellation is a core digital representation of a process or group of processes it describes (e.g. negotiation of a contract or insurance). From a constellation all possible variants of the process can be composed by adding additional layers of data flows on top of the Constellaltion (as a 3d model of the process). The Constellation remains the same.

Constellations can be depicted as abstract graphs representing core relations between key stakeholders in a certain process. Although the stakeholders differ for different processes (e.g. for ODR and for insurance), the abstract Constellations or their parts might be the same. It means that a single Constellation can describe (i) all alternative variants within one process and (ii) different unrelated processes with the same or substantially similar core structure.

Key assumption of Alternative platforms is that Constellations or their parts might be shared among processes which have different purpose but are structurally substantially similar.

Due to using open-source technology it should be possible to develop only few core Constellations and let the environment be continuosly expanded for concrete projects by anybody who is intersted.

Alternative platforms can be connected with other Alternative platforms or any other platform or system, due to its totally open and flexible character.

The initial Constellations are the following:

2.1 Smart Door Codes – the starting Constellation

The first Constelation is called Smart Door Codes (SDC). Its purpose is to describe communication as such. SDC forms a core of personal communication tools (PCTs).

Smart Door Codes E1-n

I1-n

ADDRESS=ID

Smart Door Codes or SDC is a quasi standard aimed at enabling structured communication between different alternative platforms or smart contracts.

SDC will also enable to develop apps for structured communication with alternative platforms or other systems – the personal communication tools (PCTs). SDC will be independent on any system or tool.

PCTs can: (i) search for information displayed by other systems in a format visible to Alternative platforms (e.g. whether a retailer enables effective privacy protection of customer data); (ii) present information visible to other systems which understand Alternative platforms format with whom, what info and when the PCT user wants to exchange data; and (iii) send and receive relevant data.

PCTs control:

- what info is made available to other systems and their users; - what info is requested from other systems; - who is allowed access for communication purposes; - what info can be communicated; and - when the communication can occur.

This information can be set-up by users of PCTs and will be available to all other platforms in an open published Alternative platforms‘ format. PCTs will need to interconnect with adequate security technologies (secure ID, anti-virus, etc.) to safeguard PCTs against malware, misinformation or misrepresentation by other systems.

Same rules as for PCTs will be used for non-personal systems such as B2B, B2G and G2C/B platforms. All alternative platforms (for individuals as well as corporations or public entities) will communicate using the same communication standard.

SDC will enable to configure such communication in advance at the design stage of alternative platforms or smart contracts. The communications might be automatized or they will require human intervention, according to the needs of a particular process.

All the communication strings will be open source. Parties using Alternative platforms technology will be able to configure the communication strings – add new ones, delete some or edit some.

The communication of internal nodes (I1-n) of “SDC” with external nodes (E1-n) of external platforms can be in the form of either (i) presentation of information, e.g. that consumer ODR is available for purchases from that retailer; or (ii) exchange of information, e.g. about new services; or (iii) both.

The Dot node in the centre of the circle is the communicating stakeholder or its system, represented by address(es) or ID(s) applicable for various levels of communication.

One of many potential implementations of SDC is called Customer Door Codes (CDC). It is an open description of an app for people communicating in their language with vendors about (i) available privacy options provided by the vendor; and (ii) available online dispute resolution systems of the vendor. The app is called Customer Door Codes.

2.2 Other initial Constellations

External nodes of the SDC Constellation are access gates to other alternative platforms/smart contracts or non-alternative platforms. The alternative platforms might be based on any of the following additional initial Constellations:

Light Swords

Examples of processes: (i) negotiation about a customer issue between a customer and vendor; or (ii) negotiation of a contract between 2 parties.

Flower

Examples of processes: (i) negotiation about a customer issue between a customer and integrating vendor; different aspects of the customer issue is dealt with by separate suppliers of the vendor; the vendor serves as a single front face vis-s-vis the customer; or (ii) negotiation between a company and its logistics provider.

Space Ship

Examples of processes: (i) negotiation about a customer issue between a customer and vendor of specific goods (e.g. digital games), where the vendor refers its customer to various vendor’s suppliers which deal with individual aspects of the customer issue directly with the customer; or (ii) agency relationship where an agent facilitates conclusion of contracts between a company and its customers.

Child

Examples of processes: (i) resolution of dissatisfactions using a single third-party neutral; or (ii) simple third-party services (e.g. simple transport of goods).

Castle

Examples of processes: (i) online dispute resolution (ODR) system with an ODR administrator and two or more neutrals to resolve a case; (ii) more complex third-party services (e.g. insurance).

Advantages of Constellations:

- Re-using digital code already developed and proven in practice for structurally similar processes;

- Easy modification and further development of online platforms due to open standards, growing pool of available Constellations and developers with practical know-how and experience working with Alternative platforms;

- Developing personal communication tools of new generation for integration with horizontal platforms including smart contracts;

- Possibility to interconnect with many other online platforms using the same open standard, including building fully or party automated processes;

- Possibility to globally exchange anonymized statistical data for the benefit of all the users of Alernative platforms (including but not limited to constructing AI tools).

3. Open standards

The open standards will describe the Constellations for particular processes. Each Constellation of a process is comprised of the following: (i) a mask of the Constellation which might remain the same or substantially similar for some different processes; and (ii) content filling the mask which is always different for different processes.

3.1 Mask

Each Constellation’s mask might be comprised of one or more of the following components:

- Dot: a Dot represents a stakeholder/role (person or person’s system); - Triangle: a Triangle represents a result of a process (e.g. a settlement as a result of

negotiation between the parties);- Line: a Line represents all information flows between two Dots (endpoints of the line); (e.g.

all different alternatives for information flows within a negotiation process (depicted as a line between two negotiating parties);

- Circle: a Circle represents unlimited number of variants of certain feature of a process or processes (e.g. unlimited number of platforms with which it is possible to communicate); and

- Splash of colour: Colours/sounds represent art and/or emotions which might be present in any constellation or its component;

- Other: There will be other elements developed by the community, nevertheless for the moment the existing elements are sufficient for constructing ODR Constellations.

Each of the components mentioned above has a number of characteristics which shape the individual data flows forming the 3d shape of each Constellation. All the characteristics must be capable of describing masks of multiple processes. All the characteristics are all anonymized, no personal data are needed:

- Dot: (a) data flow related: (i) structure of profile; (ii) structure of dashboard; (iii) structure of registration; (iv) process statuses; (v) screen structures; (vi) other;(b) content-related: (i) legal status: physical person, company, public institution or their systems; (ii) attribution of roles to the parties (if Dot combined with Line): only role of a party filing the communication (e.g. complainant); only role of a party receiving the communication (e.g. respondent); multiple roles (e.g. complainant or respondent); (iii) language(s); (iv) legal representation yes or no; (v) advisers yes or no; (vi) Address(es)/ID(s); (vii) statistics; (vii) other; Note: legal representation and provision of advise are also independent processes, therefore there will also be separate constellations with separate data-flow characteristics.

- Triangle: (a) data flow related: (i) goal/result unilateral (of one party – e.g. escalation by a party to ODR institution) or multilateral (e.g. agreement); (ii) form of result: a document or reaching a status (e.g. „I agree“ message as a reaction to a proposal from the other party); (iii) access (plugins, interface, integration); (iv) process statuses; (v) screen structures; (vi) user reviews; (vii) other;(b) content-related: (i) statistics; (ii) other;

- Line: (a) data flow related: (i) data flow in one direction; data flow in opposite direction; data flows in both directions; (ii) data flow triggered by and/or followed by; (iii) number of levels of communication; (v) structure of communication; (vi) form of communication; (vii) process statuses; (viii) screen structures; (ix) other;(b) content-related: (i) data flow with a goal (triangle), without goal; (ii) language(s); (iii) advise; (iv) statistics; (v) other;Note: provision of advise is an independent process, therefore there will also be separate constellation with separate data-flow characteristics.

- Circle: (a) data flow related: (i) presentation of information; (ii) communication of information; (iii) both; (iv) process statuses; (v) screen structures; (vi) other; (b) content-related: (i) statistics; (ii) other; and

- Splash of colour: (a) data flow related: (i) process statuses; (ii) screen structures; (iii) other;(b) content related: (i) colours or sounds or both describing artistic or emotional feelings; (ii) statistics; (iii) other.

3.2 Content filling the mask

The open standard will describe the following levels of content and corresponding mask:

(i) What area (e.g. ODR) and its identification (Id); (ii) What sector (e.g. ODR for food-stay-play) and its identification;(iii) What processes and process variants (e.g. simple negotiation; negotiation with multiple

parties; negotiation with multiple parties and one integrator; negotiation with escalation to independent third party neutral; negotiation, escalation to independent third party ODR institution, monitoring of implementation) and their Ids; based on the first two levels, constellations can be build in step (iii) below;

(iv) Constellation(s) of the processes within the sector (e.g. ODR constellations) and their Ids; (v) Issues per each process and their mask representations in the form of the relevant

characteristic components of each constellation (e.g. roles of the parties involved) have their mask representation in the form of dots variants (e.g. one stakeholder or its system can play only one role and not the other role; or one stakeholder can play either role);

(vi) Screens corresponding to issue(s) of each process and their corresponding screen structures; and

(vii) If certain groupings of component(s) of a particular constellation and connected mask structures becomes popular among designers or developers, they might get their own specific symbols (Symbols) in order to simplify their re-use in other platforms. Symbols will emerge as part of the development of Alternative platforms.

4. How will Alternative platforms work

When a new platform or smart contract is being designed, developed and put into operation, Alternative platforms can help in the following way:

4.1 Assisting in designing new platform

When a new platform is planned, Alternative platforms will automatically guide a user through a set of general questions describing the planned solution. General questions and user responses to them will enable the user assisted by Alternative platforms to “build” draft constellation(s) for the process(es) for which the new platform is planned.

4.2 Recognizing existing constellation(s) or drawing a new constellation

Alternative platforms will then provide the following exercise:

- Is there a platform for the process the user wishes in Alternative platforms?- If not, is there a similar constellation to constellation(s) of the process the user wants to

implement via Alternative platforms (although describing different process)?- If not, are there similarities between component parts of the planned platform and existing

process components developed via Alternative platforms?

4.3 Recognizing similar existing process masks or creating new masks of the process

Alternative platforms will guide the user automatically to prepare additional set of specific questions and answers regarding main issues of each of the components of the prepared constellation(s). Such specific sets of questions for various processes or smart contracts might also be prepared by specialized law firms, consultants or academic institutions.

At the same time Alternative platforms will identify (i) existing masks similar to what the user wants to develop; (ii) offer available Symbols (portions of masks) which might be useful for the user in developing its platform or smart contract; and (iii) provide the user possibility to create new Symbols in Alternative platforms with which it can write mask of the process it wants to implement.

4.4 Selecting screens that fit the mask(s) of the process

After preparing mask(s) of the process the user wants to implement, Alternative platforms will automatically guide the user to identify the following:

- Are there available screens which fit the mask(s) the user wants to implement?- If not, are there available blank screen structures fitting user’s masks from which the user

can built blank screens for its mask(s)?- If not, the user will be able to create new screen structures to fit its mask(s); and- The user will be able to edit the screens that fit its mask(s) to get screens according to the

user’s needs.

4.5 Finalizing the screens and implementing the new platform or smart contract

Alternative platforms will enable to design look and feel of each screen according to the needs of the particular platform or smart contract.

Alternative platforms will automatically record the final constellation(s), mask(s) and screen structures of each new platform.

In addition, each platform can get a unique address for communication among platforms.

4.6 Placing newly developed module(s) on the online market of Alternative platforms for resale to others.

Newly developed module(s) or constellations might be placed by their developers on the online market of Alternative platforms or any other market for resale. The associated documentation of Constellations, masks and screens must be shared together with the corresponding open code of the module(s) for resale. This is a condition of access to the online market for resellers of modules or Constellations. Online documentation will be created automatically by Alternative platforms during the development process, as mentioned in 4.5 above.

Access to the online market is not restricted or limited to potential purchasers who can be organizers of other Alternative platforms or other open platforms or other platforms. In addition, there might be multiple online markets selling modules of Alternative platforms.

5. Business case of Alternative platforms:

Business model of Alternative platforms is based on the following services:

- Turn-key projects;- Consultancy;- Support;- Operation of associated online market of modules based on Alternative platforms. Although

the basic modules of Alternative platforms will be free, users will pay for the following: (i) access to online market for re-use of already existing code; and (ii) placing their module(s) on online market for reselling to others;

- Users who will share their anonymous data for statistical purposes will get basic aggregated data for free; users will pay for obtaining statistics module for sharing their anonymous data as well as for advanced AI modules; and

- Comprehensive address list will be for free for those who publish their addresses within Alternative platforms; nevertheless users will pay for services of search engines available from the online market.

6. ODR Contellations

In this part we show how ODR processes can be described via Alternative platforms on the example of 2 processes, one general: Smart Door Codes (SDC) and one ODR-specific: simple negotiation.

6.1 Building ODR constellations

Name of section

Parts of the section Corresponding Ids in Alternative platforms

Area/Sector ODR Id of ODR: 0DR

Processes Smart Door Codes (SDC) = communication as such

Id: 007

Negotiation Id: 006

Escalation to independent third party

Id: 005

Process variants- SDC

Smart Door Codes (SDC) – general variant

Constellation Id: 007

Process variants - negotiation

Simple negotiation Constellation Id: 0061

Negtiation with multiple parties Constellation Id: 0062

Negtiation with multiple parties and one integrator


Other variants of negotiation To be developed by the community

Process variants – escalation to ODR

Simple ODR process, single neutral Constellation Id: 0051

Complex ODR process with one or more neutrals and monitoring of implementation


Other (e.g. additional e-justice components – preliminary measures etc.)

To be developed by the community

6.2 Example: setting up issues of ODR processes and their masks within „Smart Door Codes“ and „Simple negotiation“

In this part we describe issues of the following ODR processes via mask structures: (i) Smart Door Codes (SDC) and (ii) Simple negotiation.

6.2.1 Smart Door Code (SDC); 007

Constellation:

(a) Questions in order to select or prepare Mask(s) of the Constellation:

For Smart Door Codes we do not distinguish general and specific questions, because SDC describes communication as such which is general to all processes. The questions are as follows:

Q1: Do you want to design and develop a personal communication tool (PCT) to access your system or other systems/platforms?

Select from the following options:

(i) Yes(ii) No(iii) Other

Q2: If yes, which kind of PCT would you like to develop?

(i) A module for general PCTs (available for all PCTs compatible with Alternative platforms standard);

(ii) Specific PCT (with restricted users – e.g. only for buyers of a certain brand; Note: also a general PCT might have a restricted space for certain users only – see Q 12 below)

(iii) Combination of both;(iv) Other

Q3: What set of info requests (i.e. questions PCT users will ask your or other websites via the PCT) you would like to implement for the PCT?

(i) Select from the existing sets(ii) Define a new set(iii) Other

Q4: What languages would you like to use for your PCT:

(i) Select from the existing sets(ii) Define a new set(iii) Other

Q5: What options and preferences would you like users of your PCT to be able to set up for their communication with your website or other websites/platforms?

(i) Select from the existing options and preferences per each requested piece of information(ii) Define new options/preferences

(iii) Other

Q6: What options for presentation of information visible to users of your PCT do you want to place on your website or provide to operators of other websites/platform?

(i) Corresponding to Q3(ii) Other

Q7: Would you like users of your PCT to be able to set up in their PCT information visible to your web or other websites about (i) with whom they want to communicate; (ii) what data they are interested to receive and when (ASAP, regularly, other); (iii) other?


Q8: What set of info requests (i.e. questions your platform or other platforms will ask your PCT) would you like to implement for your plaform or provide to operators of other platforms?

(i) Corresponding to Q7(ii) Other

Q9: Would you like to include IDs in your app?


Q10: If yes, the ID will be available:

(i) Only for certain users (e.g. users with access to a private area)(ii) All users will be able to get their own ID(iii) Other

Q11: What security measures would you make available to users of your PCT to protect them against misrepresentation/malware from other platforms?

(i) Encryption(ii) I/C with anti-virus systems(iii) Other

Q12: Would you like your PCT to have a private area accessible for certain users only?


Q13: If Yes, design below the components of the private area:

(i) Textual information(ii) URL Links(iii) Ids for user accessing other systems/platforms

a. Access IDs of providers using your systemb. Your ID for access to your platformc. Other IDs

(iv) Other

Q14: Design your Smart Door Code area on your website:

(i) Access gateway to your SDC area(ii) URL link(s) – e.g. related to your [ODR] system options(iii) Your Private area corresponding to private areas of your users (iv) Responses to questions in your customer app (e.g. on customer empowerement)(v) Other

Q15: Would you like to establish exchange of information (communication) between your [ODR] system and other platforms including user apps?


Q16: If yes, which smart contract(s) or online platforms would you like to interconnect with your [ODR] system for information exchange?

(i) Will you select from existing connection(s)?(ii) Will you define new connection(s)?(iii) Both?(iv) Other?

Q17: Per each connection, will you select from available options below?

- Sets of subject matters?- Corresponding „Triggered by“ screens?- Corresponding „Followed by“ screens?- ID options?- Attachment options?- Cc options?- Bcc options?- Forward options?

OR will you define new sets and options of the above?

OR Other?

Q18: Would you like to include in user accounts of registered users of your PCT a user profile and dashboard?


Q19: How would you like to design your PCT?

- Present different design components and their options

Q20: How would you like to deliver the PCT:

(i) As your (the system organizer) server with users’ registration on your server(ii) As a web service with user registration in a central cloud (for modules for general PCTs)

(iii) Other

(b) Describing Mask(s) of the selected Constellation

This part shows different available variants of the Mask(s) of the intended ODR process depending on which options were selected in the questions above:

Constellation component: Circle; Id: 007-1

Issue/Sub-issue Mask1. Presentation of

informationSmart Door Codes (open quasi standard); an example of implementation of SDC is included in Annex 1 below;

1.1 Syntax 1.1.1 Beginning of any SDC string: “SDC:-“1.1.2 Identification of the smart contract(s) and issues of the smart contract(s) involved: “SCxxxx,xxxx,xxxx:o”, where xxxx is SDC for a particular issue of a particular smart contract1.1.3 End of any SDC string: “:-QDC“1.1.4 Beginning and end of an info block within SDC: “__:-”, where __ is the info block1.1.5 Separation of info blocks: with a comma1.1.6 URL link may be represented in the SDC in the following way: “&&&www.seller.com/feedback-en&&&:-”, where the “&&&” give information to the system that it is reading a URL code.1.1.7 SDC for mere presentation of information uses the following string structure:SDC – Smart Conract(s) - Beginning – Elements – End

1.2 Questions 1.2.1 Questions indicate which information is requested to be presented. All available questions related to a particular issue of a smart contract are set in a structured order. Each question may have attributed any of three digits – either “0”, “1” or “?”, where “1” means that answer is sought to this question, “0” means that answer is not sought for this question and “?” means a neutral position. So the questions might be represented in SDC in the following way: “SDCQ:-10?:-“, where SDCQ is the SDC code for the respective set of questions.1.2.2 Each question has a specific Id of that question1.2.3 Select from available questions1.2.4 Add new question

1.3 Answers 1.3.1 Answers are the requested information. Such information may be represented in SDC in the following way: “SDCQMessage:-xxxxxxxxx:-“, where xxxxxxxx gives the text of the message.1.3.2 Each answer has a specific Id of that answer1.3.3 Select from available answers1.3.4 Add new answer

1.4 Language(s) 1.4.1 Each language has a HTML ISO Language Code, where it is represented by exactly 2 letters. For example, English is “en” and

Czech is “cs”. Therefore, the language will be encoded in SDC as “LC:-”, where “LC” is the particular language code.1.4.2 Select from available localizations1.4.3 Add new language1.4.4 Other: to be developed by the community

1.5 Options and preferences

1.5.1 There may be several optional variants of the requested information and the system presenting the information may have preferences over those variants. This information might be described in the SDC in the following way:“2:-“, where the number indicates the preferred option of the requested information. The option starting with “1:-” would be preferred to the option starting with “2:-” and so on. If the number is “0:-” the system has no preference regarding options of presented information.

1.6 Address/ID 1.6.1 The way the ID of the parties or systems involved are formed will be decided individually by each SDC provider. However, the main code will look like this: “SDC_ID:-xxxxxxxxx:-”, where the “xxxxxxxxx” gives the ID.

1.7 Private info 1.7.1 CDC will also include private area which will enable to present specific information to certain users only. Beginning string of the Private Area will be the following: “PRIVAREADC:-”. This informs the app that it is reading a Private Area Door Code.Provider’s information in the private area follows the syntax and elements of the rest of SDC and/or other rules agreed between the provider and user app producer.

1.8 Statuse(s) 1.8.1 No statuse1.8.2 Add/Delete statuse1.8.3 Change statuse: new statuse

1.9 Screen(s) 1.9.1 Screen type 1-n 1.9.2 Screen triggered by [Ref]1.9.3 Screen followed by [Ref]

1.10 Possibilities to edit1.11 Other

2. Communication of information2.1 Communication standard

2.1.1 RFC 822

2.2 Address/ID See 1 above2.3 Statuse(s) 2.3.1 No statuse

2.3.2 Add/Delete statuse2.3.2 Change statuse: new statuse


2.5 Possibilities to edit

Related to screens not Mask

2.6 Other To be developed by the community3. Both4. ODR Statistics 4.1 Settlement rate

4.2 Implementation rate4.3 Time to reach agreement4.4 Success rate of each party4.5 Most negotiated issue of either party4.6 Most negotiated issue of a sub-party (e.g. a shop of a retailer)4.7 Feedback statistics4.8 Other statistics

5. Other (possibilities to add)

To be developed by the community

Constellation component: Dot; Id: 007-2

Issue/Sub-issue Mask1. Structure of User

Registration- Open standard(s) if available;- If not, Alternative platforms open solution; or- Also option to use own private solution.

2. User Address/ID Different Address/ID options depending on their purposes 3. Structure of User

DashboardSee 1 above

4. Structure of User Profile

See 1 above

5. Legal status 5.1 physical person5.2 legal person

6. Legal representation 6.1 Role of legal reps included 6.1.1 LR communicates, party has passive access to the platform and is only copied 6.1.2 Party communicates, LR has passive access to the platform and is copied 6.1.3 LR communicates, party does not have access to the platform and is not copied6.2 Role of legal reps. Not included in ODR platform6.3 Other: To be developed by the community

7. Sub-User(s) 7.1 Sub-User(s) 1-n7.1.1 Who sets-up Sub-User

- User- Sub-User

- Third party7.1.2 Same options of masks for Sub-User as for the User7.2 Sub-Users no

8. Statistics See 007-1 above9. Statuse(s) 7.1 No statuse

7.2 Add/Delete statuse 7.3 Change statuse: new statuse

10. Screen(s) 8.1 Screen type 1-n 8.2 Screen triggered by [Ref] 8.3 Screen followed by [Ref]

11. Possibilities to edit Related to screens not Mask12. Other (possibilities to

add)To be developed by the community

Constellation component: Triangle; Id: 007-3

Issue/Sub-issue Mask1. Access (plugins,

interconnection of other systems with „Me“, integration of „Me“ to other systems)

- Open standard(s) if available;- If not, Alternative platforms open solution; or- Also option to use own private solution.

2. Statistics See 007-1 above3. Statuse(s) 2.1 No statuse

2.2 Add/Delete statuse 2.3 Change statuse: new statuse

4. Screen(s) 3.1 Screen type 1-n 3.2 Screen triggered by [Ref]3.3 Screen followed by [Ref]

5. Possibilities to edit Related to screens not Mask6. Other (possibilities to


Constellation component: Splash of colour; Id: 007-4

Issue/Sub-issue Mask1. Use of colours 1.1 Splash of colours

1.1.1 Select from available colours1.1.2 Add new colours1.2 Objects1.2.1 Select from available objects1.2.1 Draw new objects1.3 Other: To be developed by the community

2. Use of sounds 2.1 Select from available sounds2.2 Add new sounds

3. Both 4. Statistics See 007-1 above5. Statuse(s) 4.1 No statuse

4.2 Add/Delete statuse 4.3 Change of statuse: new statuse

6. Screen(s) 5.1 Screen type 1-n 5.2 Screen triggered by [Ref] 5.3 Screen followed by [Ref]

7. Possibilities to edit Related to screens not Mask8. Other (possibilities

to add)To be developed by the community

6.2.2 Simple negotiation

(a) General questions in order to select or design the Constellation (options marked in yellow have been selected):

Q1: Should your ODR system include both feedbacks + complaints? Or only complaints? Or only feedbacks?


(i) Both complaints and feedbacks(ii) Feedbacks only(iii) Complaints only(iv) Other

Q2: If your ODR system is to include complaints, select from the following options:

(i) Only direct negotiation between the parties (no third party ODR involved)(ii) There will be no direct negotiation between the parties involved, all complaints will go

directly to third party ODR(iii) Both direct negotiation and escalation to a third party ODR will be possible(iv) The complainant will decide whether to try direct negotiation with the respondent or

skip the negotiation and immediately escalate to a third party ODR without negotiation(v) Other

Q3: If you are a respondent (e.g. a retailer), do you want to be able to transfer the whole case to another entity within (e.g. a specific department) or outside (e.g. your supplier) your organization?


(i) Yes

(ii) No

(Iii) Other

Q4: If you are a respondent (e.g. a mobile shopping assistant) do you want to ask another entity within or outside your organization about certain aspects of the case?


(i) Yes

(ii) No

Iii Other

Q5: Do you want to add an enforcement mechanism?


(i) No(ii) Yes: by monitoring how parties implement outcomes of cases; or(iii) Other

(b) Selecting the Constellation

Based on the selected options above, it is possible to conclude that what is required is Simple negotiation.

Constellation:

(c) Specific questions in order to select or prepare Mask(s) of the Constellation:

Q1: When should user registration/sign-in be requested? Select from the following options:

(iv) Sign-in at the very beginning of the “filing a complaint” process(v) Sign-in at the very end (usually one step before completion) of the “filing a

complaint” process(vi) Other

Q2: In which business sector(s) will your ODR system operate (e.g. retail, healthcare, ...)? Select from the following options:

(i) Select from the available sector module(s) that you would like to include in your ODR project

(ii) Identify new module(s) that you would like to develop(iii) Other

Q3: Do you want to allow legal representatives that would represent either one or both of the parties to be included in your system?



Q4: Which languages will your ODR system use? Are there existing language localizations of the sector(s) you need? Or do you need to create a new language version for your sector module(s)?


(i) Select from available localization(s) of sector module(s) you would like to include in your ODR project

(ii) Identify new localization(s) that you would like to prepare(iii) Other

Q5: Will only one party be allowed to be a complainant (e.g. only a customer can file complaint against a retailer)? Or will only the other party be allowed to file complaints (e.g. only retailer can file complaint against customer)? Or either party can file a complaint against the other party?


(i) Only party A might file complaints(ii) Only party B might file complaints (iii) No restrictions regarding who might file complaints(iv) Other

Q6: Do you want to illustrate issues in the complaint by sounds or pictograms? Yes or no? If yes, which ones? Select from the following options:

(i) Pictograms/sounds yes(ii) Pictograms/sounds no(iii) Other

Q7: If you would like to use pictograms/sounds, select from the following options:

(i) Available pictograms/sounds(ii) Your own pictograms/sounds(iii) Other

Q8: How many levels of communication does the Complaint have?


(i) One(ii) Two(iii) Three(iv) Four

Q9: How many levels of communication does the Response have?


(i) One(ii) Two(iii) Three(iv) Four

Q10: If your ODR system includes complaints, who prepares the first proposals how to resolve the issues?


(i) Complainant in its complaint

(ii) Respondent in its first response to a complaint(iii) Other

Q11: Does the documents need to be filed only online, or will you allow also paper filings?


(i) Only online filings(ii) Both online and paper filings, according to the preferences of the users(iii) Other

Q12: If you allow paper filings, select from the following options:

(i) Paper filings will be manually converted into online forms(ii) Paper filings will be automatically converted into online forms(iii) Other

Q13: Do you want to allow one or both parties to get online advise from third parties (e.g. consumer organizations)?


(i) Free advice (for either party)(ii) Free or paid advise (for either party)(iii) Other

Q14: Do you want to add user review after the procedure ends?



(d) Describing the Mask(s) of the selected Constellation

This part shows different available variants of the Mask(s) of the intended ODR process depending on which options were selected in the specific questions above:

Constellation component: Dot; Id: 0061-1

Issue/Sub-issue Mask1. See 6.2.12. Attribution of roles to the parties

2.1 only role of a party filing the communication

2.2 only role of a party receiving the communication2.3 Multiple roles

3. Advisers to the parties as part of the platform

3.1 Free advisers to either party

3.2 Free or paid advisers to either party3.3 No advisers

Constellation component: Line; Id: 0061-2

Issue/Sub-issue Mask1. Complaint

A B1.1 Structure of communication

1.1.1 Structured

1.1.1.1 Number of levels: n1.1.1.2 Add new level 1.1.2 Non-structured

1.2 Language(s) See 5.2.1 above1.3 Pictograms/sounds 1.3.1 Pictograms yes

1.3.1.1 Select from available pictograms 1.3.1.2 Download your own pictogram(s) 1.3.1.3 Both1.3.2 Sounds yes – see 1.3.11.3.3 Pictograms no1.3.4 Sounds no1.3.5 Other: to be developed by the community

1.4 Advisers to the parties

1.4.1 Advisers yes

1.4.2 Advisers no1.5 Form of communication

1.5.1 digital only

1.5.2 digital or paper1.5.2.1 paper communication processed manually1.5.2.2 paper communication processed automatically1.5.2.3 Other: to be developed by the community1.5.3 automatic communication

1.6 Statuse(s) 1.6.1 No statuse 1.6.2 Add/Delete statuse 1.6.3 Change of statuse: new statuse


2. Response(See also 1 above)

A B 3. Goal: 3.1 Common goal exists

3.1.1 Goal=Reaching agreement3.1.2 Other goal3.2 Common goal does not exist3.3 Unilateral goal of the party exists

3.4 Unilateral goal of the party does not exist3.5 Other: to be developed by the community

4. Who first suggests contents of common goal

4.1 Party A

4.2 Party B4.3 Either party

5. Statistics See 007-1 above6. Possibilities to edit Related to screens not Mask7. Other (possibilities to


Constellation component: Triangle; Id: 0061-3

Issue/Sub-issue Mask1. Form of agreement

(goal)1.1 By exchange of communication

1.2 By formal document1.3 Other: to be developed by community

2. User reviews 2.1 User reviews of the online platform yes 2.2 User reviews of the online platforms no

3. Access See 6.2.1 above 4. Statistics See 6.2.1 above5. Statuse(s) See 6.2.1 above6. Screen(s) See 6.2.1 above7. Possibilities to edit Related to screens not Mask8. Other To be developed by the community

Constellation component: Artemo; Id: 0061-4; for issues and sub-issues, see 6.2.1 above.

white paper . doc - alternativeplatforms.files.wordpress.com · web viewcore digital...

Documents