Re: How to mitigate accidental/unwelcome IRI expansion?

Apologies for the delay in reply.

I've responded inline again.

On Fri, Dec 18, 2015 at 7:18 PM, James M Snell <jasnell@gmail.com> wrote:

> On Fri, Dec 18, 2015 at 3:33 PM, Josh Tilles <josh@signafire.com> wrote:
> [snip]
> >
> > Assuming James’s framing of the problem is accurate: is there any
> intention
> > to fix this limitation of JSON-LD? I realize that what “fix” means isn’t
> > necessarily clear yet, so I’ll get the ball rolling. I recall that one of
> > the first things I reached for instinctively was some way to “opt out” of
> > expansion for specific parts of a document, to somehow mark a value as
> > “raw”. Now, I’m not confident (at all!) that that’s the best approach,
> but I
> > think it’s something to start with.
> >
>
> Keep in mind that the expansion is only applied when the term @type is
> defined as @id or @vocab. You can opt out on a specific term by simply
> not defining it as @type=@id in the context.

Ah, gotcha. Thank you for explaining!

> Within the AS2.0 normative context, however, many of the terms as defined
> as @type=@id,
> including every field where you'd want to use the tag uri scheme. This
> is done because it enables those values to be represented either as
> URI strings or objects with @id's of their own. It's an important
> piece of functionality that we don't want to lose.

Makes total sense.

> So, unfortunately, you cannot opt out for the AS 2.0 terms but you can opt
> out in your
> own extension properties. In JSON-LD in general, opting out is easy...
> but there is a tradeoff in functionality.
>
So would it be fair to say that —as far as AS 2.0 is concerned— the
GNIP-provided URIs are "bad"? (Incidentally, it's not just "tag": GNIP also
provides URIs that begin with "id:" and "object:"! 😬)

P.S. If I should take this conversation elsewhere (e.g., to the Activity
Streams or social-web(-comments?) mailing lists, or to an IRC channel) just
let me know.