Adrian Cochrane @alcinnz@floss.social

in addition to N-Triples, RDF/XML, and Turtle,

JSON-LD — that thing ActivityPub and Mastodon are using right this second — is actually a kind of rdf format.

a (simplified) toot in json-ld:

{
"id": "https://floss.social/users/Valenoern/statuses/example/activity",
"type": "Create",
"actor": "https://floss.social/users/Valenoern",
"published": "2021-03-05T04:24:47Z",
"to": [ "https://www.w3.org/ns/activitystreams#Public" ],
"object": {
"type": "Note",
"url": "https://floss.social/@Valenoern/example",
"atomUri": "https://floss.social/users/Valenoern/statuses/example",
"conversation": "tag:mastodon.social,2021-03-05:objectId=testconvo:objectType=Conversation",
"content": "wow a toot"
}
}

a toot in rdf/xml:

<Activity>
<id>https://floss.social/users/Valenoern/statuses/example/activity</id>
<type>Create</type>
<actor>https://floss.social/users/Valenoern</actor>
<published>2021-03-05T04:24:47Z</published>
<to>https://www.w3.org/ns/activitystreams#Public</to>
<object>
<type>Note</type>
<url>https://floss.social/@Valenoern/example</url>
<o:atomUri>https://floss.social/users/Valenoern/statuses/example</o:atomUri>
<o:conversation>tag:mastodon.social,2021-03-05:objectId=testconvo:objectType=Conversation</o:conversation>
<content>wow a toot</content>
</object>
</Activity>

(this is critically supposed to have namespace info around it that absolutely wouldn't fit in a toot body:)

<?xml version="1.0"?>
<rdf:RDF xmlns="https://www.w3.org/ns/activitystreams" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:o="http://ostatus.org#">

<Activity>...</Activity>

</rdf:RDF>

I jokingly/tentatively call this technique "OWL wings" because I like the imagery of term definitions as "wings" extending off the body of something,
or the notion of taking a data object and arbitrarily sticking several wings on it to turn it into some kind of terrifying many-winged angel thing

particularly when the data objects are in "Turtle" format it sounds like this has turned into mario or something.

It seemed like the surprising answer was..... there wasn't.

rdfs/owl/etc existed, but all the documentation about absolutely anything anywhere was just like 'these are all really broad ideas, you can make whatever you want'.
(which of course wasn't very helpful to me because I wanted to make something /specific/ and was hoping there would be a standard for it.)

eventually I just started messing with the idea of defining the technique myself and hoping there wasn't already a better version.

within rdf, there are RDFS (rdf schema), OWL (web ontology language), SHACL (shape constraint language) and others.
there are quite a few options

but one thing that confused me a lot is why prefixes — namespaces that distinguish similar property names put into "sentences" — don't immediately lead to machine-readable information about their terms,

and if there was a standard way to offload a handful of prefixes referenced at the top of an rdf file into a "prefix stylesheet" and import just one

researching what kind of formats are already used to store citations,
I eventually started learning about rdf.

at its core, rdf is just a bunch of simple "sentences" (triples) drawing a particular kind of arrow from one thing to another thing:

:rdf a :format .

however there are many methods built on top of this to make the "sentences" actually mean something, usually through more "sentences" that connect particular "words" to their qualities.

I first tried to imagine how I would store data for something like a bibliographic citation, to render out into some particular style a bit like bibtex.

one of the motivations for bopwiki is the idea of creating a 'miniature library' documenting different information sources, perhaps for the far future when it's hard to find some particular source on a web search.
like a card catalogue

so, being able to store a list of citation properties in a bop entry is a natural place to go

this is one of those times where I have no idea if anything I'm saying has enough context to make sense to anyone outside my head

but, short version:

```
This is a bop entry

=> example.com an external link
<= 1614911456 a "parent" entry
; these are functions that /return/ structured data, undefined in their text form but given life in code
; they are more than key-value fields like "parent: 1614911456".
```

> bopwiki entries [... have] "meta lines" [... and ] "filters"
> they are more than key-value fields like "parent: 1614911456".

so, I asked myself, what can I even do if I want to put a key-value dictionary inside a file format which fundamentally abhors arbitrary + mutable things like property names?

and the answer led me to a very confusing and esoteric thing called "ontologies".

@Valenoern For a file format, not breaking it is normal and should quite be expected.
For a language, okay yeah fine but maybe break a bit after like… 10 years? (C does break and it's fine)
For kernels and librairies, please do not avoid breaking ABI/API too much, there is a pile of broken things out there that are kept broken just because of this, just stabilize and keep it for few years. ("Linux maintains bugs")

my approach so far has been to kind of nudge users to code & name simple functions themselves to use features beyond absolute core ones

I figure if I essentially hide most of the logic inside the program and make the API surface "I'm" responsible for really small,
I can create a system where the user maintains their own API against future breakage

hopefully in such a way that whenever you want to add a custom feature to bop you end up reformatting data entries as little as possible

bop is fundamentally built to quickly jot down a chunk of text, and then add "meta lines" that connect it to others or describe it.
usually just a couple, but maybe a bunch

there is a whole idea of "filters" for allowing the user to customise how raw entry files become their 'canonical' form, such the user can take the bop "file format" and redefine what it is and can do

but at this time it's not really designed for meta lines like
"key: value"

this is partly intentional.

while thinking about what I wanted bopwiki to be, I decided I wanted to avoid "breakable APIs" as much as possible

nothing bugs me more than the concept programming functions can have the most arbitrary names and could change at any time or be merged or split with others...
/but/ users could also rely on them not changing.

why have we baked human language into programming like this when it's the most arbitrary and constantly-mutable thing