What can Platforms host ?

[maximelefrancois86]

What is the range of :hosts ?

https://github.com/HyperAgents/ns.hyperagents.org/blob/ac90ef8fd96c8fabc8f0c1f0ecf92956723b65df/src/core.ttl#L163-L166

Is it only :Artifact and :Agent ?

[FabienGandon]

Good question but I just wanted to note that ranges or domains are not compulsory in case we don't have an exact constraint here.

[DrLeturc]

Does it make any sense to host an artifact ?

[TO DO : we need to define and clarify :contains / :hosts / :hasWorkspace ?]

[DrLeturc]

There is ":hostsWorkspace a owl:ObjectProperty ; rdfs:subPropertyOf :hosts ;" So the range should be :Workspace and :Agent ?

[TO DO : what is the relation between a :Workspace and a :Platform ?]

[DrLeturc]

A distinction is made between :containsAgent and :containsArtifact. What about a :containsSubWorkspace?

Do we really need to explicit :containsX ?

[FabienGandon]

one radical option would be to have only one relation (eg. contains) instead of multiple (eg hosts, containsArtifact, etc.) and to use typing:

:aPlatform hmas:contains :aW1523, a:Machine4 . :aW1523 a hmas:Workspace . :aMachine4 a hmas:Artefact .

:aW1523 hmas:contains :Agent6 . :Agent6 a hmas:Agent .

[DrLeturc]

In order to see if we really need the hmas:host property, I propose to consider the following question, the answer will decide if we need it : Can a platform not host an agent that is contained in its workspace?

If the answer is "yes", then we need it.

Another similar question is : Can a platform hosts an agent which is not contained in its workspace ?

[DrLeturc]

Okay let's try something.

Let's consider that I'm in the officeWorkspace. A :connectedDevicePlatform allows me to control the temperature, the lights of the room, the panels, machines, etc. But I need to be hosted to have control on the artifacts inner the officeWorkspace. To be hosted, I need rights and since I'm a guest, I do not have the rights to be hosted by the platform.

What can we conclude ?

I'm contained in the officeWorkspace, but I cannot be hosted by the platform since I'm a guest and I do not have any login. Consequently, we need a distinction between hmas:host and hmas:contain.

Does that make any sense to say that I'm not contained in the Platform ? Well, it seems that containing and hosting do not describe the same things. We cannot say that I'm not contained in a platform since a platform can only host resources. A platform hosts workspaces and agents but does not contain anything. The semantics of these properties are indeed well different. So we cannot use only a "hmas:contain" property.

The definition of hmas:host property --> domain = Platforms, range = Workspaces U Agents (or range = Resources as it is actually the case). The actual definition lets possible to consider that an artifact may be hosted by a platform too ? Host should be only associated with "autonomous entity" capable of acting on artifacts/workspaces/agents ? But a workspace cannot be said to be autonomous..

[andreiciortea]

This relates to the discussion in Issue #6. As @FabienGandon suggested above, for now, I would not impose constraints on the range of :hosts (see also Issue #6).

On :hosts vs. :contains, there is indeed an intended distinction here:

• :hosts refers to an information resource or a process (e.g., agent) that is hosted on some :Platform; a hosting relation might have further implications, e.g. the usage of the hosted resource (or the usage of platform resources by the hosted resource) could be subject to terms of service or data licensing policies specific to the hosting platform
• :contains refers to a logical containment relation and is related to the definition of :Workspace as a logical container; here :Workspace is an environment abstraction inspired by the Agents & Artifacts meta-model

So this goes along the lines of the example given by @DrLeturc. In the end, I think the final distinction between :hosts and :contains will depend on the final definition of :Workspace, i.e. if we allow :Workspace to be a logical container that is hosted on some platform but can contain/regroup entities hosted across multiple platforms. For now, we use such "distributed workspaces" in our demos, so I would keep this distinction between :hosts and :contains.

I've updated the definitions for :Workspace, :hosts, and :isHostedBy.

[maximelefrancois86]

in #6 Andrei wrote:

so a :Platform could be hosted by another :Platform; good observation, I don't see a strong reason to exclude this possibility, but I also don't see the practical usefulness to represent such a hosting relation

• the initial intention was to use :Platform as a proxy for the concrete host(s), i.e. machine(s) accessible via a network, that provide a hosting service for any relevant resource in a Hypermedia MAS (i.e., an information resource or a process/service)
• here a :Platform could be an abstraction of a system that is controlled by one entity (so the system is centralized or appears centralized, but could in fact be a distributed system); examples include platforms such as Facebook, Twitter, or dweet.io, all of which provide services that could support hybrid communities to some extent
• aspects on centralization and control/governance are not currently captured in the :Platform definition from the core vocabulary

So should we also say that a platform can host other platforms ? +1 for this

[DrLeturc]

@maximelefrancois86 : i think yes, it should. Example : we can imagine that the Google WebPlatform hosts many subWebPlatforms gmail, googlemap, ...

[maximelefrancois86]

Pull Request #31 introduces the :Hostable class

[FabienGandon]

How much of this discussion goes away if we focus on hmas:MASPlatform as per issue #20 ?