Re: How to mitigate accidental/unwelcome IRI expansion?

On Wed, Dec 16, 2015 at 1:43 PM, Josh Tilles <josh@signafire.com> wrote:

>
> On Wed, Dec 16, 2015 at 1:06 PM, James M Snell <jasnell@gmail.com> wrote:
>
>> This is a fundamental design issue with JSON-LD's algorithms and CURIE
>> expansion.
>
> …
>
> The end result is that URLs whose schemes overlap
>> with @context defined terms are generally incompatible with use of
>> JSON-LD.
>>
> That seems like a valuably-concise definition of the problem. I’d like to
> know if others here agree with your assessment.
>

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.

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?

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