Back

The initial idea is that the wiki hosts are ActivityPub Actors who guarantee the common resolution of knowledge per signature.

These Actors should optimally reside under any tld other than these under the control of a fascist regime and/or Elmo.
[I gave up looking after alternatives to DNS and in general am thankful for any remarks]
So, let's say there is a redundant EU node and it guarantees the same trust just by the signature for ActivityPub.

We know that the specs are somewhat fragmented and some portions are underspecified, that will not hinder us.
I'll try to use the specs. in the correct order after http, JSON-LD core and syntax.
Currently I am trying to do a database model for deno kv which is performant and can directly answer what, when, where to fedi,
then I'll put all in a cleaned up repository.
For now a preview of code can be found in
wikidata to as https://gist.github.com/sebilasse/670f0a5821d12bd36a0d68eab2fc85b0 and generic functions in https://gist.github.com/sebilasse/b5370e2123145539598137c53ffb49a3

2/10

@skyfaller

https://www.w3.org/TR/activitystreams-core/
describing the multilanguage use, the Accept-Language header was somehow missing which resulted in some "primers" after the spec.
could not be changed anymore.
In short: In http it indicates the natural language and locale that the client prefers.
In ActivityPub we can extend it cause any client knows which language the user is able to speak [or is interested in, which could also be used for translate APIs]. The client sends the header, the ActivityPub server can answer with the values from the ...Map
wikidata has a few more "language maps", e.g. `Also known as` (alternativeNameMap) or "short name" (shortNameMap)
[ though it is questionable if this should not go as well to the tag: for example [{"@language": [...], "type": ["Hashtag, "wd:Property/P1813"], }] ]
The same spec. mentions how to deal with the Data Model and Core Types.
The Collection section could have some more examples.

3/10

A Collection can e.g. come from a wikidata SPARQL result or a wiki lists or e.g. our Service Actors.
It will all boil down to 1 Link.
As an example (see Client To Server and the Conformance Section of AP), the client taxiteam can organise all the Places from wikidata in an administrative-hierarchical Collection.
But any Place with a location has a geohash in our db too

[let's stick to example Hamburg in all following text].
This means, the Place can link to e.g. their (physical) children [enhanced with OSM down to buildings], parents,
contains, neighbours, neighbourhood, siblings, findNearestAddress, findNearbyWikipedia etc.
So if {"items": ["Q1055"]} is in the Collection of "Q183" (as federal state), the same id can occur in the items for e.g.
neighbours of Q3928. The Object lives independently and so does their Activities.
If the 'Place' is also an Actor (see below), these links and rels are in streams, otherwise in url.
Basic extensibility is defined in the same spec.

4/10

https://www.w3.org/TR/activitystreams-vocabulary which defines the Vocabulary.
"Conformance" just requires the server to support all of these.
It becomes clear that anything is complety versioned as we must be able to Undo or Undo/Undo anything.
This is why I am currently developping a consistent database model with atomic transactions which does deduplication, text diffing etc.

What would go where (apart from name, summary, content i18n-texts)?

- "instance of" to `type` [as alias of @type]
- "part of" to `partOf`
- "image" to `image` [same for maps, together witht the relation like e.g. "nighttime view"]
- "icon", "small logo or icon" to `icon` [same for flag, coat of arms etc. as above]
- "video", "audio" to `attachment`
- "native label" to the reserved `und` value of the nameMap
- "pronunciation audio" either to attachment (also with rel) or to attachment of the qualified statement, see. e.g official name
- "member of" like partOf for the parent collections

5/10

- "contains the administrative territorial entity" - children collection
- "shares border with" - neighbours collection …
- "elevation above sea level" to `altitude`
- "twinned administrative body" is a foaf relation as recommended per spec.
- "official website" and other URL to `url`
- Things like "country": The current here is the parent as described above, the others are marked by a 'Historical' top type or can become its own collection. [NB we have also top types for Factual (anything here) or Fictional (fairytales, unicorns and fedimagic)]
- Things like geoshape or geojson result in a preferably geojson `attachment`

- A few like "highest point", "head of government" have no according as: property.
We can extend them JSON-LD like as for example `wd:P6`
Then there are some `functional` properties like a Number or Quantity.
ActivityPub just has very few functional properties, so we did already extend our JSON-LD @context with the wikidata ones. E.g. "population" (history, s above).

6/10

So, we can go from type and datatype to `as:` (hope you get an idea).
See the linked gist for how the qualified statements are formed, for example a "speed limit" (or Infinity) valid for "Autobahn".

https://www.w3.org/TR/activitypub/ for the main spec. and workflow

The `id` property of any item can be used versatile in Fedi.
Let's say, you write an Article about Gentrification in Hamburg and you have
{"type": ["Article", "Profile"], "describes":"wd:Q1055", ...yourContent} you can show all according wikilinks as in the gif-video which is attached.
The same way proposals for Updates can be made.
Or as another ex., if you `Offer` a {"type": ["Object", "schema:Product", "Profile"], "describes":"wd:Q19599600", ...yourContent} you can show a commons photo of the hammer drill as „symbol picture“ if no other found.

The `id` can serve as a `context` where people are talking about or acting on/in Hamburg.
And form own Conversation Containers grouping these things.

7/10

This can make hashtags also well described cause maybe 200 things called "Hamburg" exist on Q2

The `id` can serve in all thinkable relations of other Links, Objects or Collections.

About the `Service` actor "wikidata.org" there is nothing super special.
It should have defined replyTo Actions for well-defined things like the edit-workflow.
It's signature is like the signature of Superman, Karlsson and Lisa Simpson alltogether guaranteeing trust.
It is receiving drafts in the inbox and federating the according update through its outbox.
It is announcing other `endpoints` and extending `streams`.
Particular Activities are described in this spec. in depth mentioning their side-effects.
When we have 1 generalized, well standardised server-concept (doing a reference in deno), it will become easy to build _Clients_

In AP mutiple actors do multiple actions to multiple objects.
In case the item is not locked, the `actors` have the `Public`, otherwise the according Collection of contributors.

8/10

Then we now who can update the "Discussion"/"Commits" conversation containers for the item.
wiki Actor can then merge approved items in atomic commits and e.g. send the Update to anyone following the item.
wiki Actor is responsible for these permissions.

So, if anyone wants to make an edit, the client produces a new draft.
What is helpful: If the Object and Activity ids are internally ulids, then we can use it for complete time based ordering and as full version control. The Activity id can be the "version" of the Object id.

Together with the Activities (which only "Extends: Object") all the meta for the discussion/commit is submitted while its .object has e.g. the "Partial Update".
For the Updates we internally use JSON Patch and Text Diff for minimal size.
For deduplication we use e.g. Content Hash, Nilsimsa text similarity with a numeric sort index and simhash for Images and destructuring/normalization for URLs etc. pp.
Will send that part to Hong in some days, can put you in cc.

9/10