Re: How to mitigate accidental/unwelcome IRI expansion?

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. 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. 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.

> Alternatively, am I incorrect in viewing this limitation as an insidious yet
> potent flaw of JSON-LD? Like, is it actually more a superficially-ugly
> oddity than anything genuinely destructive?
>

Little of both, I'm afraid.

> I look forward to your comments & suggestions,
> -Josh
>
>>>
>>>
>>> On Wed, Dec 16, 2015 at 9:08 AM, Robert Sanderson <azaroth42@gmail.com>
>>> wrote:
>>> >
>>> > Josh,
>>> >
>>> > I'm afraid I don't have a solution, but could you also post the
>>> > question to
>>> > the Social Web WG?
>>> > We're currently looking to take ActivityStreams to Candidate
>>> > Recommendation
>>> > early in the new year, and if this is something that might come up
>>> > during
>>> > the request for comments phase, it would be great to discuss it early
>>> > rather
>>> > than in last call :)
>>> >
>>> > The Social Web list:
>>> >     https://lists.w3.org/Archives/Public/public-socialweb/
>>> >
>>> > Many thanks!
>>> >
>>> > Rob
>>> >
>>> >
>>> > On Mon, Dec 14, 2015 at 6:50 PM, Josh Tilles <josh@signafire.com>
>>> > wrote:
>>> >>
>>> >> Dear all,
>>> >>
>>> >> When learning Activity Streams 2.0, I discovered that certain @ids
>>> >> were
>>> >> vulnerable to being mangled during expansion. For example, the
>>> >> absolute IRI
>>> >> tag:search.twitter.com,2005:593895901623496704 gets expanded to
>>> >>
>>> >> http://www.w3.org/ns/activitystreams#tagsearch.twitter..com,2005:593895901623496704.
>>> >> (JSON-LD playground link for complete example)
>>> >>
>>> >> Is this a problem that others have come across before? Is there any
>>> >> sort
>>> >> of standard advice to work around absolute IRIs being mistakenly
>>> >> interpreted
>>> >> as relative?
>>> >>
>>> >> An approach I came up with is to “unmap” the offending terms, like:
>>> >>
>>> >> {
>>> >>   "@context": [
>>> >>     "http://www.w3.org/ns/activitystreams",
>>> >>     {"tag": null}
>>> >>   ],
>>> >>   "@id": "tag:search.twitter.com,2005:593895901623496704",
>>> >>   "@type": "Create",
>>> >>   "url": "http://twitter.com/KidCodo/statuses/347769243409977344",
>>> >>   "actor": {
>>> >>     "@context": {"id": null},
>>> >>     "@id": "id:twitter.com:2993982541",
>>> >>     "@type": "Person",
>>> >>     "displayName": "Kid Codo",
>>> >>     "url": "http://www.twitter.com/KidCodo",
>>> >>     "image":
>>> >>
>>> >> "https://si0.twimg.com/profile_images/3664410292/1d75c213a572873bf6797c5591475da5_normal.jpeg"
>>> >>   }
>>> >> }
>>> >>
>>> >> But this seems kludgy, and I could imagine it having unintended
>>> >> consequences if other parts of the JSON document actually used the tag
>>> >> property and expected it to expand to
>>> >> http://www.w3.org/ns/activitystreams#tag. An additional weakness of
>>> >> this
>>> >> approach is that it relies on a human to determine which IRIs “don’t
>>> >> look
>>> >> right” by examining expanded documents, and that there’s no guarantee
>>> >> that
>>> >> other IRIs vulnerable to different prefix-collisions won’t slip in in
>>> >> the
>>> >> future.
>>> >>
>>> >> Please share any comments regarding the above, or advice in general
>>> >> for
>>> >> dealing with IRIs properly in JSON-LD.
>>> >>
>>> >> A pre-emptive & emphatic “thank you” for any guidance you can provide,
>>> >> -Josh Tilles
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Rob Sanderson
>>> > Information Standards Advocate
>>> > Digital Library Systems and Services
>>> > Stanford, CA 94305
>>
>>
>

Received on Saturday, 19 December 2015 00:19:14 UTC