Closed Antoine-Zimmermann closed 2 years ago
hmas:transitivelyContains
should never be used and only hmas:directlyContains
can be used. The actual comments of hmas:transitivelyContains
says :
`rdfs:comment "A relation that refers to all logical containers in which a resource is contained. (Never instantiate this class)"@en ; `
It should be better explained in the definition of those properties and maybe it is not clear why we forbid to use hmas:transitivelyContains
.
Maybe we shoudl replace the current comments with :
rdfs:comment "A relation that refers to all logical containers in which a resource is contained. This class is used to get all indirect inclusion relations between workspaces and subworkspace. This relation should never be instantiated. "@en ;
Concerning using skos:broader/skos:broarderTransitive
, skos:broader
is not transitive but it entails skos:broarderTransitive
as the transitive property we want to obtain. We wanted that everything which is contained in its workspace A is transitivelyContained in all workspaces W where A is a subWorkspace of W. skos:broarder
allows to do that. So we could consider hmas:contains
as a subPropertyOf skos:broader
in order to specify that our contain relation is a particular relation where the domain is a hmas:Workspace
and the range is a rdf:resource. Furthermore, it would remove the temptation to use a hmas:transitivelyContains
if we remove this property from the ontology. skos:broarderTransitive
will be used to get all the deductions between the inclusion relations of workspaces.
This is linked to issue #39 and the possibility of declaring hmas:directlyContains
as Asymmetric
if we want to drop that checkpoint we can have hmas:contains/hmas:transitivelyContains
just like skos:broader/skos:broaderTransitive
.
@Antoine-Zimmermann : I believe we have to be ready for changes to happen: for instance at any time a user may want to change the inclusion order between two containers, introduce new ones, etc. but to me this just mean that at a given time the model must be coherent not that two versions of the model must be coherent.
@DrLeturc : I don't get the sentence "we could consider hmas:contains as a subClassOf skos:broader in order" these are properties and I wouldn't use SKOS here as we are not modelling concepts.
I meant to redefine skos:broader
in the context of hMAS with hmas:contains
by using rdfs:subPropertyOf
.
In the description of skos:broarder
:
A hierarchical link between two concepts indicates that one is in some way more general ("broader") than the other ("narrower").
Seeing a "super-workspace" as a kind of more general concept doesn't shock me e.g. a "super-workspace" isBroader (in some way) than a "sub-workspace" that is contained in, and which contains a subset of resources.
But can we say the same for the rdf:resources that are contained in a :workspace
e.g. using hmas:contains
from a hmas:Workspace
to hmas:Artifact
or hmas:Agent
? Mmmh.. maybe not.
Whenever
C1
containsC2
, it is not necessarily clear whetherC1 hmas:directlyContains C2
or not. So it could be tempting to usehmas:transitiveContains
every time to avoid trouble. Or, conversely, it can be tempting to usehmas:directlyContains
because one does not envision an intermediary subsystem. But not envisioning such relation does not mean there is none. After examining more carefully the situation, it may appear that there is after all an intermediate subsystem that strictly containsC2
and is strictly contained inC1
.Besides, there is an argument that this mimics
skos:broader
/skos:broaderTransitive
butskos:broader
does not imply "directly broader". We can simply havehmas:contains
andhmas:transitivelyContains
, with the subproperty relation between the two.