support for multilingual names using as:displayNameMap

[elf-pavlik]

modeled after http://www.w3.org/TR/activitystreams-core/#naturalLanguageValues

example in JSON-LD Playground of Group '(Taabir) تعبير' http://tinyurl.com/q8ptu7c

[ahdinosaur]

awesome, thanks @elf-pavlik for helping support internationalization early. 😄

relevant docs on JSON-LD language maps, i wanted to look up if this was the only way to do it. i wish there was a way to have a single property name that could be either a string of a single language or an object of multiple languages, since as an implementor i have no idea what to do when both are given, personally my instinct is to ignore the former if the latter is given.

i'm unsure about using displayName, with the same reason as mentioned previously as i think we should want to aim for consistent labels across all of our domains, given that they all need labels. skos seems preferable to Activity Streams, since we will have uses for the more conceptual features of skos in our type objects. thoughts?

[ahdinosaur]

made an issue with my comments in mind, i'm happy to merge this in now.

[elf-pavlik]

Ok, so on vocabulary level we only have vf:displayName and only JSON-LD context introduces displayNameMap alias to simplify usage only in JSON-LD

"displayNameMap": { "@id": "displayName", "@container": "@language" }
https://github.com/elf-pavlik/agent/blob/displayNameMap/context.jsonld#L9

of course eventual https://valueflo.ws/ns/displayName should include section about existence and usage of displayNameMap and https://valueflo.ws/ns/displayNameMap should redirect to it

we could explain general approach in something like https://valueflo.ws/docs/multilingual
possibly referring directly to http://www.w3.org/TR/activitystreams-core/#naturalLanguageValues

I will create an issue in valueflo.ws repo about what options we have for using paths and subdomain from namespace and docs valueflows/valueflo.ws#7

i'm unsure about using displayName, with the same reason as mentioned previously as i think we should want to aim for consistent labels across all of our domains, given that they all need labels. skos seems preferable to Activity Streams, since we will have uses for the more conceptual features of skos in our type objects. thoughts?

Can you please provide concrete alternative for taabir.jsonld? Otherwise I would propose merging this PR and than pick up conversation when new PR with concrete alternative appears.

BTW at some point in near future we should leave comfort of vf: namespace and start switching equivalent terms to foaf: skos: org: etc. At this stage we can decide to use rdfs:label or skos:prefLabel instead of vf:displayName. For now I simply used displayName because of usage of the same JSON-LD context mapping trick as AS2.0 draft.

[fosterlynn]

BTW at some point in near future we should leave comfort of vf: namespace and start switching equivalent terms to foaf: skos: org: etc.

+1 I'd like to do that now. Do the research we need, make a decision. Easier to reference someone else's vocab than define your own. Also I think we should think of this as a stage of prototyping our first round trip, make it as good as we can within some reasonable limits of research time, and then assume that as others start to use it and review it, we will make some changes in that area.

[ahdinosaur]

BTW at some point in near future we should leave comfort of vf: namespace and start switching equivalent terms to foaf: skos: org: etc.

+1 I'd like to do that now. Do the research we need, make a decision. Easier to reference someone else's vocab than define your own. Also I think we should think of this as a stage of prototyping our first round trip, make it as good as we can within some reasonable limits of research time, and then assume that as others start to use it and review it, we will make some changes in that area.

keen, especially for the vocabs that do one thing and do it well (e.g. SKOS, QUDT). i'll admit i'm still skeptical about using foaf or as namespaces, but agree with your workflow suggestion.