Property under tag

ActivityPub
1

Morning all.

This is more of a thought than a finished idea. I might turn it into a more formal FEP at one point. Basically, a standard problem when organizing data is that one adds flags for all kinds of stuff. This is fine when one starts, but degrades quickly as one needs to be careful of what flag means what, what is the syntax of the flag, and so on …

For example fep/fep-5624.md at main - fep - Codeberg.org introduces a toot:canReply flag. We already have an as:sensitive flag, that changes the meaning of summary. We might see an toot:discoverable flag on posts to decide if a post can be indexed, and so on …

A different approach would be to collect these things under tag, e.g.

tag: [
  { 
     "type": "Property", 
     "name": "sensitive", 
     "summary": "content contains partial nudity",
     "value": "nsfw"
  },
  {
    "type": "Property",
    "name": "canReply",
    "value": "followers"
  }
]

Not sure if this is the format I want, but it would look something like it.

Thoughts?

2

I’m certainly no rdf expert, but this doesn’t really sound rdf compliant to me

1 Like
3

I’m curious. Which aspect of it doesn’t seem compliant with RDF?

4

I don’t really understand what a flag is. In the example it is an [array of] tags.
Tags are keywords without context, so actually without meaning.
I never really understood the meaning behind tags :wink: So I welcome the idea of giving tags a meaning.

In the example was named:

{
    "type": "Property",
    "name": "canReply",
    "value": "followers"
  }

For me, that had a resemblance to a triple.
But you also gave a more complex example:

{ 
     "type": "Property", 
     "name": "sensitive", 
     "summary": "content contains partial nudity",
     "value": "nsfw"
}

No question, this can be mapped technically well with RDF.
Is then in my opinion a categorization of things (rdf:Type).
And that would be more elegantly mapped with SKOS Simple Knowledge Organization System - home page ?

But you are right. The statement “not rdf compliant” was syntactically incorrect.

5

Does the owl for ‘canReply’ maybe looks like that?

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix : <http://joinmastodon.org/ns#>.
 
:canReply
    a rdf:Property;
    rdfs:comment "Array of actors, that are able to reply to an xyz";    
    rdfs:label "canReply".

And for sensitive maybe like this:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix : <http://toBeDefined.org/ns#>.
sensitive: 
	a rdf:Property;
	rdfs:label "sensitive"
	rdfs:comment "content contains partial nudity";

or like that :wink:

tag: 
	a rdf:Property;
	rdfs:label "tag"
	rdfs:comment "property with different meanings";

but as i said, i’m still learning rdf and can be completely wrong.

6

I agree that this can be a risk. However, I don’t see how putting these in the tags collection will help with that. The AS2 spec describes a “tag” as an Object with an implied association by reference. Even with that loose definition, it doesn’t appear to be a good match for some of the kinds of data you are thinking of putting there.

Given the lack of a formal ontology for AP/AS2, written documentation is the likely alternative for defining flag meaning and syntax.

7

This is a problem. But instead of a “written documentation”, why not a formal ontology ? A “written documentation” will never be as accurate as a formal ontology. And therefore there will always be misunderstandings.

8

I’m all for it. I updated the old unofficial AP/AS2 OWL ontology and even included a Mastodon toot ontology. However, I don’t see the community making something like this official any time soon.

steve-bate/activitypub-ontology: An unofficial and experimental OWL ontology for ActivityPub, ActivityStreams 2 and Mastodon. (github.com)

2 Likes
9

so then everyone has his own :slight_smile:

It’s based on a version of @pukkamustard

I don’t see the community making something like this official any time soon

thats a schame, but i’ve the same feeling.

1 Like
10

I’m fine with using another term, e.g. “properties”.

@naturzukunft Not sure what you are exactly trying to say with your code snippets. All I can provide is what n-quads will look like, I hope it helps.

So json-ld

{
  "@context": ["https://www.w3.org/ns/activitystreams",{"Property": "https://property.example/bestdefinition"}],
  "type": "Image",
  "summary": "Picture of Sally",
  "url": "http://example.org/sally.jpg",
  "tag": [
  { 
     "type": "Property", 
     "name": "sensitive", 
     "summary": "content contains partial nudity",
     "value": "nsfw"
  },
  {
    "type": "Property",
    "name": "canReply",
    "value": "followers"
  }
  ]}

gets turned into the following n-quads according to the json-ld playground

_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/activitystreams#Image> .
_:b0 <https://www.w3.org/ns/activitystreams#summary> "Picture of Sally" .
_:b0 <https://www.w3.org/ns/activitystreams#tag> _:b1 .
_:b0 <https://www.w3.org/ns/activitystreams#tag> _:b3 .
_:b0 <https://www.w3.org/ns/activitystreams#url> <http://example.org/sally.jpg> .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://property.example/bestdefinition> .
_:b1 <https://www.w3.org/ns/activitystreams#name> "sensitive" .
_:b1 <https://www.w3.org/ns/activitystreams#summary> "content contains partial nudity" .
_:b3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://property.example/bestdefinition> .
_:b3 <https://www.w3.org/ns/activitystreams#name> "canReply" .
11

In my eyes, this is a definition of Properties, that should be in a meta layer.

12

I don’t see much benefit in lumping these together into a collection of semantically unrelated things (doesn’t matter if they are called tags or properties or things).

In general, I don’t have a problem with these being top-level fields in the Object if there’s not a meaningful grouping.

13

5 years ago I made this that fetches the activitystreams2 spec html, parses out the class/property definitions, and then represents them as an OWL ontology instead.

If you have npm, you can print it to stdout using npx activitystreams2-spec-scraped

If you just want to see the output rq, I included a sampleoutput here.

Then I made this to re-render the owl into html again

1 Like
14

The TR has always had this non-normative ontology definition section: Activity Vocabulary

which links to https://www.w3.org/ns/activitystreams-owl

15

Yes, I started by trying to use that one but it’s broken in ways that made it useless for my purposes. I don’t remember the details but it didn’t load into Protégé or the OWL library I was using. If I remember correctly, it was also not completely consistent with the informal ontology in the specification. The ontology in my repo is based on that one, with fixes and adding the Mastodon toot ontology.

16

Have you documented any evidence wrt to the claim that it is “broken”?

(sent while mobile)

17

I have not. At least not detailed evidence. There are some high-level issues described in my repo README. The original ontology was abandoned in 2016. Does anyone claim it’s not broken?

I was curious why you scraped the spec web page instead of using that 2016 ontology for your project.

18

ok. weekly Evan has been leading session going through issues on the activitystreams and activitypub issue trackers, so if you believe it is broken, one way of verifying that hypothesis would be to seek peer review by filing an issue there.

I was curious why you scraped the spec web page instead of using that 2016 ontology for your project.

for fun

19

See also…

We should create a new topic if you want to discuss it further.

1 Like
20

what’s the point of doing this? it seems like it would just provide an unnecessary level of nesting while also violating the meaning of tag. if you want to define a property then define an actual property and put it on the graph node.