Activity Streams/Primer/Vocabulary conflicts

From W3C Wiki

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"
}

External links