it’s possible to deliver to the Collection itself but impossible to deliver only to the Collection itself. the delivery algorithm as specified will attempt delivery to both the collection and its items, with no way to address only one or the other.
not sure why a collection would have to contain Activities, but at present i am inclined to agree that Collection is a poor representation for anything other than a literal set, like a JSON-LD array []. there’s a lot of things that don’t particularly make sense about the underlying model of Collections but the workaround would be to instead reify some class of entity that has a Collection associated with it, rather than saying it is the Collection. So for example in the social media use case, one might say that a Conversation exists and has posts, such that Conversation.posts is an OrderedCollection ordered in forward chronological order or whatever. In the case of Manyfold’s “book series”, it might make more sense to define a BookSeries type and then define a separate property that references some Collection – say something like BookSeries.books.
i think it’s gotta be contextual based on what you’re trying to do. for example before sending a Follow you probably need an inbox and you probably want to check for the presence of a followers collection. i don’t think the term “actor” really means anything special here, but given that this FEP asserts that “All Actor types should be followable”, it seems fair to assume that there is at least some focus on sending Follow activities? in which case i would say that followers is a strong indicator this might work, and the inbox you should POST that Follow to is either directly specified via inbox or otherwise you might recursively crawl upwards via attributedTo until you find something with an inbox. but this isn’t fully or clearly specified anywhere as is touched upon in “following non-actor objects” in Unresolved issues surrounding Follow activities
basically in other words it’s less interesting to ask “what is an actor” and more interesting to ask “what can be followed” and then by extension “how can we follow it”. if we say that you can follow anything with followers then the next question is where to send the Follow; we have two choices, either we stipulate that the inbox must be directly on that resource or otherwise we stipulate that we are expected to crawl up the ownership chain and that it is possible to Follow things further down the ownership chain. the caveat with the latter option is that we don’t have a clear concept of this “ownership chain”, it’s out-of-spec on how to spawn actors or more precisely “how to create an object that has a followers collection and that you can Follow”. this is the problem i think we should be trying to solve.
it might make sense to say that a Creator is also a Person but it doesn’t really make sense to say that a 3DModel is also a Person. nor does it particularly make sense to say that a 3DModel is a Group, Organization, Application, or Service. the restriction to Person/Group/Organization/Application/Service is an entirely arbitrary one, and i don’t think anyone should hard-limit Follow to only working on these 5 types, especially given that Follow’s side effects are defined in terms of the followers collection and not in terms of the mythical “Actor type”.
what is the difference between an as:Person and a foaf:Person or a vcard:Individual? what about as:Organization, foaf:Organization, vcard:Organization, org:Organization? “duplication” is only an issue when two terms mean exactly the same thing. this is of course a more general problem in knowledge modeling (identity equivalence) that is sometimes solved via using owl:sameAs, owl:equivalentClass, owl:equivalentProperty. but i think even more generally the issue is that the types are being given undue importance. ideally, each type is an interface that is being fulfilled. the notion of saying that something “is a” category or class, does not actually provide much useful information except to say “this thing exists in this categorical set”. taking that second example, the claim being made is that “Stanford Bunny is a 3DModel”, that “Stanford Bunny is included in the set of all 3DModels.” this on its own is not enough information to do anything useful. you would most likely be doing something with a property that a 3DModel might have. so why check the type? why not check for the property instead? you’re using the property either way, and the type-check serves only to make your code more fragile and less robust.