Re: Real-world concept URIs

[Pieter Colpaert]

Hi Kingsley,

Thank you very much for your reply! Very satisfied with this response. 
This answer should be in text books.


I would summarize this thread as:

Question: Why do we refer to real-world concepts using HTTP URIs? You 
cannot GET them over HTTP anyway?
Answer: Because words denote things. The World Wide Web's architecture, 
via HTTP URIs, caters to the natural language needs of denotation, 
connotation using sentences or statements.


Kind regards,

Pieter


On 2014-07-18 13:12, Kingsley Idehen wrote:

On 7/16/14 9:55 AM, 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? 


Pieter,

Short response:

Words denote things.

Terms are words with the added quality of meaning de-reference 
(lookup) i.e., they have the combined qualities of denotation and 
connotation resolution.


A word and a term are slightly different [1].

In natural language (system of signs, syntax, and relation semantics) 
you construct sentences and statements using words and terms, 
respectively.


The World Wide Web's architecture, via HTTP URIs, caters to the 
natural language needs of denotation, connotation using sentences or 
statements.


RDF enables the use of IRIs (as words) to denote things (entities) 
described using sentences.


RDF based Linked Data specifically enables the use of HTTP URIs (as 
terms) to denote things (entities) described using statements.


Longer response:

"Pieter" denotes entity "You". How do I obtain a description of you 
via the Web medium without an HTTP URI that denotes you in such a way 
that when said URI is looked up  get a document back that describes you?


From this post, I can discern the following:

1. "Pieter" is your first-name.
2. "Colpaert" is your last-name.
3.  is your Email address -- you have 
a mailbox provided by a mail server denoted by the DNS identifier 
 .


I could make a concise machine and human comprehensible description of 
you as follows:


## Turtle Start ##
<>
 
;

 "About: Pieter Colpaert" ;
 """Information gleaned 
from an LOD mailing list thread about Pieter Colpaert""" ;

<#PieterColpaert> ;
  .

<#PieterColpaert>
 
 ;

 "Pieter Colpaert" ;
  .

## Turtle End ##

Conclusion:

The architecture of the Web (AWWW) isn't the problem, so we don't need 
to change anything. If you want to provide application / service 
specific tweaks to users (end-users or developers) simply build those 
into the relevant solution, by simply leveraging what the underlying 
architecture of the Web offers to you.


A Web Document is a connotation vehicle. Like a piece of paper, so to 
speak. Its something totally distinct from:


[1] what's denoted by an identifier
[2] what's described using a sentence or statement.

If we couldn't use our senses to distinguish between a movie 
projection canvas and an actual motion picture, how would we even make 
out the movie from the projection canvas? The Web is just another 
medium in which old rules (which existed before its creation) still 
apply.


BTW -- "httpRange-14" denotes an overrated distraction that blurs the 
fact that all we are dealing with here (i.e., in regards to Web 
Architecture) are age-old concepts such as:


1. entities
2. entity denotation
3. entity connotation
4. entity relations
5. encoding and decoding of information .

Links:

[1] http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word -- 
difference between a Word and a Term

[2] http://slidesha.re/QEqLZN -- RDF and Natural Language
[3] http://bit.ly/WAJGCp -- Global Identifiers & Denotation in a 
single slide .

Re: Real-world concept URIs

[Kingsley Idehen]

On 7/16/14 9:55 AM, 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? 


Pieter,

Short response:

Words denote things.

Terms are words with the added quality of meaning de-reference (lookup) 
i.e., they have the combined qualities of denotation and connotation 
resolution.


A word and a term are slightly different [1].

In natural language (system of signs, syntax, and relation semantics) 
you construct sentences and statements using words and terms, respectively.


The World Wide Web's architecture, via HTTP URIs, caters to the natural 
language needs of denotation, connotation using sentences or statements.


RDF enables the use of IRIs (as words) to denote things (entities) 
described using sentences.


RDF based Linked Data specifically enables the use of HTTP URIs (as 
terms) to denote things (entities) described using statements.


Longer response:

"Pieter" denotes entity "You". How do I obtain a description of you via 
the Web medium without an HTTP URI that denotes you in such a way that 
when said URI is looked up  get a document back that describes you?


From this post, I can discern the following:

1. "Pieter" is your first-name.
2. "Colpaert" is your last-name.
3.  is your Email address -- you have a 
mailbox provided by a mail server denoted by the DNS identifier 
 .


I could make a concise machine and human comprehensible description of 
you as follows:


## Turtle Start ##
<>
 
;

 "About: Pieter Colpaert" ;
 """Information gleaned 
from an LOD mailing list thread about Pieter Colpaert""" ;

<#PieterColpaert> ;
  .

<#PieterColpaert>
 
 ;

 "Pieter Colpaert" ;
  .

## Turtle End ##

Conclusion:

The architecture of the Web (AWWW) isn't the problem, so we don't need 
to change anything. If you want to provide application / service 
specific tweaks to users (end-users or developers) simply build those 
into the relevant solution, by simply leveraging what the underlying 
architecture of the Web offers to you.


A Web Document is a connotation vehicle. Like a piece of paper, so to 
speak. Its something totally distinct from:


[1] what's denoted by an identifier
[2] what's described using a sentence or statement.

If we couldn't use our senses to distinguish between a movie projection 
canvas and an actual motion picture, how would we even make out the 
movie from the projection canvas? The Web is just another medium in 
which old rules (which existed before its creation) still apply.


BTW -- "httpRange-14" denotes an overrated distraction that blurs the 
fact that all we are dealing with here (i.e., in regards to Web 
Architecture) are age-old concepts such as:


1. entities
2. entity denotation
3. entity connotation
4. entity relations
5. encoding and decoding of information .

Links:

[1] http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word -- 
difference between a Word and a Term

[2] http://slidesha.re/QEqLZN -- RDF and Natural Language
[3] http://bit.ly/WAJGCp -- Global Identifiers & Denotation in a single 
slide .


--
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web:http://www.openlinksw.com
Personal Weblog 1:http://kidehen.blogspot.com
Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen
Twitter Profile:https://twitter.com/kidehen
Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile:http://www.linkedin.com/in/kidehen
Personal WebID:http://kingsley.idehen.net/dataspace/person/kidehen#this




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Real-world concept URIs

[Gannon Dick]

Right you are Paul.  I live in Texas.  Mexico does not want us back after what 
we did to their food, but if they find out what we do to Spanish I predict they 
will be building fences at the border.

IMHO, this whole catastrophe could be avoided if Google Translate spoke Zebra.  
Is it just me?
--Gannon

On Thu, 7/17/14, Paul Houle  wrote:

 Subject: Re: Real-world concept URIs
 To: "Gannon Dick" 
 Cc: "Ruben Verborgh" , "Luca Matteis" 
, "Pieter Colpaert" , 
"public-lod@w3.org community" 
 Date: Thursday, July 17, 2014, 3:15 PM
 
 I can't speak for
 other countries in North, South and Central America,
  but I can say the that United States does not
 have an "official"
 language, 
 even though people who hate immigrants wish it did.
 ᐧ
 
 On Thu, Jul 17, 2014 at
 3:30 PM, Gannon Dick 
 wrote:
 >
 >
 >  > If we want to differentiate
 between
 >  >     "I
 like the
 >  zebra";
 >  >     "I
 >  don't like the document about the
 zebra".
 >
 >  But
 why do they need to be on
 >  the same
 domain? Several parties on
 >  different
 domains can represent information
 > 
 about the animal zebra.
 >  They just
 seem like
 >  different things to me.
 >
 >
 ===
 > There is a
 "what's the problem again ?" component to the
 problem (rinse, repeat).
 >
 > As evidence, I offer two factoids:
 > a) The EU has 24 "Official"
 languages (http://europa.eu/)
 >
 b) Americans speak 100+ languages at home 
(http://www.census.gov/hhes/socdemo/language/)
 and have one "Official" language.
 >
 > It seems to me those
 are two solutions to the problem.
 >
 What's the problem again ? :-)
 >
 > --Gannon
 >
 >
 >
 
 
 
 -- 
 Paul Houle
 Expert on Freebase,
 DBpedia, Hadoop and RDF
 (607) 539 6254   
 paul.houle on Skype   ontolo...@gmail.com

Re: Real-world concept URIs

[Paul Houle]

I can't speak for other countries in North, South and Central America,
 but I can say the that United States does not have an "official"
language,  even though people who hate immigrants wish it did.
ᐧ

On Thu, Jul 17, 2014 at 3:30 PM, Gannon Dick  wrote:
>
>
>  > If we want to differentiate between
>  > "I like the
>  zebra";
>  > "I
>  don't like the document about the zebra".
>
>  But why do they need to be on
>  the same domain? Several parties on
>  different domains can represent information
>  about the animal zebra.
>  They just seem like
>  different things to me.
>
> ===
> There is a "what's the problem again ?" component to the problem (rinse, 
> repeat).
>
> As evidence, I offer two factoids:
> a) The EU has 24 "Official" languages (http://europa.eu/)
> b) Americans speak 100+ languages at home 
> (http://www.census.gov/hhes/socdemo/language/) and have one "Official" 
> language.
>
> It seems to me those are two solutions to the problem.
> What's the problem again ? :-)
>
> --Gannon
>
>
>



-- 
Paul Houle
Expert on Freebase, DBpedia, Hadoop and RDF
(607) 539 6254paul.houle on Skype   ontolo...@gmail.com

Re: Real-world concept URIs

[Gannon Dick]

 > If we want to differentiate between
 >     "I like the
 zebra";
 >     "I
 don't like the document about the zebra".
 
 But why do they need to be on
 the same domain? Several parties on
 different domains can represent information
 about the animal zebra.
 They just seem like
 different things to me.

===
There is a "what's the problem again ?" component to the problem (rinse, 
repeat).

As evidence, I offer two factoids:
a) The EU has 24 "Official" languages (http://europa.eu/)
b) Americans speak 100+ languages at home 
(http://www.census.gov/hhes/socdemo/language/) and have one "Official" language.

It seems to me those are two solutions to the problem.
What's the problem again ? :-)

--Gannon
 

RE: Real-world concept URIs

[Pete Rivett]

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

Re: Real-world concept URIs

[Nandana Mihindukulasooriya]

Hi Pieter,

On Thu, Jul 17, 2014 at 7:36 PM, Pieter Colpaert 
wrote:

>  Hi Nandana,
>
> Thank you a lot for your clear reply!
>
>
> On 2014-07-17 19:17, Nandana Mihindukulasooriya wrote:
>
> Hi Pieter,
>
>  If we still stick with URIs (as a name but not a locator) [1] but with a
> different scheme, say "things" or something, your solution will still work
> the same, right? There are already URN/DOI to URL resolvers [3], so
> similarly but rather than using a service, your URIs identifying real world
> things will use a convention to resolve them to information resources by
> converting, say things:{foobar} to http://{foobar}, when one have to do a
> lookup.
>
>
> Correct! "thing:" could be the protocol of the real world: thing:A can
> shake hands with thing:B, http://A can serve the fact that thing:A shook
> hands with thing:B over HTTP. I like it!
>

Apparently this has been considered and discarded with the argument of
building the Semantic Web on top of what was already available back then.
http://www.w3.org/DesignIssues/HTTP-URI.html#L920

Along with the URI collision that David Booth pointed out, we have
the Indirect Identification use case (i.e., the context defines what the
URI identifies). Probably this works well for humans but not so well for
machines.
http://www.w3.org/TR/webarch/#indirect-identification

Best Regards,
Nandana

Re: Real-world concept URIs

[David Booth]

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 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

Re: Real-world concept URIs

[Ruben Verborgh]

> But why do they need to be on the same domain?

They don't need to be.

> Several parties on
> different domains can represent information about the animal zebra.
> They just seem like different things to me.

They are, indeed.

Re: Real-world concept URIs

[Luca Matteis]

On Thu, Jul 17, 2014 at 7:29 PM, Ruben Verborgh  wrote:
> If we want to differentiate between
> "I like the zebra";
> "I don't like the document about the zebra".

But why do they need to be on the same domain? Several parties on
different domains can represent information about the animal zebra.
They just seem like different things to me.

Re: Real-world concept URIs

[Pieter Colpaert]

Hi Nandana,

Thank you a lot for your clear reply!

On 2014-07-17 19:17, Nandana Mihindukulasooriya wrote:

Hi Pieter,

If we still stick with URIs (as a name but not a locator) [1] but with 
a different scheme, say "things" or something, your solution will 
still work the same, right? There are already URN/DOI to URL resolvers 
[3], so similarly but rather than using a service, your URIs 
identifying real world things will use a convention to resolve them to 
information resources by converting, say things:{foobar} to 
http://{foobar}, when one have to do a lookup.


Correct! "thing:" could be the protocol of the real world: thing:A can 
shake hands with thing:B, http://A can serve the fact that thing:A shook 
hands with thing:B over HTTP. I like it!




In my opinion it probably it could have been an alternative solution 
to the http-range-14 [4,5] issue and provide a clear separation of 
information resources and real world things.


Indeed.

However, the challenge is to have everyone agree to this convention 
and as we have so many real world things already named using HTTP 
URIs, I am not sure whether it will be a practical solution right now.


There are indeed already a lot of things named using HTTP URIs, and that 
is okay. Nothing will break :)


Kind regards,

Pieter

Re: Real-world concept URIs

[Ruben Verborgh]

> When
> do people need to refer to the "document" or the representation of the
> animal zebra?

If we want to differentiate between
"I like the zebra";
"I don't like the document about the zebra".

Or more real-world examples:
a document about Barack Obama has a different creation date
than Barack Obama himself.

Best,

Ruben

Re: Real-world concept URIs

[Nandana Mihindukulasooriya]

Hi Pieter,

If we still stick with URIs (as a name but not a locator) [1] but with a
different scheme, say "things" or something, your solution will still work
the same, right? There are already URN/DOI to URL resolvers [3], so
similarly but rather than using a service, your URIs identifying real world
things will use a convention to resolve them to information resources by
converting, say things:{foobar} to http://{foobar}, when one have to do a
lookup.

In my opinion it probably it could have been an alternative solution to the
http-range-14 [4,5] issue and provide a clear separation of information
resources and real world things. However, the challenge is to have everyone
agree to this convention and as we have so many real world things already
named using HTTP URIs, I am not sure whether it will be a practical
solution right now.

Luca,
In addition what Pieter said, sometimes we have add licences to the
information resource so that the information about Zebra is given in a free
open licence [for the Zebra you will have to pay :)], and history of the
document (not the Zebra), owener of the document (not the Zebra), etc. So
IMO there is a need to identify and name the information resource and real
world thing separately.

Best Regards,
Nandana

[1] - http://tools.ietf.org/html/rfc3986#section-1.1.3
[2] - http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[3] - http://nbn-resolving.de/
[4] - http://norman.walsh.name/2005/06/19/httpRange-14
[5] - https://plus.google.com/109693896432057207496/posts/Q7pCA6yqNtS

On Wed, Jul 16, 2014 at 5:29 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?
>

Re: Real-world concept URIs

[Gannon Dick]

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  wrote:

 Subject: Real-world concept URIs
 To: "public-lod@w3.org community" 
 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
 
 

Re: Real-world concept URIs

[Pieter Colpaert]

Hi Luca,

Thank you for your reply.

An example why you would need it is to add more statements for e.g., 
hypermedia applications which need to know how to navigate. For 
instance, our zebra has many owners (and these owners don't fit on one 
page):


HTTP GET http://zebra#animal
Response:
 a dbpedia-owl:Animal .
 foaf:name "Bert" ; ns0:owns 
 .
 foaf:name "Ernie"; ns0:owns 
 .

...
 a hydra:PagedCollection ;
hydra:firstPage  ;
hydra:nextPage  .

What I suggest instead is introducing something like this:

HTTP GET http://zebra
Response:
 a dbpedia-owl:Animal .
 foaf:name "Bert" ; ns0:owns  .
 foaf:name "Ernie"; ns0:owns  .
...
 a hydra:PagedCollection ;
hydra:firstPage  ;
hydra:nextPage  .

Kind regards,

Pieter

On 2014-07-17 17:16, 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 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

Re: Real-world concept URIs

[Luca Matteis]

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 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
>
>

Real-world concept URIs

[Pieter Colpaert]

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

Real-world concept URIs

[Pieter Colpaert]

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