- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Fri, 14 Mar 2014 08:10:22 +0100
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAAOEr1k_XZCp1XszsepMqcpgC3QeNoqcqLvHA0_4cpZpTO1=Gg@mail.gmail.com>
Hi, IIRC, in the previous LC, we had binary/text (non-RDF) resources as non-LDPRs but we decided to move to in to the hierarchy by giving them the name LDP-NR and making them a subclass of LDPR. But this has some implications on the previous restrictions. For instance, *4.2.1.4 LDP servers exposing LDPRs must advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource <http://www.w3.org/ns/ldp#Resource>, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI.* IIRC, in the previous last call we only send this header for only LDP-RS and not for LDP-NR (because they were at the time non-LDPR). Then in the same point, we say *The presence of this header asserts that the server complies with the LDP specification's constraints on HTTP interactions with LDPRs, that is it asserts that the resource has Etags, has an RDF representation, and so on, which is not true of all Web resources served as RDF media types.* Was this intentional ? In that case, do we need to have two separate values identify the two types like we do in containers ? Talking about containers, I think in the example 8, the Link header should be Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type" instead of Link: <http://www.w3.org/ns/ldp#Container>; rel="type". Also regarding the Link header, in 5.2.1.4 we say 'The notes on the corresponding LDPR constraint apply equally to LDPCs.'. So does this mean a container should always advertise two Link headers, e.g. Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" Link: <http://www.w3.org/ns/ldp#Container>; rel="type" I find it a bit redundant as LDPC is a subclass and always a LDP-RS/LDPR but not an issue. Just wanted to make sure as I don't remember all the discussions on client inference vs overhead. Best Regards, Nandana
Received on Friday, 14 March 2014 07:11:09 UTC