Activity Streams/Primer/Vocabulary conflicts
Users of AS2 may incorporate other vocabularies that have terms that conflict with the AS2 terms.
When this happens, there are a few possibilities for disambiguating the terms.
Use a full IRI for the extension term
The default option is to use the full IRI of the extension term. This has the advantage of not needing to define any additional @context
declarations, but it can be inconvenient to read or work with if there are many extension terms being used from the same vocabulary, or if the IRIs are very long and not particularly human-readable.
{ "@context": "https://www.w3.org/ns/activitystreams", "type": ["Person", "http://schema.org/Person"], "name": "Alice P. Hacker", "http://schema.org/givenName": "Alice", "http://schema.org/additionalName": "P." "http://schema.org/familyName": "Hacker" }
Use namespace prefixes
One way to disambiguate is to provide namespace prefixes for your extension vocabularies, and use those prefixes within the document. For example, the following document uses Person
and name
from both the ActivityStreams and Schema.org namespaces, but prefixes usages of the terms from the Schema.org namespace:
{ "@context": [ "https://www.w3.org/ns/activitystreams#", { "schema": "http://schema.org/" } ], "@type": ["Person", "schema:Person"], "name": "Alice", "schema:givenName": "Alice", "schema:additionalName": "P.", "schema:familyName": "Hacker" }
This option has the advantage of shortening various usages of full IRI terms, but it also has the disadvantage that there are infinitely many possible prefix mappings. It is good practice to try to be consistent with conventional mappings such as those found in the RDFa Core Initial Context, and to not invent your own prefix mappings. For example, since http://schema.org/
is commonly defined with the shorthand prefix schema:
, it would not be best practice to instead use sc:
or sdo:
as a prefix definition.
Use a term definition
If using namespace prefixes within your JSON is inconvenient, or if you want to map terms to specific shorthand property names, it is possible to define a term within an additional context document. For example, the following document uses an embedded context document that defines terms for two properties taken from the VCard RDF syntax:
{ "@context": [ "https://www.w3.org/ns/activitystreams#", { "VcardOrg": "https://www.w3.org/2006/vcard/ns#Organization", "email": { "@id": "https://www.w3.org/2006/vcard/ns#hasEmail", "@type": "@id" } } ], "@type": ["Organization", "VcardOrg"], "name": "Acme Inc", "email": "mailto:hello@acme.example" }