[ { "@context": ..., "@id": "http://manu.sporny.org/i/public", "@type": "foaf:Person", "name": "Manu Sporny", "knows": "http://greggkellogg.net/foaf#me" }, { "@context": ..., "@id": "http://greggkellogg.net/foaf#me", "@type": "foaf:Person", "name": "Gregg Kellogg", "knows": "http://manu.sporny.org/i/public" } ]
This pattern is extensively used in linked data. e.g for calendar events, transactions, etc.
The consequence of non conformance will be that remote storage will NOT be able to read arbitrary JSON LD. And not be able to write JSON LD where there is more than one object. Obviously this could make it difficult for unhosted apps to interact with other web apps such as RWW..
I just wanted to establish whether it's a goal of remote storage to be in conformance with JSON LD on this issue, or whether it's a willful violation of the spec.
--
--
Excerpts from Melvin Carvalho's message of 2012-09-28 22:14:29 +0000:
guys c'mon! let's take it calm and look at Melvin's use case?> On 29 September 2012 00:06, Michiel de Jong <mic...@unhosted.org> wrote:
>
> > On Fri, Sep 28, 2012 at 9:32 PM, Melvin Carvalho
> > <melvinc...@gmail.com> wrote:
> > > my opentabs transactions will not be loadable by an unhosted opentabs
> > app.
> >
> > wait, you are not using remotestorage, so then it doesn't affect you.
> > All you need to do is serve your data with CORS headers, then any
> > unhosted web app can load your data, regardless of how the
> > remotestorage module structures its own data, that's independent.
> >
>
> Im definitely keen to use remotestorage, when it's linked data ready.
> Probably makes sense to wait a bit, at this stage.
i understand that you want to shovel an array of financial transactions into your remotestroage account.
[ {}, {}, {}, ...]
what URI you would like to PUT it to and GET it from?
ex. /transactions/2021/09/29
how do you see it organized within remote storage paths? do you just want to PUT and GET from given path or you expect storage to do something *intelligent* with an array you PUT?
☮
--