remove informative appendix on reification, etc.

[pfps]

Fixes #85

---

Preview | Diff

[doerthe]

I agree with the change but we should combine it with an issue somewhere else to make sure that the informal part of the appendix is explained somewhere. Or is that already the case?

[niklasl]

I'm not sure we agreed to remove all of the appendices, but i don't mind moving them; possibly to different places.

On the call of 2025-02-28 we talked about whether/what to move. Some notes:

• The Primer shouldn't mention legacy things or go much into advanced practice, so it's not very suitable.
• If moved, we don't necessarily need to have links from Semantics, since these are "forever" in 1.1 Semantics.
• The section in Semantics sort of served to mention that while these terms exist in the RDF vocabulary, they don't have a formal semantics...

I tentatively suggest:

• Collections (i.e. lists) have syntax in all W3C RDF formats, and are extensively used, including in OWL. That could go into concepts. An alternative is to add it to RDF Schema, and reference it from concepts.
• Containers are reasonably legacy/archaic (some users might disagree). Perhaps it can be moved to an appendix of RDF Schema, with some "soft" deprecation language (in favour of collections)?
• The classic reification section could go into the Note I have an action to draft.

[TallTed]

    <p>There is no way in RDF to assert
      that a container contains only a fixed number of members. This is a
      reflection of the fact that it is always consistent to add a triple
      to a graph asserting a membership property of any container. And
      finally, there is no built-in assumption that an RDF container has
      only finitely many members.</p>

This is an important difference between containers and collections. To my mind it is sufficient reason to have both, and not treat either as "legacy/archaic". They are different constructs, and both have reasons to exist, or they would not both have been specified in the first place.

    <p>Also, RDF imposes no 'well-formedness' conditions on the use of this
      vocabulary, so that it is possible to write RDF graphs which assert
      the existence of highly peculiar objects such as lists with forked
      or non-list tails, or multiple heads:</p>
[...]
    <p>It is also possible to write a set of triples which under-specify a collection
      by failing to specify its <code>rdf:rest</code> property value.</p>

I do think there might be a way to specify a hybrid construct which supports both the infinitely expandable nature of a container and the forkable collection (which forking does mean that there may not be an rdf:nil on every branch, potentially making an infinitely expandable collection). Such a hybrid contruct could replace both these existing constructs, but the existing constructs MUST be supported for some indefinite (perhaps perpetual) period even if they're being deprecated, because we have no way of knowing how much data exists with these "legacy/archaic"/deprecated constructs.

[niklasl]

I was surprised to see this merged without any approvals. IIRC, there where some thoughts from @pchampin regarding if all could be removed/moved? In any case, we need follow-up issues to put (some of) this somewhere else. See my suggested destinations above.

[franconi]

I was surprised to see this merged without any approvals. IIRC, there where some thoughts from @pchampin regarding if all could be removed/moved? In any case, we need follow-up issues to put (some of) this somewhere else. See my suggested destinations above.

Yes, I guess this was a mistake from my part. I thought that the PR was implementing the deletion only of the reification part.