snarfed
Consider treating mf2 "category" URLs as AS objectType "person"
Per conversation in IRC http://indiewebcamp.com/irc/2015-11-17/line/1447795539069
We should consider microformats2 simple "u-category" properties as person tags if they look like a URL.
That means mf2:
{
"properties": { "category": ["http://tantek.com"]
}
would translate to activitystreams as:
{
"tags": [{ "objectType": "person", "url": "http://tantek.com"}]
}
Rationale: normal tags are textual, e.g. "books", rather than URLs. URLs can be people, locations, organizations, etc. Person is a reasonable fallback assumption if not otherwise specified, since that is the biggest use case for tagging with a URL, and also is nice feelgood human-centric indiewebiness
the use case is to not require h-card on person tags for bridgy publish, right? the alternative would be to put this "assume person tag by default" logic in bridgy instead, and keep granary's existing conservative translation.
Right!
If "assume category url is a person" is a good general rule for interpreting mf2, then I think it should go in Granary.
If it's an experimental addition to see if it's something that we may adopt in practice in the future (and a useful interpretation for publishing person-tags since that's what we're excited about this week) that argues for Bridgy.
yup. i vote the latter. default use case, yes. default schema mapping, maybe not.
also fwiw, the logic in bridgy publish would be looser: it technically wouldn't assume they're people, just that they have silo accounts. includes pages, orgs, etc.
That makes sense to me. For Granary then, we just need to add support for simple text tags (right now they are skipped when processing "category")