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

"capabilities" in what I am looking at is a consequence of visibility /
read/write permissions of information. "capabilities" really implies
something like RPC in my book.

On Sun, 5 Mar 2023 at 23:49, Bob Wyman <bob@wyman.us> wrote:

> 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
>
>
>

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and Computer Scientist.