Hypotheses

We are proposing to build a system that enables a network of seamlessly and transparently inter-operable platforms. The application of the resulting technological artifact in the real world is the actual test of all the hypotheses that are implicitly or explicitly accepted by us in building the artifact.

The hypotheses are not necessarily ones we were able to state at the beginning of the design process - rather, they are the result of a search process, whereby the iterative work on an initial set of hypotheses leads to intermediate solutions, rejected and newly stated hypotheses. In so doing, we adhere to Hevner's framework of Design Science.

1. A generic infrastructure for the platform business is possible

2. A generic infrastructure for platforms needs to solve at least the following aspects:

   1. actors must be able to announce their intention to interact
   2. actors must be able to find one or more ways to have that interaction (search or matching)
   3. actors must be able to interact in some way - e.g. exchange information (directly or indirectly) or use each other's product/service

3. The following properties or functionalities present in many platforms are not mandatory.

   1. User profiles that are visible to others
   2. payment solution
   3. reputation system
   4. search among profiles (if profile matching is the norm)
   5. profile matching (if search is the basis)

4. It is appropriate to achieve de-centralization through a system of http servers and additional messaging infrastructure per server. It is not required to design the solution as a fully distributed system.

5. The adequate representation of an actor with respect to a concrete intention to interact is not the actor, but the intention itself (Need)

6. It is not required that the Actor controlling the Need be known to any other party.

7. It is appropriate to require that each Need and all its associated data be managed by exactly one of the servers.

8. Actors need to be able to establish a communication channel (Connection).

9. The adequate communication channel for managing the interaction of two agents is a bi-directional channel that allows message push.

10. Matching is an adequate alternative for search.

11. It is adequate to define matching as the suggestion of a communcation channel between two actors.

12. It is appropriate to collect received messages and serve them as elements of a collection.

13. It is appropriate to use LDP collections for serving any collections in the solution

14. It is appropriate that any Need can request a Connection to any other Need.

15. it is appropriate that a Connection request can be declined by the requested Need.

16. it is appropriate that a Connection can be closed at any time by any of the Needs.

17. it is required that an actor can close and lock a Connection at any time.

18. it is appropriate that an actor can re-open a closed, unlocked Connection at any time, but not a locked one.

19. it is appropriate that an actor can send any number of messages in a Connection.

20. It is appropriate for Connections to provide non-repudiation of the message history.

21. RDF is an appropriate information modeling framework for this work.

22. Linked data is an appropriate information publishing and retrieval method.

23. Linked data is appropriate for describing Needs and Connections.

24. Linked data is appropriate for formulating and sending (publishing) messages.

25. It is required that Need descriptions be unmodifiable.

26. It is required that Needs cannot be impersonated by anyone but their creator/owner.

27. It is not required that servers manage their data internally as RDF, but is desirable that all data objectively defining the system be available as linked data.

28. WebID is an appropriate technology for authenticating participants in the system.

29. It is not required that an actor use the same WebID for all Needs.

30. There is a conflict of interest between matching services and actors. Matching services profit from accessing all the information in the system, whereas actors have privacy and business interests to disclose little or no information.

31. The following access rules are appropriate:

    1. Access to Needs, Connections, and Messages is configurable through WebAccessControl.
    2. Needs are world-readable by default.
    3. The list of connections (linking to the 'remote Need') is world readable by default.
    4. Messages sent in a connection are private to the actors controlling the two Needs in question by default.