#social 2019-11-17
2019-11-17 UTC
# 
trwnh fr33domlover: a merge request is actually the request itself, not simply a set of commits. the commits are attached. i think it makes sense to say MergeRequest is an extension of Offer
# trwnh that way the Commits are the "object" of the MergeRequest, not the "content"
# fr33domlover trwnh, good point. It still leaves the question, whether to use 'content' for the description. Another example is a hypothetical type Banana that has a rich text description, but it's not the real content
# fr33domlover I want to decide whether to always use 'content' in such cases, or always use something else
# fr33domlover And reserve 'content' to Note, Article etc. where the text is literally the content
# trwnh fr33domlover: you could use either content or summary as discussed previously (with summary being reserved for natural language processing)
# trwnh The summary of a MergeRequest would be like "trwnh wants to merge 6 commits into fr33domlover/vervis"
# trwnh the "content" would be the longform description that the user would type out
# fr33domlover trwnh, yeah I mean should I use 'content' for the user written description e.g. "A delicious yellow banana" / "Hello, this merge request fixes issue #42, have fun"
# fr33domlover Hmm ok
# fr33domlover trwnh, are there examples from the fediverse for this? I mean, I want to make the choice that would be expected and compatible
# fr33domlover Like, have people been doing this in implementations
# fr33domlover i.e. using 'content' in stuff that isn't Note or Article
# trwnh well barely anyone uses anything aside from Note anyway
# trwnh just because there arent any implementations doesnt mean the spec isnt laid out in such a way as to expect certain things
# trwnh it might be helpful to have a documentation site where example as2 documents are provided, and then request comment on those
# trwnh before any sort of implementation work is done, that is
# fr33domlover I'm happy to use 'content' and not a custom non-standard property, I just want to be sure it's not confusing when 'content' isn't used for the actual content such as in Banana above
# fr33domlover trwnh, i'll write an example :)
# fr33domlover trwnh, ah I have another example: a Commit object, in which 'content' would be the plain text commit message. Does that make sense? (I've been using a custom property for this until now)
# fr33domlover (the real essence of the commit is the actual changes it made)
# trwnh yes fr33domlover, the content of a Commit could be the message
# trwnh a Commit is essentially in my mind an extended Note
# trwnh the relevant git.patch is an attachment
# fr33domlover trwnh, in my mind a Commit is a VCS object that sits inside .git :P
# trwnh well you're dealing with both
# fr33domlover And the AP Commit object is just an AP representation/description of it
# trwnh in VCS terms a commit is a commit, in AP terms you should be more concerned with describing the actual forge bits
# trwnh rather, maybe more accurate to say Commit and Issue both are more like extended Articles, but the note vs article distinction isn't terribly important
# fr33domlover trwnh, tbh I don't like thinking of everything as Note and Article. Because that just takes us back to plain email. We're using JSON-LD i.e. RDF here, things can be properly typed and just be versions of text messages
# fr33domlover *and not just
# fr33domlover Technically, a commit message can be empty
# fr33domlover The essence of the commit is the actual diffs, the changes it makes to the repo
# fr33domlover And the message just helps humans understand the purpose of the changes
# trwnh fr33domlover it's not that everything is a Note or Article, but rather that Note and Article are the only native text Objects within activitystreams
# trwnh we're not going "back" to email, but rather, we're making email that's more metadata-aware
# trwnh essence is not relevant
# trwnh what matters is how you carry it
# fr33domlover It's just Note and Article because AS2 can't define every possible type out there, and doesn't need to; there are RDF ontologies for that
# trwnh from a structured data viewpoint, we should leave the ultimate interpretation to the humans while making it as machine-readable as possible
# trwnh honestly Note and Article are redundant
# trwnh they're just Text
# trwnh not that a Text type exists, but thats besides the point
# trwnh how do you express a native container for xsd:string, basically
# trwnh in hindsight it would maybe have been better to say that Note should always be plaintext, or that Article should be embeddable in html <article>, or whatever
# fr33domlover trwnh, last comment at https://talk.feneas.org/t/editable-rich-text-fields/185/5
# trwnh but the delivery mechanism is the same
# trwnh we're just passing around text as native objects
# trwnh the extensions provide the metadata
# fr33domlover We're passing text, numbers and booleans
# fr33domlover The native literal types of JSON ^_^
sl007 joined the channel
# nightpool[m] trwnh: discord chat messages are unambiguously Notes, but they have rich text formatting
# nightpool[m] so it's a bit of a hard line to walk
take2 joined the channel
# heluecht[m] trwnh (IRC): Concerning this "Link instead of Page": In fact the "Link" type has got fewer parameters. And since we are referring to a page, this should be okay.