Fuseki2 file upload

[Ian Dickinson <i....@gmail.com>]

Hi Andy,
What's the API for file uploads to F2? I can't see it in the docs**,
and I've failed to puzzle it out from your prototype implementation.
I'm guessing that for dataset foo, I use

/foo/upload

as the destination on the upload form. Is that correct?

Thanks,
Ian

** which could be me - rtfd and a pointer is a good answer :)

Re: Fuseki2 file upload

[Andy Seaborne <an...@apache.org>]

On 09/06/14 12:13, Ian Dickinson wrote:
> On Fri, Jun 6, 2014 at 9:22 AM, Andy Seaborne <an...@apache.org> wrote:
>> The upload is a standard file upload - multipart with a parameter for the
>> graph name (or "default" or empty) and a file content part.
>>
>> The upload approach is problematic at scale:
>>
>> The graph name can come after the file content so you don't know the
>> destination until you see the whole request.  That is, the request needs to
>> be buffered.  And the jquery-fileuploader does seem to send the name after
>> the content.
>
> One way to approach this would be to use the long-running tasks
> infrastructure that you've set up. In the first step, we post a new
> graph name to the /upload endpoint, which returns the URL for
> uploading the graph content to in step 2. Would that work?

What a cunning plan.

A kind of action (with graph name) that creates a destination URL for 
the file upload that is wired to its dataset destination at the start is 
doable.  The URL can include some large unique number to make it 
reasonably secure.

If it could just send the file content, not a browser file upload, the 
URL could be POST to the graph store protocol URL but the file uplaod to 
a magic one-off URL ispretty similar it shouldn't be hard to do at some 
time.

As things stand at the moment, it won't work because long running tasks 
are just monitored for completion, with no web-facing-ness.

For now, shall we stick to the file upload as-is, which is workable for 
small and medium sized files so that this issue is not a blocker?

	Andy

>
>> It would be better to only use the SPARQL Graph Store Protocol for data
>> upload but that's was beyond my capabilities in finite time of dealing with
>> files etc from within the browser.
>
> I don't think you can monkey with the files that are picked by the
> file input control. In general, JavaScript isn't permitted to access
> the contents of files from the browser's host OS.
>
> Ian
>

Re: Fuseki2 file upload

[Ian Dickinson <i....@gmail.com>]

On Fri, Jun 6, 2014 at 9:22 AM, Andy Seaborne <an...@apache.org> wrote:
> The upload is a standard file upload - multipart with a parameter for the
> graph name (or "default" or empty) and a file content part.
>
> The upload approach is problematic at scale:
>
> The graph name can come after the file content so you don't know the
> destination until you see the whole request.  That is, the request needs to
> be buffered.  And the jquery-fileuploader does seem to send the name after
> the content.

One way to approach this would be to use the long-running tasks
infrastructure that you've set up. In the first step, we post a new
graph name to the /upload endpoint, which returns the URL for
uploading the graph content to in step 2. Would that work?

> It would be better to only use the SPARQL Graph Store Protocol for data
> upload but that's was beyond my capabilities in finite time of dealing with
> files etc from within the browser.

I don't think you can monkey with the files that are picked by the
file input control. In general, JavaScript isn't permitted to access
the contents of files from the browser's host OS.

Ian

Re: Fuseki2 file upload

[Andy Seaborne <an...@apache.org>]

On 05/06/14 21:16, Ian Dickinson wrote:
> Hi Andy,
> What's the API for file uploads to F2? I can't see it in the docs**,
> and I've failed to puzzle it out from your prototype implementation.
> I'm guessing that for dataset foo, I use
>
> /foo/upload
>
> as the destination on the upload form. Is that correct?

Yes.

The upload is a standard file upload - multipart with a parameter for 
the graph name (or "default" or empty) and a file content part.

The upload approach is problematic at scale:

The graph name can come after the file content so you don't know the 
destination until you see the whole request.  That is, the request needs 
to be buffered.  And the jquery-fileuploader does seem to send the name 
after the content.

It would be better to only use the SPARQL Graph Store Protocol for data 
upload but that's was beyond my capabilities in finite time of dealing 
with files etc from within the browser.

Caution: I didn't make the jquery fileuploader work properly - I 
couldn't get it to pick up the target URL properly so I tweaked it to 
pull in the URL, rather the rest of the code push it into the right place.

>
> Thanks,
> Ian
>
> ** which could be me - rtfd and a pointer is a good answer :)

Less documented as it's not as stable.  That's my storey.

>