Open pascalfleury opened 1 week ago
As the person that implemented most of the code around extension vocabularies, this makes a lot of sense to me.
There were initial ambitions for the extension vocabularies mechanism, for which it made sense at the time to utilise schema.org to describe itself as much as possible. Those ambitions never really materialised, with currently the mechanism now primarily only being used to identify pending terms.
As you say, such a move would entail some changes to the generation tools. If you can justify the effort I would say go for it.
Having worked on that area of the code in the past, I would suggest you add a little extra contingency to your estimates to allow for diagnosing unexpected knock on consequences.
~Richard
I have a concern here. I'm not sure there is any real confusion between use cases 1 and 2 mentioned by the OP. In one case the thing being descried is a portion of a work or a work which is also a part of another work. In the other case the thing being described (schema portion) is part of a larger schema. Both are semantically valid for their contexts. I fail to see the challenge in the appropriate application of the term. It is not two different semantics or meanings rather two different contexts with the same semantics or meanings.
Is it not the case that http://schema.org/isPartOf is canonically equivalent to http://purl.org/dc/terms/isPartOf (https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/isPartOf) ? As a casual reader of schema.org and an oft user of Dublin Core I would expect these to have a canonical equivalence.
If this change is carried forward as the OP describes. Then please also be sure to address the inverse relationship hasPart
as well.
In the schema.org model,
http://schema.org/isPartOf
is used for two distinct meanings:It would make tooling easier if there was a mechanical way to distinguish these two. The proposal is to continue using the current representation for meaning #1, and simply use Dublin Core's
isPartOf
for the schema's internal structure.This would entail changing a bit the generation tools to ensure this distinction when deploying and releasing a new version.