- From: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
- Date: Mon, 13 Nov 2023 12:15:16 +0100
- To: public-webid <public-webid@w3.org>
- Message-ID: <0c3e000f-cd2c-4cf4-bd0e-6749670be2e3@informatik.uni-leipzig.de>
Dear all, I took on the quest to sort out some basic issues that I see with RDF (R=Resource) and Resources as defined by HTTP. This is an effort to remove serious limitations that I see with the current way of operating Linked Data. I am not saying that it's broken, just that it makes serious implementation decisions that cripple REST and HATEOAS. Mainly by typing URIs or HTTP resources as "Documents". One of the basic issues is that HTTP and the Web stopped using a "document" model with the introduction of REST (should be between 1996 / 2000). Resources are "interfaces". RFC 9110 should be the latest: https://www.rfc-editor.org/rfc/rfc9110.html Clarification: this is not about 303 or HR14. It's solely about '#' URIs. foaf:Document as a superclass of foaf:ProfileDocument says this: We do not (currently) distinguish precisely between physical and electronic documents, or between copies of a work and the abstraction those copies embody. The relationship between documents and their byte-stream representation needs clarification (see |foaf:sha1 <http://xmlns.com/foaf/0.1/#term_sha1>| for related issues). Here is an honest question: If I have http://example.com/res#me that behaves like this: curl -H "Accept: text/turtle" http://examples.com/res 200 OK Content-Type: text/turtle <http://examples.com/res#me> a foaf:Person . and curl -H "Accept: application/n-triples" http://examples.com/res 200 OK Content-Type: application/n-triples <http://examples.com/res#me> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> . I would like to add an rdf:type statement describing http://examples.com/res and a statement describing the relation of http://examples.com/res to http://examples.com/res#me, so in turtle, I would like to add: <http://examples.com/res> rdf:type ? <http://examples.com/res> ? <http://examples.com/res#me> or other direction <http://examples.com/res#me> ? <http://examples.com/res> As an extended question, I would again have content negotiation like above, but this time Content-Location is used in two different ways: curl -H "Accept: text/turtle" http://examples.com/res 200 OK Content-Type: text/turtle Content-Location: http://examples.com/res.ttl <http://examples.com/res#me> a foaf:Person . as well as with a git commit hash. curl -H "Accept: text/turtle" http://examples.com/res 200 OK Content-Type: text/turtle Content-Location: http://examples.com/f73dfab067d4b4462aa3a6e9b6075788c52fdd00/res.ttl <http://examples.com/res#me> a foaf:Person . The question would be analogous, but in addition clarifying the additional relations between res/#me and the Content-Location URI : <http://examples.com/res> a ? . <http://examples.com/res> ? <http://examples.com/res.ttl> . <http://examples.com/res> ? <http://examples.com/res#me> . <http://examples.com/res.ttl> a ? <http://examples.com/res#me> ? <http://examples.com/res.ttl> . and <http://examples.com/res> a ? . <http://examples.com/res> ? <http://examples.com/f73dfab067d4b4462aa3a6e9b6075788c52fdd00/res.ttl> . <http://examples.com/res> ? <http://examples.com/res#me> . <http://examples.com/f73dfab067d4b4462aa3a6e9b6075788c52fdd00/res.ttl> a ? <http://examples.com/res#me> ? <http://examples.com/f73dfab067d4b4462aa3a6e9b6075788c52fdd00/res.ttl> . It is an honest question as I really don't know where I would actually put the foaf:profileDocument. There are several ways to implement it due to HTTP Semantics and REST. Many, many more ways than these three in fact. HATEAOS should allow to evolve/switch implementations naturally, with clients adapting in a generic manner to change, but I also do currently not know how this would work in detail. More issue here: 1. RDF Statements about representations: http://examples.com/f73dfab067d4b4462aa3a6e9b6075788c52fdd00/res.ttl is also a URI, i.e. an interface with the special case that it is designed only to deliver exactly one representation, i.e. the state of the resource after the commit. The question would be how to describe the representation in RDF, because URI != representation, right? How would I make an RDF Statement referring to the representation not the URI delivering the representation? 2. RDF statements about the graph. There seems to be an abstract graph and serialized graphs. What would be the URI to use in the subject of an RDF statement? Might be http://examples.com/res as the HTTP resource here is the graph, right? 3. [solved] Fragment Identifiers: RFC 9110 copied from the URI Generic Syntax RFC 3986: "Fragment identifiers allow for indirect identification of a secondary resource, independent of the URI scheme, as defined in Section 3.5 <https://www.rfc-editor.org/rfc/rfc3986#section-3.5> of [URI <https://www.rfc-editor.org/rfc/rfc9110.html#URI>]." Actually this part is crystal clear. The URI minter assigns social meaning to the "#" URI. RDF can pick that up to describe it. A note: I am reading Linked Data Plattform again https://www.w3.org/TR/ldp/ However, I really take issue with this standard as it introduces yet again more unclear terminology that I can neither map well to HTTP Semantics nor to RDF. I think they are mixing everything together: Link A relationship between two resources when one resource (representation) refers to the other resource by means of a URI [WEBARCH <https://www.w3.org/TR/ldp/#bib-WEBARCH>]. Linked Data Platform Resource (LDPR) A HTTP resource whose state is represented in any way that conforms to the simple lifecycle patterns and conventions in section 4. Linked Data Platform Resources <https://www.w3.org/TR/ldp/#ldpr>. Linked Data Platform RDF Source (LDP-RS) An LDPR <https://www.w3.org/TR/ldp/#dfn-linked-data-platform-resource> whose state is fully represented in RDF, corresponding to an RDF graph. See also the term RDF Source <http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source> from [rdf11-concepts <https://www.w3.org/TR/ldp/#bib-rdf11-concepts>]. Linked Data Platform Container (LDPC) A LDP-RS representing a collection of linked documents (RDF Document <http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document> [rdf11-concepts <https://www.w3.org/TR/ldp/#bib-rdf11-concepts>] or information resources [WEBARCH <https://www.w3.org/TR/ldp/#bib-WEBARCH>]) that responds to client requests for creation, modification, and/or enumeration of its linked members and documents, and that conforms to the simple lifecycle patterns and conventions in section 5. Linked Data Platform Containers <https://www.w3.org/TR/ldp/#ldpc>. Where as RDF Document is defined as sth. that would be considered a "representation" in HTTP, see https://www.w3.org/TR/rdf11-concepts/#rdf-documents An RDF document is a document that encodes an RDF graph <https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-graph> or RDF dataset <https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-dataset> in a concrete RDF syntax, such as Turtle [TURTLE <https://www.w3.org/TR/rdf11-concepts/#bib-TURTLE>], RDFa [RDFA-PRIMER <https://www.w3.org/TR/rdf11-concepts/#bib-RDFA-PRIMER>], JSON-LD [JSON-LD <https://www.w3.org/TR/rdf11-concepts/#bib-JSON-LD>], or TriG [TRIG <https://www.w3.org/TR/rdf11-concepts/#bib-TRIG>]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems. If you unfold LDPC it becomes an LDP-RS, which is an LDP-R, which is a resource in HTTP. Thus becoming a "Resource in HTTP that represents a collection of linked RDF representations or other information resources. " However, information resources in WebArch is congruent to HTTP and defines "The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as “information resources.” I understand how you can build a collection of URIs or a collection of messages/representations, but I don't get how you can use a Resource to represent a collection of resources. I also wouldn't know how you would link RDF Documents (the representation) without URIs. I really feel like William of Baskerville from the Name of the Rose, when reading LDP, which seems to have had the intention to clarify my issues above. Sorry for the long email. I just feel that we really need to solve this (practically and with good terminology), then break it down into correct ways of implementing WebID for everybody. All the best, Sebastian
Received on Monday, 13 November 2023 11:16:00 UTC