#social 2018-03-06
2018-03-06 UTC
javisantos and cdchapman joined the channel
# 
Gargron what json-ld property can i use to encode a list of key/value pairs where the key is free-form text defined by users?
cwebber joined the channel
# Gargron cwebber: what json-ld property can i use to encode a list of key/value pairs where the key is free-form text defined by users?
xmpp-social, JanKusanagi, jankusanagi_ and rigelk joined the channel
# puckipedia <Gargron> what json-ld property can i use to encode a list of key/value pairs where the key is free-form text defined by users? <- hmm, which context?
# puckipedia ah, aha
jankusanagi_ and jankusanagi__ joined the channel
# puckipedia (I replied on the discord)
# puckipedia (in general, if you know json-ld, it's @index container mapping)
JanKusanagi, jankusanagi_, jankusanagi__ and cwebber joined the channel
# cwebber hi Gargron... uhhhhh... I dunno if there is a way to do it or not, but there might be in 1.1 ... I'm going to ask people who know better than I do
# cwebber Gargron: could you give me the use case?
# cwebber Gargron: rather, I *do* know of a way but
# puckipedia cwebber: yeah, I also replied
# puckipedia context was metadata (string key/value next to your bio)
# cwebber ah
# puckipedia I suggseted @index
# cwebber so there's https://www.w3.org/TR/2014/REC-json-ld-20140116/#data-indexing but the keys are thrown away when transferred into rdf right?
# cwebber which means if those keys are really important
# cwebber someone could produce two different documents with different keys
# cwebber and they'll both sign to the same thing
# cwebber that's the primary risk I see from that
# puckipedia cwebber: yeah so I suggested a solution to that
# cwebber puckipedia: oh? :)
# puckipedia which is having an ID an name in the value :P
# cwebber looks at link
# cwebber puckipedia: ahh
# cwebber puckipedia: that's clever
# puckipedia csarven: @index gets dropped if you RDF it
# cwebber puckipedia: I know that bigbluehat recently pointed me at a type of uri where it actually contained string data :D
# cwebber but I forget which one it is
# cwebber csarven: Gargron wanted keys that map to strings but which *don't* map to specific terms
# puckipedia csarven: I mean, @container:@index
# puckipedia I mean, it's in JSON-LD 1.0 as well :P
# puckipedia ko so
# puckipedia csarven: see https://dev.glitch.social/@bea
# puckipedia underneath the bio, there's the "pronouns/title/AKA"
# puckipedia that's what Mastodon is implementing now, but the way that it's done on those servers is by embedding a bunch of faux-yaml in the bio
# cwebber puckipedia: https://en.wikipedia.org/wiki/Data_URI_scheme could also be used :)
# cwebber csarven: right we were talking about that not long ago, and I think we were talking about the data: uri scheme, right?
# cwebber so another way to do it might be to do
# cwebber data:text/plain;charset=UTF-8,pronoun
# cwebber or data:text/plain;charset=UTF-8,spivak
# cwebber csarven: except I don't think you can do strings as keys in json-ld
# cwebber maybe in n-quads you can
# cwebber you could also prefix this like:
# cwebber
{"@context": {"str": "data:text/plain;charset=UTF-8,"}, "str:pronoun": "str:spivak"}# cwebber that might be awful but you could do it :)
# cwebber well wait
# cwebber you wouldn't need to do it for the value
# cwebber anyway
# cwebber it is still a uri, but yeah json-ld has the limitation that strings can't be predicates
# cwebber or sorry, predicates can't be strings
# cwebber in the S-P-O sense
# cwebber ooh
# cwebber puckipedia: one could even make the str: implicit by using @vocab on the property
# cwebber to automatically make these data uris
# 
bigbluehat puckipedia: if you just want "random" key/value storage, but still within the graph, I'd recommend (atm) looking into modeling with http://schema.org/PropertyValue
# cwebber
{"@context": {"foo": {"@id": "https://example.org/#foo", "@vocab": "data:text/plain;charset=UTF-8,"}, "foo": {"pronoun": "spivak"}}# bigbluehat however, the community will get the greatest value out of any key/value it maps into the graph itself--rather then this tangential approach
# cwebber is that completely evil?
# cwebber bigbluehat: hm PropertyValue, interesting
# bigbluehat cwebber: probably :)
# cwebber anyway
# cwebber yeah it's probably completely evil
# bigbluehat cwebber: I'd also be careful (atm) to no overuse that data URL "hack" thing
# cwebber seems like a great way to unravel linked data ;)
# cwebber I'm off!
# cwebber later
# bigbluehat its abilities are unquantified :)
# bigbluehat cwebber: breaks the links a bit. ;)
# bigbluehat cwebber: ttfn
# bigbluehat puckipedia: if you want to chat more about this, I'd be happy to
# bigbluehat puckipedia: also, you might also present your use case on this list https://lists.w3.org/Archives/Public/public-linked-json/
# bigbluehat helpful folks there (besides just me ;) )
# puckipedia <bigbluehat> puckipedia: if you just want "random" key/value storage, but still within the graph, I'd recommend (atm) looking into modeling with http://schema.org/PropertyValue <- issue is that schema:name kinda overlaps with as:name
# bigbluehat puckipedia: you'd need a custom context to use it
# bigbluehat puckipedia: I missed your primary use case earlier, though I did see the key/value section in the Mastodon profile
# bigbluehat is the objective just to give users *display* of "random" user-generated key/values?
# puckipedia yes. the users can use any key and any value they want
# bigbluehat or are you wanting it mapped into the data, such that it can be queried specifically upon (vs. full text search or somesuch)
# puckipedia well, the metadata has to be federated somehow
# bigbluehat right.
# bigbluehat so...some options
# bigbluehat these are more modeling options than direct suggestions fwiw :)
# puckipedia yeah, I'm also not the one to primarily implement this, I think :P
# bigbluehat you could provide an rdf:HTML type value where folks could dump whatever key/value (or even non-key/value) profile content they want
# bigbluehat there might (though I'm not sure) be some place in AS2 for that already
# bigbluehat puckipedia: no worries :)
# bigbluehat it helps me to think through these problems too :)
# puckipedia right, so there's already a 'summary' field, but that's closer to e.g. a twitter bio
# bigbluehat here's the extension stuff in AS2 https://www.w3.org/TR/activitystreams-core/#fig-a-simple-extended-object
# bigbluehat right, so you could use that to put more stuff in--but depending on your use case, you may not want to
# puckipedia people want semi-structured key/value tables, which they kinda hacked into the bio for now, but that will be moved out
# bigbluehat if you just want it to move around the network, then summary *may* be OK
# bigbluehat sure
# bigbluehat and the goal of moving it out is?
# bigbluehat indexing it?
# bigbluehat and by extension searching for it specifically?
# puckipedia well, primarily adding the key/value structure, right now it's implemented in a fork by having e.g. "hello this is my bio\n---\npronouns: she/her\nmore: a, b, c\n---"
# puckipedia inside the summary
# puckipedia I don't know about searching, but it's primarily federating, and having to e.g. parse pseudo-yaml frontmatter is not fun
# puckipedia (especially as the summary is actually HTML)
# puckipedia (but heavily sanitized)
# bigbluehat yeah. so that current use maps to the simplest option...though, since it's HTML, I'd suggest using something HTML-y like <dl>, <dt>, and <dd>...or even a table :)
cdchapman joined the channel
# puckipedia bigbluehat: so here's the second thing: Gargron does not actually like that the federation of everything uses HTML. of course, I think it's better because it avoids side efects like how to parse @mentions
# bigbluehat "federation of everything"?
# puckipedia statuses etc, summary, all HTML, but heavily sanitized
# bigbluehat what would they want instead of HTML?
# bigbluehat gotcha, but not sure what the counter options are
# bigbluehat Markdown?
# puckipedia just plain text, like a twitter status, and the receiving server parses it
# bigbluehat gotcha
# puckipedia e.g. @asdf@example.com gets sent as-is, and then locally turned into mention
# bigbluehat there's no reason you couldn't restrict it to plain text
# puckipedia anyways. I do get why you would put the metadata in another structure, because then you can show the metadata of remote users the same way as local
# bigbluehat plain text is a valid HTML fwiw ;)
# bigbluehat in fact, https://www.w3.org/TR/activitystreams-vocabulary/#dfn-content and summary are both defined as strings--not technically as HTML
# bigbluehat is digging into why atm
# puckipedia bigbluehat: yeah, but there's also contentType or mediaType, forgot which
# puckipedia I don't think summary has a defined content type, but the content is html by default
# bigbluehat also, using HTML (rather than plain text) does avoid having to have out of band parsing rules (like "@mention" being significant, but technically undefined outside of a human context)
# bigbluehat yeah, the description states that it's HTML
# puckipedia bigbluehat: yeah, that's my opinion as well
# puckipedia there'se a bunch of other odd hacks in Mastodon, like how custom emoji work
# bigbluehat oh? images?
# bigbluehat or do you ship a custom CSS around too :)
# puckipedia haha nope. the HTML contains :asdf:, then that is parsed by the receiving server by way of a list of custom tags
# puckipedia I mean a few of us did plead for <img src="asdf" alt=":asdf:"/>
# bigbluehat yeah...that seems closer to the truth :)
# bigbluehat the issue is "out of bound" knowledge about rendering/display/processing
# bigbluehat if you keep that at the "social" layer, it's unlikely that my system will support your :asdf: emoji
# bigbluehat and keeping that merely at the software layer, means it'll ultimately fail the decentralized scalability test--because it won't reach beyond Mastodon software instances
# bigbluehat :asdf: should be mapped into something...somewhere that can be understood, reused, and referenced
# bigbluehat and <img> at least works all the places :)
# bigbluehat and, with more metadata on that tag, you could potentially "teach" other instances that this <img> they just got should be cached/kept and mapped to this custom emoji--at least for that user
# bigbluehat anyhow :)
# bigbluehat I'm happy to contribute to issue discussions and such if there are specific needs I can help with puckipedia
# puckipedia bigbluehat: so the way :asdf: was mapped, is there was a
{"type": "Emoji", "name": "asdf", "image": {...}} in the status as well# bigbluehat ah. phew!
# bigbluehat :)
# bigbluehat but that seems like twice the work
# puckipedia yes. I suggest that we have the emoji tag anyways, and then just an <img> anyways lol
# bigbluehat yeah. <i typeof="Emoji" property="name" content="asdf"><img property="image" src="asdf.gif"></i> would've also been cool :)
# bigbluehat puckipedia: anyhow. :) feel free to @ me on the githubs, twitters, or whereevers
# bigbluehat I'm also bigbluehat@toot.cafe if you need me on the Mastodonz
# puckipedia ok!
# puckipedia other question: https://github.com/tootsuite/mastodon/issues/6657
cdchapman, Chocobozzz and csarven joined the channel
# Gargron PropertyValue sounds like my exact use case
# Gargron A bunch of items where the "name" and the "content" are both written by the end-user
# puckipedia Gargron: biggest issue is that the `name` inside that PropertyValue isn't actually the same `name` that AS2 uses
# Gargron yeahhh...
# puckipedia that's probably why I suggested my own type
# Gargron i was wondering if there was maybe vCard json-ld and if that had something like hwat i need
# puckipedia anyways you could just have a toot:metadata property, and just a set of name/value/id/type objects
# Gargron i need a different name than metadata, i don't like that name
# puckipedia actually, why not cram these into as:tags
# puckipedia emh, as:tag
# Gargron yes.... yes... that could work
# puckipedia `One or more "tags" that have been associated with an objects. A tag can be any kind of Object.`
# puckipedia maybe even as:attachment?
# puckipedia `The key difference between attachment and tag is that the former implies association by inclusion, while the latter implies associated by reference.`
# Gargron attachment is even more appropriate i think
# puckipedia yeah
# Gargron tags imply search to me
# puckipedia well, you reference tags, you include attachments
# Gargron aye
# puckipedia also: will the metadata have html content or not? I think maybe, if you look at glitch-soc's implementation
# puckipedia you could e.g. have "also known as: @another@instance, etc..."
# Gargron yeah i think it'll be html
# Gargron at this point it'd be weird to try to use plaintext formats when everything else uses html
rhiaro and csarven joined the channel