Re: How to mitigate accidental/unwelcome IRI expansion?

Thanks James, I think mentioning the incompatibility in the draft is a good
idea.

On Wed, Dec 16, 2015 at 1:32 PM, James M Snell <jasnell@gmail.com> wrote:

> Josh: I'm going to be adding a note to the editor's draft about this
> issue today. It's likely worthwhile to at least drop a note into the
> mailing list about the issue but given that JSON-LD support is
> optional, it's not a blocker for moving forward.
>
> On Wed, Dec 16, 2015 at 10:29 AM, Josh Tilles <josh@signafire.com> wrote:
> > Robert,
> >
> > I actually started out by creating an issue for the Activity Streams 2.0
> > GitHub repo. 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, 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
> >
> >
>