Please alias @id and @type to 'id' and 'type'

[msporny]

Hey, sitting here in Web Annotations breakout with @tantek, and chatting w/ Social Web WG previously - it seems like both groups are using "@id" and "@type" without legacy data issues (you don't have previous data that uses "id" and "type".

It's considered a best practice to alias all "@" keywords to those keywords without the @sign. So for example "@id" should be aliased to "id". We just convinced the Web Annotations WG to make this change. They were concerned about making this change because they wanted to use the Social Web WG that was using "@id" and "@type".

If both groups switch to just "id" and "type", it would be very positive for Web developers. Don't use @ signs if you don't have to.

[azaroth42]

👍 from the Web Annotations WG. Our equivalent issue: w3c/web-annotation#88

[elf-pavlik]

👍

I also suggested it in

• https://lists.w3.org/Archives/Public/public-socialweb/2015Oct/0165.html

and referenced previous discussion started by @azaroth42 in

• https://lists.w3.org/Archives/Public/public-linked-json/2015Sep/0000.html

[jasnell]

+1. This does not completely eliminate the @ issue given the @context and @language requirements, but it great to see this adopted as a best practice.

[akuckartz]

👍

[dissolve]

👍
"It's considered a best practice to alias all "@" keywords to those keywords without the @sign."

why would we not alias @value and @language as well?

[aaronpk]

👍

[silverbucket]

IMHO this adds more confusion. We're saying that @prop and prop are the
same, so just use prop. Except @context, for which @context and context are
two different things, not sure why we had to do that but we did.

If we have to use @context for compliance reasons, why did we add another
property called context?

On Fri, Oct 30, 2015, 16:11 Aaron Parecki notifications@github.com wrote:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#232 (comment)
.

[jasnell]

Limiting this to id and type is just fine. AS2 core does not make use of @value and @language only really comes into play when setting the default language context... and things just continue to work for implementers who are going the full JSON-LD processing route. Limiting this to id and type covers the overwhelming majority of cases where the @ would be used outside of the @context field itself.

[elf-pavlik]

I would like to remind that @context applies to all the nested object as well and needs to stay kept as special property. @id and @type work like any other property and apply only to the object directly used on.

http://www.w3.org/TR/json-ld/#aliasing-keywords

Each of the JSON-LD keywords, except for @context, may be aliased to application-specific keywords. This feature allows legacy JSON content to be utilized by JSON-LD by re-using JSON keys that already exist in legacy documents. This feature also allows developers to design domain-specific implementations using only the JSON-LD context.

[silverbucket]

What about context vs @context ?

[jasnell]

@context cannot be aliased given the fact that the value of @context is
where the aliases are defined.
On Oct 31, 2015 7:51 PM, "Nick Jennings" notifications@github.com wrote:

What about context vs @context ?

—
Reply to this email directly or view it on GitHub
#232 (comment)
.

[silverbucket]

@jasnell Oh, yeah I know. What I meant was, we use both properties for different things, don't we? context has a meaning separate from @context. That could be a source of confusion (it was for me) when first approaching AS2

[BigBlueHat]

@silverbucket good catch... Given that context in the AS2 Vocabulary is "intentionally vague" and really only about grouping related content, I'd be in favor of seeing it removed or renamed (possibly to purpose...but that's still very vague) or replaced by the use of Tag objects--which seem to serve this purpose also.

Additionally, I didn't find reference of this context in the AS1 vocabulary, so I'm not sure there's a compelling reason to keep it around given the confusion it introduces.

This sounds like a new issue, though...so I'll file that. 😄

[silverbucket]

I currently use context quite a bit in Sockethub development. Since Sockethub processes Activity Streams as commands (rather than results of actions), I use context to define a logical grouping of verbs (@type). For example, a post to twitter would have the context of twitter, while a post to facebook would have the context of facebook. A message to IRC would have the context of irc.

This is the only way I could find in the ActivityStreams2 spec to not have to define my own vocabulary and keep things simple (IMO I think this is quite a basic thing that shouldn't need extra vocabulary - don't you want to know where your data is coming from or going to?).

[silverbucket]

Ah I see now that context is actually supposed to be an object, I didn't know that before and have been using it as a string. However, I see as one of the properties of the context object is platform. Maybe it would make sense to define Sockethub platforms (what I refer to them as) as:

{
...
  "@type": "send",
  "context": {
    "platform": "irc"
  }
}

@jasnell do you have any suggestions?

[jasnell]

context can easily be a string so long as it's an absolute URL/IRI ;-) You can use any object type you want for context.

[jasnell]

WG approved this change