Closed Mihailoff closed 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
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"
}
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.
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
andid
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 theJSON-LD
definition.I could not find the definition of
type
andid
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.