w3c / activitystreams

Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/
Other
281 stars 61 forks source link

Difference between @type/@id in JSON-LD and type/id in AcitivtyStream #592

Closed Mihailoff closed 5 months ago

Mihailoff commented 5 months ago

Please Indicate One:

Please Describe the Issue:

I'm new to ActivityStreams and was actively studying it for a couple of days.

It seems that the purpose of the type and id in AcitivtyStream is pretty similar if not the same as @type and @id in JSON-LD.

For example, in https://www.markus-lanthaler.com/hydra/spec/latest/core/ spec @type and @id is used "as-is" conforming to the JSON-LD definition.

I could not find the definition of type and id properties in specs https://www.w3.org/ns/activitystreams/ https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-vocabulary/

It makes it confusing. In this regard, using @type and @id in AS would reduce the learning curve and perhaps the adoption.

nightpool commented 5 months ago

"type" and "id" are defined in the JSON-LD context document to be pure aliases of the JSON-LD @type and @id properties: https://www.w3.org/ns/activitystreams

They were created solely to make it so consumers using languages like Javascript and others that use the . notation for property access could more easily access the type and id of activitystreams objects. So, for example, you can do post.id in js without having to add some complicated manual conversion layer or litter your code with hundreds of post["@id"] sigils.

While this might not have been the right trade-off for learning purposes, I think it's true that "most" developers don't really need to understand JSON-LD to start processing and sending ActivityStreams documents, and only once you get into the nitty-gritty of extending AS2 with new feature or improving the spec design do you really need to start to worry about what's going on "under the hood" on the JSON-LD level. So I think there's some merit to it

Mihailoff commented 5 months ago

The only mention I found is this https://www.w3.org/ns/activitystreams.jsonld suggesting that it is an alias?

{
  "@context": {
    "@vocab": "_:",
    ...
    "id": "@id",
    "type": "@type",
}

Will this be a valid AS statement?

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@type": "Object",
  "@id": "http://www.test.example/object/1",
  "name": "A Simple, non-specific object"
}
Mihailoff commented 5 months ago

They were created solely to make it so consumers using languages like Javascript and others that use the . notation for property access could more easily access the type and id of activitystreams objects. So, for example, you can do post.id in js without having to add some complicated manual conversion layer or litter your code with hundreds of post["@id"] sigils.

Thank you. This explains it.


$id and $type could work for easy JSON access but could potentially create issues on the storage query side. In some databases $ is a special character...

const test = {
  "$id": "hi"
}

console.log(test.$id) // 'hi'

The safest is _ but it is now drifted away from JSON-LD.

To conclude: it is what it is and for a reason. I hope this will be a valuable piece of knowledge for others.