Hi Benedikt,
It could be that there's some wording confusion: by "offline", did you
really just mean "private"? It sounds like what you're talking about is
people submitting data, via the internet/web, that then gets put into an
external server - only one that requires a password to access; as opposed
to the usual meaning of "offline", meaning something that people can do
locally on their computer, without any network connection.
And if that's the case, maybe the easiest solution is just to have a 2nd
wiki, with much more restricted viewing?
-Yaron
On Tue, Nov 26, 2013 at 8:28 AM, Benedikt Kämpgen <benedikt.kaemp...@kit.edu
> wrote:
> Hi,
>
> Bernhard, Yury, Yaron, Neill, thanks for your answers.
>
> @Bernhardt: the Push extension is interesting, but probably will not help,
> here, since no information shall be pushed to the online wiki.
>
> @Yury: One important requirement is to have elaborate forms (dropdown,
> etc.) and a flexible form design. Not sure whether Miga could be easily
> extended towards this use case.
>
> @Yaron:
>
>
> > - Would the offline form be just a copy of an online form? If so,
> > doesn't that mean that sensitive patient data *can* get put on the wiki?
>
> Ideally, the offline form would provide the same functionality (e.g.,
> autocompletion) than the online form. However, an offline filled-in form
> will never be stored on SMW but rather be put as-is on a secure file server.
>
> The question is, whether "as-is" actually is possible. Apparently, we are
> looking for some kind of JavaScript library that allows to offline modify
> an HTML page with forms and to save the modified HTML page.
>
>
> > - If a physician stores data offline, can other physicians ever view it?
>
> The current plan is: After offline filling-in a form, the filled-in form
> will be put on a secure file server. From there it can be downloaded for
> viewing.
>
>
> > - Where would the data be stored - on a single device?
>
> Ideally, the offline form could be used on various workstations. When an
> offline form has been filled in, it is uploaded on a single secure file
> server.
>
>
> > - Would each set of offline data have its own RDF export?
>
> That is the crucial point and the reason for using SMW in the first place.
> The online SMW is used to define properties for patients (e.g., "has BMI").
> An offline form shall now be used to fill in all properties for a patient.
> An RDF export of the offline form shall use the same properties as
> introduced by the online form. This way, we have a unique relationship
> between properties as defined by the online SMW and filled-in properties
> for a patient in an offline form. Ideally, an RDF export from an offline
> form would create the same RDF that would have been created if the form
> would have been filled-in in the online SMW.
>
> Maybe, the RDF export of the offline SMW could also be implemented using
> RDFa.
>
>
> > - How would the RDF data be queried, if it requires FTP to access?
>
> The RDF data would be downloaded on demand from the file server and for
> instance loaded into a triple store for querying.
>
> @Neill:
>
>
> > What would the Physicians use to key in the data into the form? A laptop
> > or PC/Mac based laptop?
>
> Probably a PC with Windows.
>
>
> > If this is the case there is nothing stopping them running a local copy
> > of MW/SMW and then simply uploading the data to the central instance (a
> > server somewhere I assume) using the normal MW export/import.
>
> True. We just try to avoid the additional effort of managing a local copy
> SMW by having offline forms that create the same RDF as an online filled-in
> form.
>
> I hope that makes our problem clearer.
>
> Best,
>
> Benedikt
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
