Re: How to mitigate accidental/unwelcome IRI expansion?

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
> <http://www.w3.org/TR/2015/WD-activitystreams-core-20151006/>, 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
> <http://www.w3.org/ns/activitystreams#tagsearch.twitter.com,2005:593895901623496704>.
> (JSON-LD playground link
> <http://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%22http%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%22%40id%22%3A%22tag%3Asearch.twitter.com%2C2005%3A593895901623496704%22%2C%22%40type%22%3A%22Create%22%2C%22url%22%3A%22http%3A%2F%2Ftwitter.com%2FKidCodo%2Fstatuses%2F347769243409977344%22%2C%22actor%22%3A%7B%22%40id%22%3A%22id%3Atwitter.com%3A2993982541%22%2C%22%40type%22%3A%22Person%22%2C%22displayName%22%3A%22Kid%20Codo%22%2C%22url%22%3A%22http%3A%2F%2Fwww.twitter.com%2FKidCodo%22%2C%22image%22%3A%22https%3A%2F%2Fsi0.twimg.com%2Fprofile_images%2F3664410292%2F1d75c213a572873bf6797c5591475da5_normal.jpeg%22%7D%7D> 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