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

On Sat, Mar 4, 2023 at 12:05 AM a <a@trwnh.com> wrote:

> > we should at least consider whether, after five years, the Activity
> specs are in need of clean-up, modification, or extension
>
> Yes, but we should also consider *why* any of these cleanups,
> modifications, or extensions are "need"ed, and for what purpose and what
> use-case.
>
> > The purpose of standards is to enable interoperation between
> independent implementations without the need to understand the
> peculiarities of individual implementations. Such
> implementation-independent interoperation is far from what we have in the
> SocialWeb today. The best we can say about implementations like Mastodon is
> that they are "inspired by" ActivityStreams/ActivityPub. That's not enough
> to ensure standards-based interoperation.
>

On Sat, 4 Mar 2023 at 18:25, Benjamin Goering <ben@bengo.co> wrote:

> > We might similarly refer to any other software's "conformance profile"
> as the set of requirements and expectations that must be maintained for
> interoperating with that software. The task, or challenge, is to then try
> and find commonalities and overlaps between these conformance profiles and
> see how many (or how few) distinct conceptual spaces you can collapse into.
>
> That is very well stated.
>

The Activity Streams specification already gives a way of describing
"capabilities", it is just no one uses it properly to my knowledge.
JSON-LD's @context 's give a totally flexible way of describing data, they
are what I term "meta descriptive", they give a syntactic level of
description using RDF or a semantic one using OWL 2.

{
  "@context": {
     "@vocab": "https://www.w3.org/ns/activitystreams",
     "ext": "https://canine-extension.example/terms/",
     "@language": "en"
  },
  "summary": "A note",
  "type": "Note",
  "content": "My dog has no nose.",
  "ext:nose": 0,
  "ext:smell": "terrible"
}

https://www.w3.org/TR/activitystreams-core/#jsonld

Also see :-

https://www.w3.org/TR/json-ld/#example-22-combining-external-and-local-contexts

And
    https://json-ld.org/contexts/person.jsonld

for another example.

ActivityStreams 2 itself is founded on an OWL description :-

    https://www.w3.org/ns/activitystreams-owl

I know URI's are URI's. But it would be lovely if on using the HTTP Accept
header on a GET we could get the turtle or RDF OWL Activity Streams spec,
rather than having to use a different path, as above.

    GET /ns/activitystreams HTTP/1.1
    Host: www.w3.org
    Accept: text/turtle

The main issues with this whole affair though is most people and
implementations are working on hard hand coded code that only work with
fixed meta data instances i.e. subsets, supersets, or intersecting protocol
sets. And not meta descriptive agent instances.

Being able to query a server using WebFinger and
/.well-known/activitystreams.json for a turtle RDF or OWL spec, to the very
minimum just the ActivityStreams 2 Standard URL :-

    GET /.well-known/activitystreams.json HTTP/1.1
    Host: www.example.org <http://www.w3.org/>
    Accept: application/json

Returning :-
    {
        "context": "https://www.w3.org/ns/activitystreams",
        "version": "2.0",
        "normative": "true"
    }

But this 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.

This is then just a matter of serving up a static file to be compliant for
the more versatile to be able to communicate with them.

This is similar to a capabilities model

The problem is people and implementations not adhering directly to the full
standard, I know you are allowed to implement the standard willy nilly in
part and add fields too.

Just my $0.02 cents on how to normalize standards compliance as far as I
see possible at this stage.

-- 
Aaron Gray

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