- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sun, 25 Mar 2012 10:13:09 +0100
- To: Michael Brunnbauer <brunni@netestate.de>
- Cc: James Leigh <james@3roundstones.com>, public-lod community <public-lod@w3.org>
Hi Michael, On 24 Mar 2012, at 23:16, Michael Brunnbauer wrote: > so every publisher who wants to provide licencing information for his RDF has > to either > > 1) use 303 redirects > 2) publish no data at the NIR except the describedby triples, which seems pointless to me They can publish whatever data they like at the NIR. > 3) use the same URI for the IR and the NIR This isn't best practice, as it isn't today. But of course people do it, just as they conflate different meanings for any URI. > If he also wants to provide meta information for his HTML, he cannot > publish the HTML at the NIR. I don't see a new and easier option offered by > the proposal. In the end, people will do what they already do today. Yes, some publishers who are publishing according to the current specs (with 303 redirections being their only option) might continue to do what they do today. Others, as I have explained previously, may prefer to use 200 responses so that they can use the main (NIR) URI everywhere in their web application, while retaining the other responses that they already support for semantic web purists to access. Publishers who are not today using 303s but are nevertheless minting URIs which identify NIRs (ie those outside the semantic web community) will also continue to do what they do today. The difference is that we (semantic web purists) will no longer be constantly telling them that they're Doing It Wrong, but will be able to build consumers that cope with this reality. > BTW: The POWDER describedby property suggests that you will find some > information about the subject of the describedby triple when you dereference > the object URI but this does not seem to be intended here. Wrong. The documents that are said to describe a URI should still describe that URI. > POWDER with it's > power to assert metadata for whole collections of IRs also probably will > contribute to the IR/NIR conflation. > > I think we should leave everything as it is and just don't blame publishers > who conflate IRs and NIRs. Sooner or later, they probably will fix it all. I agree we shouldn't blame publishers who conflate IRs and NIRs. That is not what happens at the moment. Therefore we need to change something. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Sunday, 25 March 2012 09:13:33 UTC