As used by Luca, "the animal zebra" is not a real world thing either: it's a
man-made concept, or possibly a "form" (Plato -
http://en.wikipedia.org/wiki/Theory_of_Forms ). It's a classification applied
to a number of individual things that have common characteristics (black and
white stripes, hooves, a certain DNA signature). Such individual things do not
necessarily need to be "real world" either - e.g. the flying horse Pegasus.
And the concept/classification "zebra" does not have a length either. Unless
one means something like "The average length of an adult male zebra is 250cm".
Even then it's not the concept that has a (average) length: that requires you
to have a specific individual zebra in mind (or a set of them if talking about
averages).
Pete
Pete Rivett (pete.riv...@adaptive.com)
CTO, Adaptive Inc
9861 Irvine Center Drive Suite 200, Irvine, CA 92618
cell: +1 949 338 3794
Follow me on Twitter @rivettp or http://twitter.com/rivettp
-Original Message-
From: David Booth [mailto:da...@dbooth.org]
Sent: Thursday, July 17, 2014 11:18 AM
To: public-lod@w3.org
Subject: Re: Real-world concept URIs
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
> 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 woul
