Bundle "folder" should be URI escaped

[stain]

A confusion point has been identified for the bundledAs section:

folder
A folder in the bundle this resource belongs to. This member MUST be present if filename is given, and MAY be present alone. The path SHOULD be prefixed with / and SHOULD end with /, for instance /folder2/ or /. The folder SHOULD be a directory in the zip archive.

This item is interpreted in JSON-LD as a URI reference, and so should be URI escaped just like uri, e.g. "/folder/with%20spaces".

On the other hand (and perhaps confusing), filename is just the value of the filename within the folder, and should NOT be URI escaped. This is not clearly indicated, although it does say:

The filename should not contain the characters /, : or , but MAY contain spaces and international characters.

[stain]

@gambl and @hainesr are suggesting to me that perhaps having a single attribute "filepath" with no escaping would be easier - and link to the restrictions on filenames in ZIP -

https://www.pkware.com/documents/casestudies/APPNOTE.TXT says:

D.2 If general purpose bit 11 is unset, the file name and comment should conform to the original ZIP character encoding. If general purpose bit 11 is set, the filename and comment must support The Unicode Standard, Version 4.1.0 or greater using the character encoding form defined by the UTF-8 storage specification. The Unicode Standard is published by the The Unicode Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files is expected to not include a byte order mark (BOM).
(..)
4.4.10 file name length: (2 bytes)
4.4.11 extra field length: (2 bytes)
4.4.12 file comment length: (2 bytes)

The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields should not generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero.
(..)
4.4.17 file name: (Variable)
4.4.17.1 The name of the file, with optional relative path. The path stored MUST not contain a drive or
device letter, or a leading slash. All slashes MUST be forward slashes '/' as opposed to backwards slashes '' for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field.

[stain]

My reason for splitting folder and filename was to be able to 'list the content of a folder'. Thus 'folder' became a resource (also it might exist as a real folder in the zip) - while filename was just an attribute. If we merge them, then you will have to resolve ./ from the bundledAs -> filepath to find the folder - which is not very easy in say SPARQL.

[stain]

The spec leaves the possibility open for a 'virtual file' to have the same filename as a 'bundled file'. Our current bundledAs spec does not put any uniqueness requirements on this filename. Is this an issue? We don't require folder and filename - it's more like a logical grouping thing. We don't say it, but it's implied that if there is no folder and filename specified, you can list the resource according to its uri

[hainesr]

I'd prefer to keep folder and filename separate.

I do think that, given these attributes would be used to build a logical filespace, that we should treat them in the same way that other filenames are treated in the ZIP spec - so have the same restrictions on characters, etc as the APPNOTE says.