Expose file classes in LDP container listing

[rescribet]

Traditionally when rendering a list of files, the OS can associate file types by looking at the extension to determine what to do with the file. In pods, most files are rdf resources, so the information historically provided in the file name is hidden in the file itself (more like a magic number than a file extension).

When rendering a directory index, it would be really useful to have the explicit type statements from ~the file~ the graph's identity resource included in the container index response.

Possible use-cases include rendering proper iconography and doing fast default application without needing to fetch the backing resource beforehand.

Edit: As @elf-pavlik mentioned, a graph can have multiple resources with multiple rdf:type statements, this post is targeting the resource that targets the file (identity resource, turtle relative document <> rdf:type Thing, whatever name).

[elf-pavlik]

I think query mechanism like Quad Pattern Fragments should cover requirements like this one, i see here 2 patterns:

• resources (graphs) contained by container (in other cases members of a collection)
• statements with rdf:type predicate in those graphs

Applications still would need to anticipate that some resources (graphs) will have multiple statements about multiple things (subjects), each may have different rdf:type.

This would provide more general query mechanism, which can allow getting not only statements with rdf:type but also rdfs:label etc.

[michielbdejong]

Hi @fletcher91, there are two sides to this:

• Mapping between on-disk filenames and content-type (see https://github.com/solid/node-solid-server/blob/v5.1.1/lib/resource-mapper.js#L8-L10)
• Triples to include in LDP-BC representation
  • currently only ldp:contains
  • we could definitely add triples to give more meta-data about contained resources
  • such as content-type
  • and whether it's a sub-container or not

If we want clients to rely on it, then this should be described at the spec level, not just in one server implementation.

And we're now only weeks away from switching over from node-solid-server to the new TypeScript code, so we'll probably not make any more code changes to this repo unless it's really hotfix level.

[dmitrizagidulin]

Agreed with everything @michielbdejong said above.

I do think it's a good idea to add file types to LDP listings at the spec level, tho. Should we open a corresponding issue on the spec repo?

[rescribet]

filenames and content-type

such as content-type

add file types to LDP listings

Just for clarity, I specifically referred to the rdf type of the (graph identity) resource rather than the content-type. Resource-type(?), at least not the information encoding algorithm but the semantic classes the file/resource primarily has. The file/content-type would also be useful, but clients could already infer by comparing the name to the IANA extension registry.

If we want clients to rely on it, then this should be described at the spec level, not just in one server implementation.

Completely agree

[michielbdejong]

Ah ok, sorry. Yes, it's a good point, will move this issue to the wac-ldp repo so we can look at implementing this in the TypeScript-based successor of node-solid-server!

[michielbdejong]

Continued in ^