ActivityStreams specification OWL and turtle documents

I found this one: (not easy to find, ask me why!)

But i miss the turtle file for ActivityStreams 2.0 Terms

Any idea ?
Thanks

ActivityPub is strictly built on JSON-LD. It is not valid to send Turtle or any other RDF serialization other than JSON-LD to an ActivityPub endpoint. Accordingly, ActivityPub vocabularies are only provided in JSON-LD format.

Ultimately, the OWL files were just something provided on a best-effort basis by one of the previous group members, and they’re not well-maintained. The specifications in question are still the normative reference for these properties.

ok, so i’ve to eat that: https://www.w3.org/ns/activitystreams :wink:
However, at the end there are triples. Even that is hided.
Thanks

Currently the specification appears to provide 0 machine-readable definitions that I can see. Providing an OWL would be a fantastic accelerant to anyone trying to get going with ActivityPub.

We should make this easy to work with. Right now it’s just a bunch of works on a page. This is un-ideal in extreme. Arguing that OWL files were often unmaintained is uninteresting to me. We can and should do better, and not argue on the side of worse is better.

2 Likes

I strongly agree.
Many people here have said so.
Full ack.

We can and should do better

I tried. OWL/RDFS/SKOS :
It is a Work in Progress but should cover in the end
• ActivityStreams / Activity Vocabulary
• ActivityPub properties
• ActivityStreams Extensions
• Extensions in the various namespaces of implementors
→ aka the fediverse in the end

WIP - Please tell me if something is missing
see asSkos.ttl (valid turtle file)

We can build JSON-LD contexts from it or build it with Skohub Vocabs or debate it etc.
It has multiple languages, more in the DB and should become a valid turtle file by today.

Arguing that OWL files were often unmaintained

We can also try to optimize. See the https://skohub.io approach.
When we can federate the single OWL/RDFS/SKOS/ActivityStreams definition then also the “OWL file” could be a Collection where everyone can publish their extension or vocabularies, define own Roles etc.

:thinking: Hi @Sebastian, i’m not sure, if this is the correct thread therefore. I didn’t get the goal of asSkos.ttl.

This is the activityStream definition in turtle, i’m using: vocabulary/src/main/resources/activitystreams-definitions.ttl · develop · naturzukunft / public / rdf / rdf4j-tools · GitLab

Fredy

Hey there,

the file started after the “towards AS3” discussion.
The goal is to collect

  • activityStreams2 (“ActivityVocabulary”)
  • as extensions
  • all the extensions used in the Fediverse in other namespaces (toot, litepub, peertube, mobilizon, lemmy, forgefed etc.)
  • the extensions which will be introduced by 2 proposals “inReplyToPolicy” and “Potential Actions attached to objects” [the second was in as once and is just an update for ActivityPub]
  • and the redaktor properties

And it is specified in SKOS for https://skohub.io in 4 languages and apart from the nice skohub site generator any term will have its own ActivityPub inbox (skohub builds the single JSON-LDs already) and the thing will be an as:Collection, so we can then also discuss towards as3 or update the vocabulary.

That said, the “public goal” is to have a place where you can browse or consume all the terms.
For me a secondary goal is that it has all the mappings (now currently finishing) like exactMatch or converters to humanreadable IPTC ( important for @redaktor.me ) but also mappings to
schema org, wikidata, Library Of Congress etc. (potential datasources, and I find the inventaire-idea to “give back” to wikidata very nice).

Does that mean it is a step before the RDF types are defined.

Fredy

Does that mean it is a step before the RDF types are defined.

Exactly. To have a base for a debate.
And when the types are defined, the definitions are updated by a script which
would put “domain”, “range”, “functional” in the human readable SKOS part.

I think, currently the fediverse becomes pretty fragmented in terms of extensions.
The Vocab-File already shows some duplicates or things which are just done different per implementation although it would be better to unite things (just as in the specifications).

And also it really helps to investigate the different vocabularies.
An example, I come from the world of “The International Press Telecommunications Council (IPTC)”,
which is rather describing society than product-based vocabs like schema org.
So, trying to come up with a base vocabulary which makes sense to the Fediverse (and not to google).
For example some things in schema org are fine but many are not.
We have a type “RealEstateListing” where you can describe and list your castles.
Unfortunately I doubt that many people in the fediverse own many castles and if they would, they would prefer centralisation and walled gardens. So it would make sense to have also a type “HospitalityListing” where you can describe couch-surfing or hospitality.
Etc.

So you want to build a fediverse vocabulary?
From my point of view, ActivityStreams is not the right place for something like a fediverse vocabulary.
I am also not sure if a fediverse vocabulary is a good idea. But I agree with you that coordination is worth a try. so the fediverse vocabulary could just be a list of types from other vocabularies that we want to use.

Well, it would be sad, if we do not use it.
Cause I think, yet all the things which were debated in the meetings made a lot of sense.
Also for preparing ActivityStreams version 3 (when Dr. Amy Guy got time).

And also the extensions which were specified make sense.
For example, if mobilizon has the address of a place where the event takes place, why should I hide it from my users … At least the 300.000 G+J subscribers enjoy the specified things. To put this into perspective:
If Social CG now specifies a way to query (e.g. outboxes) then people can (re. the example) also check which other events take place at the same address etc.

PS: The file is now in a repository: see asSkos.ttl (valid turtle file)
Currently there seems to be an issue with the spanish html pages when building but all Activity Inbox/Outbox creation seems be there.
We are working on this issue.

@Sebastian I don’t really understand your answer.
But i must also admit that i don’t know the story and wasn’t present at the auditions.
If we define types, it would be nice if they were compatible. I am not at all happy that Activity Vocabulary and Event - Schema.org Type are two different things. I mean RDF can do that better. But I’m an RDF beginner and I may be wrong here.

If we define types, it would be nice if they were compatible

But this is the goal of the project.
The original namespaces are all preserved, except for schema.org and wikidata.org which are aligned to ActivityStreams now (in terms of e.g. rdfs:range).
We tried to list any term which arrived in our inboxes and official extensions and also the documentation of the different projects.
Also thanks to everyone who contributed extensions or terms.

I am not at all happy that Activity Vocabulary and Event - Schema.org Type are two different things

Exactly.
If you look at the file: They are not. Either schema/as are unions or you have as Objects in the range for schema properties. Feel free to do Pull Requests to make it even better.

If we stick to the Events example, it also has a Controlled Vocabulary for the Type/Genre of the event.
And these CVs are the intersection of what different implementations intend to use (e.g. mobilizon, redaktor, g+j here). It has the list from the mobilizon issue and the types do not have to be schema.org.
Please note from a social viewpoint that schemaOrg is very commercial/product/business-focused and does not have Event types in a social context, like protests, rallies, auditorium, artisan markets, community gardening etc. pp.
But they are used in fediverse.

What might make it more clear and is much better to consume by humans:
Meanwhile we have built the SKOS part of the file in the repo to these html pages and JSON-LDs: