Re: How to mitigate accidental/unwelcome IRI expansion?

Robert,

I actually started out by creating an issue for the Activity Streams 2.0
GitHub repo
<https://github.com/jasnell/w3c-socialwg-activitystreams/issues/273>. Would
you still encourage re-posting my question to the Social Web WG?

On Wed, Dec 16, 2015 at 12:08 PM, 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
>> <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
>