remove .ttl from RDFSource URIs

[elf-pavlik]

https://www.w3.org/TR/webarch/#uri-opacity

Resource state may evolve over time. Requiring a URI owner to publish a new URI for each change in resource state would lead to a significant number of broken references. For robustness, Web architecture promotes independence between an identifier and the state of the identified resource.

While some server implementations might start using persistence like https://github.com/rdf-ext/rdf-store-fs they might later change to quad stores, document stores or IPFS and use RDF Dataset Normalization.

Suggesting particular media type / file format in URIs looks like not following Web achitecture good practice.

BTW https://github.com/solid/solid-spec/blob/c9f6ba28315efcd467aa2057bff75fadaa59cf55/solid-webid-profiles.md

/profile/card - their primary (public-readable) WebID Profile...

already uses card not card.ttl!

[dmitrizagidulin]

I agree with the proposal. I think we should fix nodeSolidServer/node-solid-server#275 (ldnode currently relies on file extensions to preserve content type) first. But should merge after that.

[elf-pavlik]

@timbl also discourages including file extension in URI in https://www.w3.org/Provider/Style/URI
Sections:

• What to leave out (no anchor to link to it)
• How can I remove the file extensions...

[elf-pavlik]

Noticing nodeSolidServer/node-solid-server#445

I would like to clarify if solid spec requires a server to store RDFSource payload of POST/PUT exactly as received, or server can choose to store it in quad store, or as Normalized RDF.

I hope that solid clients will never rely on 'file extensions' and always rely on HTTP headers (Content-Type & Accept). So if https://github.com/solid/node-solid-server/ relies on file extensions it stays as its internal implementation choice and not recommendation of the spec.

[melvincarvalho]

In modern systems, URIs tend to be opaque, so it should not matter all that much.

However when choosing a name there are certain advantages to adding the .ttl suffix. Apart from that it is intuitive, less modern systems such as github will correctly interpret the extension and serve the correct content type header.

[elf-pavlik]

already 2 years have passed, I consider just closing this PR as part of spring cleanup...

[melvincarvalho]

@elf-pavlik thanks for flagging this, and for the creation of PR.

As noted, there is some non trivial, re architecture of node solid server that would change how we deal with extensions and content negotiation

Also related is this new issue : nodeSolidServer/node-solid-server#645

We can close this if you are more happy that way, or keep it open and change the docs after the re architecture is complete.

[elf-pavlik]

Thank you @melvincarvalho

I'll leave this one here open and will also follow issue you've linked

[elf-pavlik]

As noted, there is some non trivial, re architecture of node solid server that would change how we deal with extensions and content negotiation

LDP spec has MUST for both text/turtle and application/ld+json for RDFSources. I think Solid can respect that so each RDFSource should at least allow negotiating for those two content types.

[RubenVerborgh]

I think Solid can respect that so each RDFSource should at least allow negotiating for those two content types.

Yes. There is a conneg difficulty at the moment, but extensionless files are interpreted as Turtle (which is the conneg issue, but works to our advantage here).

[melvincarvalho]

4.3.2 HTTP GET

4.3.2.1 LDP servers must respond with a Turtle representation of the requested LDP-RS when the request includes an Accept header specifying text/turtle, unless HTTP content negotiation requires a different outcome [turtle].

Non-normative note: In other words, Turtle must be returned by LDP servers in the usual case clients would expect (client requests it) as well as cases where the client requests Turtle or other media type(s), content negotiation results in a tie, and Turtle is one of the tying media types. For example, if the Accept header lists text/turtle as one of several media types with the highest relative quality factor (q= value), LDP servers must respond with Turtle. HTTP servers in general are not required to resolve ties in this way, or to support Turtle at all, but LDP servers are. On the other hand, if Turtle is one of several requested media types, but another media type the server supports has a higher relative quality factor, standard HTTP content negotiation rules apply and the server (LDP or not) would not respond with Turtle.

4.3.2.2 LDP servers should respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent [turtle].

4.3.2.3 LDP servers must respond with a application/ld+json representation of the requested LDP-RS when the request includes an Accept header, unless content negotiation or Turtle support requires a different outcome [JSON-LD].

https://www.w3.org/TR/ldp/#ldprs-get-turtle

The spec says turtle first, then json-ld, which is the order node solid server has done it. I agree with Ruben it's to our advantage, in this case. I've had good experiences with turtle data.

[elf-pavlik]

Yes. There is a conneg difficulty at the moment, but extensionless files are interpreted as Turtle (which is the conneg issue, but works to our advantage here).

In that case merging this PR will not result in IRIs which would not work with node-solid-server. I could create separate issue in that repo to not use .ttl for resources auto generated when creating new account.

4.3.2.3 LDP servers must respond with a application/ld+json representation of the requested LDP-RS when the request includes an Accept header, unless content negotiation or Turtle support requires a different outcome [JSON-LD].

I think for request with just Accept: application/ld+json it MUST respond with JSON-LD. It may respond with Turtle in case of multiple mime types in Accept header and turtle and json-ld have tie.

[elf-pavlik]

I still stand behind changes proposed in this now 3 years old PR 👴

[Mitzi-Laszlo]

Please add your suggestions on routes forward and your thoughts on the pros and cons of each to the following table:

Route Forward	Pros to Consider	Cons to Consider
Merge this PR and don't use 'file extensions' in any URLs used in the spec, at least RDFSources	* Following referenced Web Architecture best practice, and avoiding confusion when RDFSources allow content negotiation	(insert suggestion)

[elf-pavlik]

Route Forward: Merge this PR and don't use 'file extensions' in any URLs used in the spec, at least RDFSources

Pros to Consider: Following referenced Web Architecture best practice, and avoiding confusion when RDFSources allow content negotiation

Const to Consider: I don't see any cons

[angelo-v]

I second @elf-pavlik's proposal