Re: Reconciling theory and in practice -- do the specs need updating?

Aaron,
I think it is well understood that adding to the @context is the method
that should be used to declare what vocabularies are being relied upon in a
chunk of JSON-LD. And, it is understood that an arbitrarily large number of
vocabularies could be referenced. However, while the generality of this
mechanism is useful, its use can create a mess. Recipients of a message
will often want to know more than just the message's syntax. They will want
to know what it means. If we rely too heavily on just listing vocabularies
in @context, we're likely to discover that several different groups have
defined their own vocabularies even though the scope of those vocabularies
overlaps, or may even be identical. The result will be potentially
avoidable complexity. Given this, it would be good to have a process where
at least those vocabularies of common interest can be jointly developed,
debated, understood, etc.

This is similar to a capabilities model

I think we're talking about different kinds of "capabilities." You seem to
be talking about "capabilities" as the ability to encode stuff in messages
(i.e. Things you can include in a chunk of JSON-LD.). However, another
meaning of "capabilities" is "some operation you are capable of doing;
because you have permission to do it" (e.g. Create, Update, Delete, etc.)

["https://www.w3.org/ns/activitystreams"] should only be offered up by the
> server or agent if and only if it supports the whole normative standard,
> otherwise a subset, superset, or intersecting set, OWL turtle spec should
> be offered up.


If there is an obligation to produce, serve, and use a "subset" vocabulary,
that means that we might find that many servers offer distinct subsets, and
many servers will have server-specific names for subsets also served by
others. Thus, unless there are a small number of servers, it is likely that
a message processor will often find it necessary to fetch a copy of a
server-specific vocabulary before processing a message. This would properly
irritate developers while also slowing down the processing of messages.
(There's already quite a lot of anti-LinkedData grumbling...)

My personal opinion is that it is best to define a set of vocabularies that
comprehensively address distinct application scopes with the hope that any
particular message will only use a minimal number of vocabularies. I would
prefer an "ActivityPub" vocabulary that addressed only very general needs,
basically just the data needed for CRUD (e.g. Create, Read, Update, Delete
of objects), and a "Social Vocabulary" that defined stuff like "like,"
"dislike," "Question," etc. that are common to social apps but don't appear
in all other application contexts.

bob wyman