Best way/example of extending AS Object Types

[gobengo]

I'm making this separate issue from my earlier question to @elf-pavlik on #134. But I welcome feedback from anyone.

I've done a good amount of work recently mapping the current draft AS Vocabulary to the domain used at my organization, Livefyre, which you can check out at http://livefyre.github.io/activity-vocabulary/

I'd like to make sure we're extending AS Object Types in the best way possible to promote interoperability, but I also have some goals of my own.

Let's take an example, as:Content and livefyre:Content

Why extend?

• There are some assertions I can make about livefyre:Content that I can't truthily make about all as:Content. For example, rdfs:comment (descriptions of this set of objects and how they fit into the rest of the Livefyre ecosystem, documentation links, etc).
• There are properties whose range may be livefyre:Content but not as:Content, because they're relations that are idiosyncratic to our platform

Now, when I'm serializing a JSON Object representing livefyre:Content, I want to be encoding the fact that it is livefyre:Content (a subset of as:Content), but ideally in such a way that if there is a consumer who doesn't know/care about out subset, they can just treat it as as:Content (without reading/understanding the rest of my context document that explicitly says that livefyre:Content owl:subClassOf as:Content)

It seems like the relevant part of the current draft that would help me answer this is section 1.2 of the Core Syntax. But honestly, I'm not really sure exactly what it means.:

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here. Implementations may augment the provided @context with additional @context definitions but must not override or change the normative context. Implementations may also include in the serialized JSON document additional properties and values not defined in the JSON-LD @context with the understanding that any such properties will likely be unsupported and ignored by consuming implementations that use the standard JSON-LD algorithms. See the Extensibility section for more information on handling extensions within Activity Streams 2.0 documents.

Here is what I'm doing now. Is this valid AS2? If not, how should I do it?

• Here the social object serialization uses a @context that itself includes the canonical AS2 context in its context.

  {
  "@context": "https://livefyre-cdn.s3.amazonaws.com/libs/livefyre-activity-vocabulary/v0.0.0/context.json",
  "@id": "urn:livefyre:{network}:collection={collection.id}:content={content.id}",
  "@type": "Content"
  }

I have a feeling that it's not, and that there's not currently a valid way of reusing the 'Content' term if it compacts to my vendor-specific vocab prefix ('livefyre:'). It seems like that conflicts with

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here.

This is frustrating as it seems like 'being AS2 compliant' imposes an upper bound on how 'rich' my JSON-LD document can be.

If I give up on being able to re-context the 'Content' term, I could use multiple types to balance richness and compliance, though this would make it harder to do just naive consumption (activity['@type'] !== 'Content')

Is this valid?

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    "url to livefyre context that doesnt redefine _:Content, just livefyre:Content"
  ],
  "@id": "urn:livefyre:{network}:collection={collection.id}:content={content.id}",
  "@type": ["Content", "livefyre:Content"]
}

[jasnell]

The second example is close. You can envelope the core context as you do in your first example but you cannot redefine any of the core terms. So you can, for instance, have your own context doc like:

http://example.org/my-context.jsonld:

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    {
      "livefyre": "http://livefyre.example.org/",
      // other terms that aren't in the core context
    }
  ]
}

Then have your instance doc:

{
  "@context": "http://example.org/my-context.jsonld",
  "@id": "urn:livefyre:{network}:collection={collection.id}:content={content.id}",
  "@type": ["Content", "livefyre:Content"]
}

[gobengo]

Thanks @jasnell