- From: Josh Tilles <josh@signafire.com>
- Date: Wed, 16 Dec 2015 13:43:36 -0500
- To: James M Snell <jasnell@gmail.com>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Linked JSON <public-linked-json@w3.org>
- Message-ID: <CAFRY1zppF3MigkdVt8qz1zsyFaG1wfAE00c_VH8K4A4WO3b1mQ@mail.gmail.com>
James, I’ve replied inline. 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. I recall you saying as much in my GitHub issue. > … AS2 does not require the use of JSON-LD, Oh, I didn’t realize that! I thought that AS2 was “merely” a vocabulary for JSON-LD documents. > The suggested work > around actually leads to invalid AS2 because the core term mappings > cannot be modified. Ouch. Thanks for calling that out. I’d be interested in other workarounds, but it seems like that veers into territory that would be more appropriate on the Activity Streams mailing list instead of here. > 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. > > 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:44:05 UTC