This is a simplified archive of the page at https://socialhub.activitypub.rocks/t/developers-meeting-7-a-standard-way-to-query-in-activitypub/2488/13
Meeting Minutes Super nice meeting, 7 people attended. In the beginning we talked about an Ontology for the Fediverse Repository and Pages at redaktor.github.io/vocab in 4 languages Then we came to the core topic of the meeting and checked out the available alternatives for querying which included • SPARQL inkl. json-rql • GraphQL • JSON-LD Framing Using JSON-LD Framing as a Query Language | david w barratt and we weighted the Pros and Cons. The common intent to use SPARQL was clear. I...
#8
What do people need to query that isn’t in the AP spec (or other community specs)?
Pops up nearly each day, so will ask the next.
Personally same things than e.g. in twitter
“posted before/after/between”
“posted from/to”
“only type=Image”
“context about Harold and Maude or Robert Frank”
etc.
I’m using SPARQL! rdf-pub is supporting SPARQL.
I’m struggeling with some issues in the moment and currently the auth server is down ;-(
But in principle you can query the public collection.
There is certainly still a lot to learn and, if necessary, to optimise.
From an authentication point of view, it will be exciting.
I’ll have to test that soon, but at the moment I’m still testing the public collection query.
The karte von morgen (kvm) adapter, that is doing a one way sync kvm → rdf-pub uses “hardcore” SPARQL to check, what entries are already in rdf-pub.
Hey planning to come.
I am currently stuck with fedigoup because
And I can’t seem to get a follow activety to work from Pleroma neither.
I am not sure if its a fastapi bug or something I am missing. If anyone could help me out that would be really helpful!
Since the meetup I did manage to deploy guppe groups and reproduce the issue with Pleroma. So we have now logs for that.
Super nice meeting, 7 people attended.
In the beginning we talked about an Ontology for the Fediverse
Repository and Pages at redaktor.github.io/vocab in 4 languages
Then we came to the core topic of the meeting and checked out the available alternatives for querying which included
• SPARQL inkl. json-rql
• GraphQL
• JSON-LD Framing Using JSON-LD Framing as a Query Language | david w barratt
and we weighted the Pros and Cons.
The common intent to use SPARQL was clear.
It took three hours until we had a final text.
So, all then remaining 4 people showed (yet) interest in the
Proposal
re. the Spec. section 4.1 Actor objects “The endpoints mapping MAY include the following properties:”
We specify a sparql property in the endpoints object of an Actor for querying the public collection of the AP instance you got the profile from.
Clients must set the content type as specified in the SPARQL specification (1) or to application/ld+json; profile=“ActivityStreams 2.0 Terms”.
In case of the latter this is expecting a query like
{
"id": "myID",
"type": ["Query"],
"@where" : {
"@type" : "Person",
"birthPlace" : { "name": { "@contains" : "London" } }
}
}
The properties for the type Query are defined in json-rql - v0.6.2 | json-rql - v0.6.2
I will inform others about the final proposal.
Notes apart from voting:
It was said that the querying language used (in this case json-rql as default) should be specified in the Query Object to allow for other JSON-based extensions (e.g. GraphQL).
Other Topics
Later steffen brought up another important topic and so;
We did also talked about fedi.camp and doing a Call for Participation.
The problem will be: Fedi Camp is a huge physical camping and the Internet connection is limited.
We will discuss solutions with other organisers like if we do 1 live streaming with 1 camera, 1 mic and 1 projector attached and everyone switches off mobiles. Or if we do async sessions like about Topics or AMAs.
So that developers and users from anywhere can come together.
Then I will write a CFP here.
—-
Thanks to anyone who attended, happy holidays anyone.
(boat by hamish)
I found this by accident today. I haven’t looked at it, but it seems to fit the topic and might be interesting for one or the other Introduction | Ontop
Hi all,
currently i’ve trouble with the idea in the proposal 
Because i’m not able to find out the public sparql endpoint, if i make a request with an anonymous user
I didn’t have an actor/profile to request.
See also: Standard for getting information about a ActivityPub Server
Fredy
Sorry, I do not understand “anonymous user”.
The “actor/profile” is the document where you find the sparql endpoint too.
It is the same document giving you the outbox/inbox/other endpoints.
In ActivityPub every user (Actor) MUST have outbox/inbox …
See #actor-objects
A not authenticated user.
If i didn’t know an actor on an instance, but want to query the public collection.
Ah, I see.
Well, this is not specified either anywhere. So I can only tell how it will work in redaktor:
Any instance in redaktor is itself a Group Actor.
This means if you ask the instance root URL it would deliver the ActivityStreams Actor representation in response to
application/ld+json; profile="https://www.w3.org/ns/activitystreams"
…
There you have sharedInbox.
Does that make sense in general or does a better way comes to anyones mind?
In my Opinion any instance should be reachable as an Actor anyway.
Then you can speak in the name of your instance and also do things like federated search.
PS: sorry for responding slowly, träwelling Deutsche Bahn much this week.
Hm, that an AP instance is an actor makes sence.
But in my opinion it’s more a application than a group.
Well, redaktor is itself an Application but a redaktor instance is
{"type": ["Group", "Service"]} –
Just updated the Vocabulary Ontology with the new skohub branch.
I will document semantics there next week.
We tossed that idea around for a while here and decided that we shouldn’t put any constraints on the instance actor. Some may wish to present as a Group, some as an Application or Service, possibly even an Organization, and some perhaps as a Person (e,g, the admin).
We do not provide anything like a “public collection” which enumerates the site members. I’m not opposed to the idea, however if it existed, it must conform to local privacy expectations so people can choose to be unlisted in the site collection and the site admin can choose not to provide it at all.
If a redaktor instance is not an application, what are the activities of a redaktor application ?
however, if we want to specify a location where application-instance-related features are to be found, then we would have to agree.
@macgirvin am I understanding you correctly? You mean that an actuator in itself is the wrong place for such application instance-related features?
In the zot6 and nomad protocols which I also develop, in fact we do place instance-related information in the root or site “actor record”, such as cryptographic methods which are supported by this site. My comment was only that we don’t really care what specific type of actor the site uses to present itself; as sometimes we are dealing with a site that is representative of an organization or group and sometimes as representative of a person or service or application. It seems silly and wrong to constrain it to be a specific type of actor which may or may not fit the underlying purpose and actual management structure of the site.
what i don’t really like about the actor is that there is no common type actor, but the base is as:object. therefore we can rather badly agree that the instance properties belong to a random actor. But we could introduce another actor “instance”, which has instance properties. anyone can then return any actor under a defined url, e.g. root, which is also of the type instance!
What we’ve been doing is to put a site actor at the root of the domain and the let the person/s running the site decide what else they want to do with it and how it will interact. Those aren’t our choices to make.
Agreed that it makes no sense to specify what Actor-type any groups or commons should be.
Also keep in mind that any Object can be an Actor in ActivityPub.
This is super important and it is used in various implementations where e.g. an Event can be an Actor too and send for example a reminder etc.
In the Ontology the Actor is just a skos:Concept (for most used Actor-types) but not an owl:Class [visually no bracket-icon] …
Maybe this is a bit more intuitive.
An alternative to constraints in types, we could simply propose special types for
Actor and Instance which could be used alongside the others.
I think there also is a common misconception between what machines and users must “understand” in ActivityPub.
This is why I asked Evan, the author of ActivityStreams if we could do a meeting or fedi.camp session because between AS and AP him and James Snell had nice discussions about how to describe potential actions to other machines.
This included also plain http workflows but scoped to ActivityPub:
Basically the other party only needs a resulting Action with a name and maybe an icon.
It can then present an according button under the Object with an inReplyTo-Action …
There is nothing to understand how this Activity “works”, it is just a special reply to send.