Re: How to mitigate accidental/unwelcome IRI expansion?

> On Dec 16, 2015, at 10:06 AM, James M Snell <jasnell@gmail.com> wrote:
> 
> This is a fundamental design issue with JSON-LD's algorithms and CURIE
> expansion. Since AS2 does not require the use of JSON-LD, it's likely
> not a blocker for CR but it is something that ought to be documented
> (I can include an editorial note in the AS2 spec). The suggested work
> around actually leads to invalid AS2 because the core term mappings
> cannot be modified. The end result is that URLs whose schemes overlap
> with @context defined terms are generally incompatible with use of
> JSON-LD.

It seems that the use of “tag” as both a IRI scheme and a term definition is unfortunate, and is indeed the source of this confusion. FWIW, pretty much any RDF serialization that allows a value to be either an absolute IRI or a CURIE/Compact IRI would suffer from the same problem. IIRC, RDFa faced such a problem when there was a vocabulary with the unfortunate “http” prefix (now simplified to just “ht” in the RDFa initial context).

Gregg

> 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 Wednesday, 16 December 2015 18:16:56 UTC