Open simongray opened 3 years ago
Thanks for the detailed report! We recently concluded a documentation push where we, among other things, tried to standardize the A/B vs X/Y things, but it seems like we've missed some. Similarly, we had issues with the description being the reverse of what they should be. It seems there is still a lot of work to do.
NP!
If I may make one suggestion it would be to always have a representation of the actual directionality somewhere in the entry, i.e.
A -> B
(... or whatever triple representation you favour) which makes it clear which part A
is referring to and which part B
is referring to.
Then you can flip this relationship for the entry describing the reverse relationship:
B -> A
and reuse the entity names so they still reflect the same entity types, that is: use them as backreferences. This would also allow you to reuse many of the written descriptions for the reverse relationships.
However, without a consistent codification of the relationships inside the entries, the descriptions are quite useless and it actually becomes very hard to spot the errors.
That's a good idea. Sometimes the directionality is confusing even when the wording is correct.
In general, when reading through the documentation, I am a bit uncertain what Concepts
A
andB
really refer to. I would expect ConceptA
to always be the first entity in an outgoing relationship with ConceptB
, such thatB
satisfies some attribute ofA
, i.e.However, in some cases this does not seem to be the case.
In certain cases,
A
andB
seems to be backreferences to similarly-named entitiesA
andB
in their opposite relation entries. The order of mention seems to be the thing to go by in those cases (i.e. the first mentioned entity is the first entity in the triple rather thanA
), but this is not consistent either.As a sidenote,
A
andB
are often randomly calledX
andY
throughout the documentation before going back to being calledA
andB
again. My intuition tells me to replaceX
withA
andY
withB
, but that introduces contradictions in certain places (see examples further down).Basically, the naming of the entities seems quite random and it makes using this resource as a source of truth for my work a bit hard. Right now I have to resort to deducing the intended usage from the published XML files of the English Wordnet instead. Hopefully, creating Github issues such as this one will help make the resource more consistent. It is still a wonderful piece of documentation, but it seems to need a little work.
Examples of what I find confusing:
Meronym
which is to be expected, but the definition further down is the exact same asMeronym
.Meronym
entry above which states that "Y makes up a part of X".Holonym
entry which states "X makes up a part of Y".Meronym
which states "Y makes up a part of X". The canonical example provided also contradicts the single example under the Examples heading, i.e. "player has member-meronym team" is the opposite direction of "fleet has member-meronym ship".Holonym
which states "X makes up a part of Y". Like withMember Meronym
, the canonical example provided also contradicts the single example under the Examples heading.Meronym
which states "Y makes up a part of X". Both examples seem to contradict the definition (opposite direction).Holonym
which states "X makes up a part of Y", although the description itself mentions the entities in opposite order which is a bit confusing. We could perhaps rewrite it as "concept A is a component of concept B" instead which is the same meaning, but unfortunately also the exact same description asPart Meronym
which is obviously contradictory.Meronym
which states "Y makes up a part of X". Furthermore, the canonical example and the example under the Examples heading seems contradictory (opposite directions).Portion Meronym
.Meronym
which states "Y makes up a part of X".Substance Meronym
(B is the substance in both cases).In general, the directionality of many of these relations seems to be opposite of the prior usages they are intending to subsume, e.g. in DanNet
has_holo_member
goes from member to group andhas_holo_madeof
goes from substance to whole, whilehas_mero_madeof
andhas_mero_member
go in the opposite direction. Some quick googling tells me that is also how these attributes have been used in other WordNets, see e.g. descriptions for the Estonian Wordnet.