Re: Real-world concept URIs

Hi Pieter,

I disagree, pending clarification.

If the transportation costs of (RESTful) URI's - an Ontology - between Top Level Domains TLD is Zero - more specifically exp(Zero)-1="Zero", then the URI's are entangled (as in "Quantum Entanglement").  In this case, the  URI's are not "broken", but rather the URL's are NOT entangled, they are distinct TLD's.

Alternate synthesis:
"bicycle" needs 2 URI's (ownership and fuel)
"Porsche" needs 2 URI's (ownership and fuel)

A bicycle with nobody to pedal it and a Porsche with no gas both obey Newton's First Law, which is quite "Real World".

--Gannon
--------------------------------------------
On Wed, 7/16/14, Pieter Colpaert <pieter.colpaert@ugent.be> wrote:

 Subject: Real-world concept URIs
 To: "public-lod@w3.org community" <public-lod@w3.org>
 Date: Wednesday, July 16, 2014, 8:55 AM
 
 Hi list,
 
 Short version:
 
 I want real-world concepts to be able to have a URI without
 a "http://". 
 You cannot transfer any real-world concept over an Internet
 protocol 
 anyway. Why I would consider changing this can be
 
   * If you don't agree, why?
   * If you do agree, should we change the definition of
 a URI? Will this 
 break existing Linked Data infrastructure?
 
 Long version:
 
 I'm overlooking the development of a hypermedia application*
 at a server 
 which redirects all http://{foobar} URIs towards
 https://{foobar}. 
 Furthermore, in order to make a distinction between
 real-world objects 
 and their representation, I have added "#object" at the end
 of the URIs 
 for the real-world objects in the store behind it.
 
 Now I have to explain these developers that each time a
 request is done 
 on the website, they will have to look up what the requested
 URI was, 
 then substitute https:// with http:// and then concatenate
 "#object" to 
 the URI, in order to be able to find statements which will
 be useful in 
 the application. The reason behind this is of course the
 real-world 
 objects which cannot be retrieved over HTTP, yet the
 representation has 
 a different URI, which is automatically generated as
 everything starting 
 at "#" gets deleted anyway.
 
 Now I also have to convince another reuser of the data, a
 native 
 application builder, that he should use these URIs with
 http:// and 
 "#object". Inside his application, he does have his own
 style of 
 identifiers, which looks very close to URIs, the only thing
 that lacks 
 is the protocol. So I've asked him to add the protocol to
 the URIs for 
 real-world objects and add "#object" at the end. He ended up
 giving me 
 something with "https://" in the beginnen. Which makes a lot
 of sense: 
 that's what works on the Web, but sadly not in my store.
 
 This process could have been a lot simpler with a tiny
 change: allowing 
 URIs identifying real-world objects not to have a protocol.
 Why would 
 you add http:// to something you cannot GET anyway? What if
 we would 
 allow our real-world URI to be just {foobar} and the URI of
 the 
 representation being http://{foobar} or https://{foobar}?
 Now the 
 developers just have to remove the protocol in order to find
 useful 
 triples about what the client requested in the store.
 
 This would make sense in a lot of cases: e.g., my
 organization is 
 ugent.be, and its Web representation can be found at http://ugent.be.
 
 Filling out ugent.be in a browser will automatically refer
 you to its 
 representation.
 
 Your thoughts?
 
 Kind regards,
 
 Pieter
 
 * This application I'm working on: http://iRail.be

Received on Thursday, 17 July 2014 16:17:35 UTC