Re: Real-world concept URIs
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. mailto:pieter.colpa...@ugent.be is your Email address -- you have a mailbox provided by a mail server denoted by the DNS identifier dns:ugent.be . I could make a concise machine and human comprehensible description of you as follows: ## Turtle Start ## http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://xmlns.com/foaf/0.1/Document; http://www.w3.org/2000/01/rdf-schema#label About: Pieter Colpaert ; http://www.w3.org/2000/01/rdf-schema#comment Information gleaned from an LOD mailing list thread about Pieter Colpaert ; http://xmlns.com/foaf/0.1/primaryTopic#PieterColpaert ; http://www.w3.org/2000/01/rdf-schema#seeAlso http://bit.ly/1fqJ5yv . #PieterColpaert http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://xmlns.com/foaf/0.1/Agent ; http://xmlns.com/foaf/0.1/name Pieter Colpaert ; http://xmlns.com/foaf/0.1/mbox mailto:pieter.colpa...@ugent.be . ## 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
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. mailto:pieter.colpa...@ugent.be is your Email address -- you have a mailbox provided by a mail server denoted by the DNS identifier dns:ugent.be . I could make a concise machine and human comprehensible description of you as follows: ## Turtle Start ## http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://xmlns.com/foaf/0.1/Document; http://www.w3.org/2000/01/rdf-schema#label About: Pieter Colpaert ; http://www.w3.org/2000/01/rdf-schema#comment Information gleaned from an LOD mailing list thread about Pieter Colpaert ; http://xmlns.com/foaf/0.1/primaryTopic#PieterColpaert ; http://www.w3.org/2000/01/rdf-schema#seeAlso http://bit.ly/1fqJ5yv . #PieterColpaert http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://xmlns.com/foaf/0.1/Agent ; http://xmlns.com/foaf/0.1/name Pieter Colpaert ; http://xmlns.com/foaf/0.1/mbox mailto:pieter.colpa...@ugent.be . ## 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 .
Real-world concept URIs
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
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
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
Re: Real-world concept URIs
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:
http://zebra#animal a dbpedia-owl:Animal .
http://zebra/bert#owner foaf:name Bert ; ns0:owns
http://zebra#animal .
http://zebra/ernie#owner foaf:name Ernie; ns0:owns
http://zebra#animal .
...
http://zebra a hydra:PagedCollection ;
hydra:firstPage http://zebra?page=1 ;
hydra:nextPage http://zebra?page=2 .
What I suggest instead is introducing something like this:
HTTP GET http://zebra
Response:
//zebra a dbpedia-owl:Animal .
//zebra/bert foaf:name Bert ; ns0:owns //zebra .
//zebra/ernie foaf:name Ernie; ns0:owns //zebra .
...
http://zebra a hydra:PagedCollection ;
hydra:firstPage http://zebra?page=1 ;
hydra:nextPage http://zebra?page=2 .
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
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
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.colpa...@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
Re: Real-world concept URIs
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 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?
Re: Real-world concept URIs
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
On Thu, Jul 17, 2014 at 7:29 PM, Ruben Verborgh ruben.verbo...@ugent.be 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
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
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
Re: Real-world concept URIs
Hi Pieter,
On Thu, Jul 17, 2014 at 7:36 PM, Pieter Colpaert pieter.colpa...@ugent.be
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
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
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
Re: Real-world concept URIs
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
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 gannon_d...@yahoo.com 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
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 ontolo...@gmail.com wrote: Subject: Re: Real-world concept URIs To: Gannon Dick gannon_d...@yahoo.com Cc: Ruben Verborgh ruben.verbo...@ugent.be, Luca Matteis lmatt...@gmail.com, Pieter Colpaert pieter.colpa...@ugent.be, public-lod@w3.org community public-lod@w3.org 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 gannon_d...@yahoo.com 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
