Recommended reading would be "Cool URIs for the Semantic Web":
http://www.w3.org/TR/cooluris/
In spite of the advice in that document, people can and sometimes do use
the same URI for both the real world entity (such as a zebra) and the
document that describes that zebra. Doing so may be expedient for the
URI owner and some users of that URI, but it also causes URI collision
http://www.w3.org/TR/webarch/#URI-collision
that may be detrimental to other users of that URI who wish to
distinguish between the zebra and the page that describes the zebra.
For example, the zebra may have a length of 250 cm, but the page
describing that zebra may have a length of 2500 bytes.
David
On 07/17/2014 11:16 AM, Luca Matteis wrote:
I never really understood the difference between real world objects
and their representations. I've never had to talk about the
representation of something, so I always just dealt with real world
URIs. I have http://zebra. For me http://zebra represents the animal
zebra. If people want to know what it is, they resolve it. Done. When
do people need to refer to the "document" or the representation of the
animal zebra?
On Wed, Jul 16, 2014 at 3:55 PM, Pieter Colpaert
<pieter.colpa...@ugent.be> wrote:
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
