not duplicating the same difference in properties and classes and ranges/domains

[FabienGandon]

for a property like "host" it is enough to use the range to know if we are talking about an Agent or a Workspace, we don't need hostAgent or hostWorkspace

[maximelefrancois86]

So would you use two different schema:rangeIncludes ? or would the rdfs:range be the union of Agent and Workspace ?

[FabienGandon]

I would stick to W3C semantics for now so rdfs:range be the union of Agent and Workspace ?

[andreiciortea]

In the Nov 29 meeting, we agreed to remove the :hostsAgent and :hostsWorkspace properties, so I will remove them from the core vocab.

I do not see a reason to impose strong formal constraints on the range of :hosts: in addition to agents and workspaces, a :Platform could host any Web resource specific to a type of MAS or to an application domain.

However, if we need to impose formal constraints on the range of :hosts, I would go with schema:rangeIncludes to relax the formal constraints (it specifies expected types from an open set: https://schema.org/rangeIncludes).

@FabienGandon @maximelefrancois86 what are your thoughts?

[FabienGandon]

Just to understand why use schema:rangeIncludes instead of rdfs:range? or an OWL Union as a range if you need union? moving to schema:rangeIncludes means we are no longer compatible with classical RDFS/OWL reasoners. More at https://link.springer.com/chapter/10.1007/978-3-319-11964-9_17

[andreiciortea]

@FabienGandon well, I'm just looking for a solution that would allow us to model the range of :hosts as an open set — and any solution would work, including not imposing formal constraints on the range of :hosts.

On schema:rangeIncludes vs. rdfs:range, it just seemed to me that the former would be more convenient to model an open set, but I have no practical experience here (and I was not aware of the incompatibility with classical RDFS/OWL reasoners). For instance, if we say:

:hosts a owl:ObjectProperty ;
           rdfs:range [ a owl:Class ;
                         owl:unionOf ( :Agent
                                       :Workspace
                                     )
                       ] ;

Would this exclude an object that is a foaf:PersonalProfileDocument?

[FabienGandon]

other options would be to keep it fully open like this

:hosts a owl:ObjectProperty ;
           rdfs:range rdfs:Resource .

or using super classes like (quick and dirty example)

:hosts a owl:ObjectProperty ;
           rdfs:range  :Hostable .

:Agent rdfs:subClassOf :Hostable .
:Workspace rdfs:subClassOf :Hostable .

[DrLeturc]

Current definition of "hmas:hosts" : "A relation between a platform and a resource hosted by the platform. Resources may include information resources or processes (e.g., a software agent)."

The meaning of "to be hosted" according to the Cambridge dictionnary :
"to provide the computer hardware and software that allows a website to exist on the internet"
(https://dictionary.cambridge.org/fr/dictionnaire/anglais/hosted)

First, should we agree with these definitions ?
If yes, then everything on the web is possibly a "hostable" resource by considering these definitions.
Thus it does not need any restriction and the first proposition of Fabien holds.

While the first proposition of Fabien is more general, the second one brings the question of "what is exactly something hostable?". Thus, what is your definition of "to be hostable" ? (A rdfs:resource ?)
What is the main reason to restrict the definition to only "hostable" resources?
What does this restriction bring to ontology? I don't see.

Other question, by considering the second proposition :
Is a :platform "hostable" ? I guess so.

[andreiciortea]

@DrLeturc some quick thoughts on my side:

• on the 1st question: +1 for the definition and for the first option proposed by @FabienGandon
  • just one remark to align on the breadth of the definition for :hosts: I would keep the textual definition broad, i.e. not only for websites; e.g., we could have an artificial agent bob who is an :Agent and exists in the form of a process that is running/hosted on some :Platform named platform1; bob could be described by a :ResourceProfile, which is an information resource hosted by some :Platform named platform2
• on the 2nd question: 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

@DrLeturc a suggestion following up from the last points: we could open an issue to refine/agree on the definition of :Platform. We should also discuss how centralization/decentralization and governance come into this definition — and if :Platform is the best name for this concept. How I currently understand the term, examples of :Plaforms would include Facebook, Inrupt, a community-hosted SOLID platform, or a SOLID data pod hosted by some individual.

[andreiciortea]

PS: instead of opening a new issue, we could also move this discussion to Issue #8: "What can Platforms host ?". If so, we could close this issue just to keep things tidy, the initial point raised by this issue was addressed: :hostsAgent and :hostsWorkspace are no longer in the core vocab.

[maximelefrancois86]

+1 for introducing :Hostable as the range of :hosts. I create issue #23 then to discuss if there are things in the hmas ontology that cannot be hosted:

For example: can a :Signifier be hosted ? can a :ResourceProfile be hosted? by a platform ?

[DrLeturc]

@maximelefrancois86 : I see :Signifier and :ResourceProfile classes as manuals for using a resource.
:ResourceProfile are the books, and :Signifier some pages that may belong to a :ResourceProfile. A book is not necessarily hostable by a platform when it is physically contained in a :PhysicalWorkspace. This manual has to be digitized to be :Hostable.

I think if we really want to build general hMAS-platforms, we really need to make such distinctions between what is :Hostable and what is not.