name versus nameMap clarification

[JacksonBailey]

Please Indicate One:

• [ ] Editorial
• [x] Question
• [ ] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

Activity Vocabulary Object only mentions name, but Activity Streams Object mentions both name and nameMap. The Activity Vocabulary name property shows an example where the property is named name (example 117) and one where it is named nameMap (example 118).

1. Should the Activity Vocabulary Object specify that it has both name and nameMap instead of only name?
2. If it is correct that Object has both of these properties, is name meant to always be xsd:string and nameMap meant to always be rdf:langString?

[evanp]

This is somewhat confusing. When we were creating the AS2 docs, we considered nameMap to be a minor structural variation on the name property, and similarly with other *Map properties. That said, it probably would be useful to include the *Map properties in the full list of Object properties on the Vocabulary doc, and to have an entry in the Properties section for each one.

The question now is whether this rises to the level of an error, requiring an Erratum, or if this is the kind of clarification that we would do in a next version. I think this is some significant text, and probably should be part of a next version's clarifications.

[evanp]

@trwnh suggests that this also might be a good candidate for a Primer page, to cover the basics how to use these properties.

[evanp]

If it is correct that Object has both of these properties, is name meant to always be xsd:string and nameMap meant to always be rdf:langString?

No, the nameMap should only be in the mapping format shown in Natural Language Values in AS2 Core.

[trwnh]

The difference between name and nameMap is that name has no @language declaration, while nameMap does have a @language declaration:

https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%22https%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%22name%22%3A%22Sally%22%2C%22nameMap%22%3A%7B%22und%22%3A%22Sally%22%7D%7D

From the N-Quads and Table views, you can see the difference between "Sally" and "Sally"@und

---

I don't think there should be both x and xMap properties on the same object, but it is probably going to be something that some producers are going to do for nonspecific compatibility reasons.

[JacksonBailey]

As an aside, thank you for mentioning the primer. I did not know that exists. (And for others who may not know it exists, https://w3c.github.io/activitystreams/, https://www.w3.org/wiki/Activity_Streams/Primer)

[JacksonBailey]

Relates to #486

[sebilasse]

just wanted to mention, the sentence " that name has no @language declaration" might be misleading. If the JSON LD root has a @language ("the default language of a JSON-LD document") then this is the language of the name otherwise it has none.

From the bottom of my heart, encouraging anyone to be ActivityPub conformant and support "the entirety"- When you consume e.g. data from news agencies or wikidata it will end up with a super-nice nameMap, summaryMap, contentMap

[evanp]

I think this error of omission is too big to be covered by an erratum, which is usually something we do for an error of commission, that is, textual or example errors. In this case, I'm going to take off the Needs erratum tag, and leave the Needs primer and Next version. I think the best outcome would be to fully document *Map in the Vocabulary doc in the next version of the standard.

[sebilasse]

just btw; as:nameMap is mostly covered in the core specs. : https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues ff.

Posted to fedi then:

[…] (apart from this concrete issue) it make me think about how new users to the protocol understand the use of multiple languages

The problem why the #ActivityPub #Specification has a deep learning curve:

In order to understand the use of multiple languages, you need to read at least 4 specifications. Any user of the software can say: I speak language X in quality Y. It might not be obvious to new users that it is the according

• HTTP "accept-language" header like e.g. "de,en-US;q=0.7,en;q=0.3"

The default language is defined in the

• JSON-LD spec. as described in above issue

The primer to read about how to use it is in the

• AS Core specs. https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues

while the properties are described in the

• Vocabulary specs. e.g. https://www.w3.org/TR/activitystreams-vocabulary/#dfn-name

While this is understandable and fine for me, it might be confusing to new or non-tech-implementors … #i18n #language #specs

[evanp]

I added a Primer page to cover this issue.

https://www.w3.org/wiki/Activity_Streams/Primer/Language_mapping

We still need to include the *Map properties in the Activity Vocabulary in the next version, for clarity and completeness, but this should help for developers.