What types of resources can be modelled as hmas:Workspace?

[andreiciortea]

I'm opening this issue to discuss the use of the term hmas:Workspace — and to regroup some of the discussions from f2f meetings and email conversations. Two questions that surfaced in the discussion of Issue #122 are:

• is an hmas:Workspace a subclass of hmas:Artifact?
• is an hmas:Workspace hostable (i.e., can it be hosted on an hmas:HypermediaMASPlatform)?

Long write-up, but I tried to keep it structured, concise, and self-contained. Concrete proposals for the core ontology and its usage are at the very end.

To open the discussion, consider the following examples:

• a factory building:
  • the factory building is a non-information resource that exists in the physical world
  • the factory building can contain agents (e.g., factory workers), industrial devices, tools, and the agents' activities
  • all this can be described in an hmas:ResourceProfile
• a workspace on Yggdrasil, which implements Agents & Artifacts (as part of the JaCaMo meta-model):
  • the workspace can contain Jason agents, CArtAgO artifacts, other workspaces, and the agents' activities
  • the workspace is implemented as an instance of the CArtAgO Workspace class; agents do not interact with the workspace directly: they interact with the workspace via an artifact, which is an instance of the CArtAgO WorkspaceArtifact class
  • both the workspace and the workspace artifact are hosted on Yggdrasil
  • the workspace artifact has an hmas:ResourceProfile that exposes hmas:Signifiers for interacting with the workspace, and links to hmas:ResourceProfiles of contained resources
• a container on JADE-hypermedia, which implements the FIPA Abstract Architecture (in the interpretation given by the JADE platform):
  • the container can contain JADE agents and their activities (e.g., interactions with other agents)
  • the container has an hmas:ResourceProfile that describes the container and links to hmas:ResourceProfiles of contained agents
• a Linked Data Platform (LDP) Container: the LDP Container is an LDP RDF Source, which is an LDP Resource whose state is fully represented in RDF (see also RDF Source); the LDP defines three types of containers:
  • LDP Basic Container: can only contain documents (i.e., information resources) and links to the contained documents via containment triples using ldp:contains as predicate
  • LDP Direct Container: in addition to containment triples with ldp:contains, it can use custom membership triples (e.g., a membership triple using foaf:knows as predicate), and can contain any resources (i.e., not only documents)
  • LDP Indirect Container: similar to an LDP Direct Container with the difference that the object of a membership triple can be derived from the content of a contained document
  • for example, if I post a foaf:PersonalProfileDocument to an LDP Indirect Container, the object of the membership triple can be derived from a triple with property foaf:primaryTopic contained within the profile document and identifying the person described by the profile document (e.g., <#andrei>); in contrast, if I am using an LDP Direct Container, the derived object of the membership triple would the profile document itself

From these examples:

• I generally understand an hmas:Workspace to refer to something else than a document, i.e. it is a non-information resource
• I see the factory building, an Yggdrasil workspace, or a JADE-hypermedia container as good examples of hmas:Workspace:
  • they contain agents and their activities; the factory building and the Yggdrasil workspace can also contain artifacts or other resources agents use in their activities
  • they are all examples of non-information resources that can be described by hmas:ResourceProfiles
• I understand an LDP Direct/Indirect Container to be closer to an hmas:ResourceProfile that describes an hmas:Workspace (rather than an actual hmas:Workspace)
  • both would use hmas:contains as the predicate of membership triples (in addition to containment triples using ldp:contains as predicate)
  • the containment and membership triples are managed by the LDP according to the W3C Recommendation
• we can use an LDP Basic Container to describe an hmas:Workspace but clients would have to manage the membership triples
  • this is an important point because, to the best of my knowledge, most existing implementations of Solid platforms use LDP Basic Containers (I might be wrong)
• the factory building is a physical entity and cannot be hosted on an hmas:HypermediaMASPlatform (but its hmas:ResourceProfile can be hosted)
• the Yggdrasil workspace and the JADE-hypermedia container are examples of workspaces that are hosted on an hmas:HypermediaMASPlatform
• conceptually, I understand an hmas:Workspace to be something different from an hmas:Artifact: the workspace contains agents and their activities, which may use artifacts and other resources
• I do not see a fundamental reason for requiring an hmas:Artifact similar to the workspace artifact in CArtAgO in order to allow agents to interact with an hmas:Workspace — but it might be useful in some cases
  • e.g., we currently use workspace artifacts on Yggdrasil because the implementation is based on CArtAgO

Concrete proposals for the core ontology and its usage:

• to make hmas:Workspace a subclass of hmas:Hostable; note here that hmas:Hostable is not just for documents / information resources (it already includes agents)
  • [later edit, I think I was rushing too much to wrap up the conclusions] if we consider the factory building to be an hmas:Workspace, then clearly we cannot define all workspaces to be hmas:Hostable (but some of them are, which we could model in various ways)
• to maintain that hmas:Workspace and hmas:Artifact are disjoint classes
• to maintain that hmas:Agent, hmas:Artifact, hmas:Workspace, and hmas:HypermediaMASPlatform generally refer to non-information resources described by hmas:ResourceProfiles
  • I would extend this point to hmas:Organization as well (cc @gnardin @oboissier)

[gnardin]

@andreiciortea

We (@oboissier and I) agree that hmas:Organization refers to a resource, i.e. the organization. Yet it describes the structural, functional, configuration, and normative aspects of the organization (I personally do not know if we can say it refers to a non-information resource). A hmas:ResourceProfile associated to the hmas:Organization would then describe and allow to expose through signifiers, the possible actions that can be performed by an agent in the organization. We envision that an hmas:Organization may have multiple hmas:ResourceProfiles that can be contained in the same or in multiple distinct hmas:Workspaces. This will allow hmas:Agents to interact with an hmas:Organization.

While hmas:Organizations are situated on hmas:Workspaces through hmas:Agents and hmas:Artifacts, they are contained in hmas:Workspaces through their hmas:ResourceProfiles.

[UPDATE ON May 25, 2023] Based on Issue #154, hmas:Organizations will be associated to one or multiple hmas:ResourceProfiles, but neither of them will be contained in hmas:Workspaces. They both will be accessible through the hmas:Agents and the hmas:Artifacts that situate the hmas:Organizations on the hmas:Workspaces.

[FabienGandon]

From the two comments so far I see only two concrete impacts on the core.ttl :

1. hmas:Workspace should be a subclass of hmas:Hostable
2. hmas:Workspace and hmas:Artifact should be disjoint classes

Did I miss an action?

[DrLeturc]

Need to be discussed during the plenary (5-10min)

[DrLeturc]

Consensus :

• We no longer have hmas:Hostable ;
• hmas:Workspace is disjoint from hmas:Artifact (need to implement that) ;
• All interactions on the web are in the context of a hmas:Workspace, all interactions happen in a context of hmas:workspace whether or not explicit as e.g. the web ;
• hmas:Workspace can be created or deleted by agent .

To Do :

• The definition of hmas:Workspace has to be updated and must be more abstract ;
• Revise : "A workspace can be a LDP container..." ;
• Add to the definition : "hmas:Workspace supports interaction" ;
• Add examples for TPAC (ldp and solid) ;
• We open a new issue to discuss about the link between ldp:container and a hmas:workspace which seem to be different terms ;
• Inria will make a proposal for a new definition for the hmas:Workspace .

[FabienGandon]

UPDATE FROM PLENARY 28/06/2023:

Definition at time of discussion: "A logical container of one or multiple interactions among agents and potentially artifacts. Workspaces can contain any resource in general and in particular agents, artifacts, other workspaces, or platforms. A workspace can be a LDP container and this can be done by multi-typing the container or by multiple inheritance on a Class ex:Workcontainer. "@en ;

Agreed sentences: "All interactions happen in the context a workspace whether or not it was explicitly reified." "Workspaces can be created or deleted by agents on a needed basis." "A workspace can be, for instance, implemented on top of an LDP indirect container."

Remove subclass and disjointness between Workspace and Artifact

Check the double use of owl:disjointWith and owl:AllDisjointClasses

[FabienGandon]

All changes are implemented in the latest Core.ttl