Re: Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Mark Fallu
That is a fair point - but I would still suggest that it is important for 
search engines to be able to meaningfully interpret:
- internal links
- rdfa representations that span multiple pages.

Cheers,

Mark

Sent from my iPhone

> On 19 Jul 2014, at 3:02 am, Paul Houle  wrote:
> 
> Frankly I don't care about PageRank,  and these days I don't know if
> Google does.  These days Google gets direct sampling of user behavior
> through Chrome and Google Analytics,  and this sort of data is
> probably much more valuable than the link graph since they know about
> things like time-on-page,  query chains,  and things like that.
> 
> If anything,  PageRank,  or what people imagine about PageRank has
> been harmful to the web because it's created a situation where people
> just don't make links to other web sites anymore.  It started with
> high profile sites (ex. engadget) that just wanted to be greedy and
> not give any PageRank to their competition.  Then you saw people using
> the NOFOLLOW attribute because they thought that this too was a way to
> be greedy.
> 
> Ten years ago I got a lot of emails from people that amounted to "I
> will pay you $X if you make a link on page Y to page Z with anchor
> text T".  You'd also find SEO firms that would ask for $X a month to
> generate Y links to your site.
> 
> Recently Google made some changes and they seem to be punishing people
> who have inappropriate links so now people get emails like "Would you
> please remove the link from page X to page Y" and the new thing is
> that SEO firms now want you to pay them $X to remove Y links to your
> site.
> 
> I think it is all a lot of bull and I make whatever links I like and
> figure that Google is going to do whatever it is they are going to do.
> 
> ᐧ
> 
>> On Fri, Jul 18, 2014 at 8:05 AM, Mark Fallu  wrote:
>> I am attempting to understand how the the CoolURI 303 redirect pattern for
>> the semantic web (http://www.w3.org/TR/cooluris/) can be implemented without
>> negative impact on search engines.
>> 
>> This pattern appears to allow site content to be indexed, but prevents page
>> rank from flowing through internal links due to the use of a 303 redirect.
>> 
>> For example in Griffith's Research-Hub: http://research-hub.griffith.edu.au
>> 
>> A get request to the URI of Howard Wiseman:
>> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>> 
>> Will resolve to different urls based on content negotiation.
>> 
>> For RDF:
>> wget --header "Accept: application/rdf+xml"
>> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>> 
>> results in a "303 see other" redirect to the RDF version of the entity:
>> http://research-hub.griffith.edu.au/rdf/n33a4e2d3057476efaff5ce1884564a8f/n33a4e2d3057476efaff5ce1884564a8f.rdf
>> 
>> For HTML:
>> wget --header "Accept: text/html"
>> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>> results in a "303 see other" redirect to the HTML version of the entity (our
>> old friend the "display" version:
>> http://research-hub.griffith.edu.au/display/n33a4e2d3057476efaff5ce1884564a8f
>> 
>> Note: There will never be a HTML page at
>> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>> just a HTTP response
>> 
>> Links will be presented as the "individual" uri and then redirect to the
>> "display" url.
>> 
>> All good so far - this is a perfectly functional example of the Cool URI
>> specification at work.  Unfortunately it results in a few issues in
>> practice.
>> 
>> If the links we present to the outside world for harvesting eg. via sparql
>> endpoint, OAI-PMH or open social widget etc is the canonical "individual"
>> URI, clients will be able to get to the "display" url, but the google page
>> rank that would normally flow from these external links will not.
>> 
>> The specification of a 303 redirect describes it as:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>> 
>>> "The response to the request can be found under a different URI and SHOULD
>>> be retrieved using a GET method on that resource. This method exists
>>> primarily to allow the output of a POST-activated script to redirect the
>>> user agent to a selected resource. The new URI is not a substitute reference
>>> for the originally requested resource. The 303 response MUST NOT be cached,
>>> but the response to the second (redirected) request might be cacheable.
>>> 
>>> 
>>> 
>>> The different URI SHOULD be given by the Location field in the response.
>>> Unless the request method was HEAD, the entity of the response SHOULD
>>> contain a short hypertext note with a hyperlink to the new URI(s)."
>> 
>> 
>> Google correctly implements the specification and does not assign the page
>> rank of the "individual" URI to the "display" URL as it is "not a substitute
>> reference for the originally requested resource".
>> 
>> The same is true of internal links, a high page rank home page will not pass

Re: Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Paul Houle
Frankly I don't care about PageRank,  and these days I don't know if
Google does.  These days Google gets direct sampling of user behavior
through Chrome and Google Analytics,  and this sort of data is
probably much more valuable than the link graph since they know about
things like time-on-page,  query chains,  and things like that.

If anything,  PageRank,  or what people imagine about PageRank has
been harmful to the web because it's created a situation where people
just don't make links to other web sites anymore.  It started with
high profile sites (ex. engadget) that just wanted to be greedy and
not give any PageRank to their competition.  Then you saw people using
the NOFOLLOW attribute because they thought that this too was a way to
be greedy.

Ten years ago I got a lot of emails from people that amounted to "I
will pay you $X if you make a link on page Y to page Z with anchor
text T".  You'd also find SEO firms that would ask for $X a month to
generate Y links to your site.

Recently Google made some changes and they seem to be punishing people
who have inappropriate links so now people get emails like "Would you
please remove the link from page X to page Y" and the new thing is
that SEO firms now want you to pay them $X to remove Y links to your
site.

I think it is all a lot of bull and I make whatever links I like and
figure that Google is going to do whatever it is they are going to do.

ᐧ

On Fri, Jul 18, 2014 at 8:05 AM, Mark Fallu  wrote:
> I am attempting to understand how the the CoolURI 303 redirect pattern for
> the semantic web (http://www.w3.org/TR/cooluris/) can be implemented without
> negative impact on search engines.
>
> This pattern appears to allow site content to be indexed, but prevents page
> rank from flowing through internal links due to the use of a 303 redirect.
>
> For example in Griffith's Research-Hub: http://research-hub.griffith.edu.au
>
> A get request to the URI of Howard Wiseman:
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>
> Will resolve to different urls based on content negotiation.
>
> For RDF:
> wget --header "Accept: application/rdf+xml"
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>
> results in a "303 see other" redirect to the RDF version of the entity:
> http://research-hub.griffith.edu.au/rdf/n33a4e2d3057476efaff5ce1884564a8f/n33a4e2d3057476efaff5ce1884564a8f.rdf
>
> For HTML:
> wget --header "Accept: text/html"
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
> results in a "303 see other" redirect to the HTML version of the entity (our
> old friend the "display" version:
> http://research-hub.griffith.edu.au/display/n33a4e2d3057476efaff5ce1884564a8f
>
> Note: There will never be a HTML page at
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
> just a HTTP response
>
> Links will be presented as the "individual" uri and then redirect to the
> "display" url.
>
> All good so far - this is a perfectly functional example of the Cool URI
> specification at work.  Unfortunately it results in a few issues in
> practice.
>
> If the links we present to the outside world for harvesting eg. via sparql
> endpoint, OAI-PMH or open social widget etc is the canonical "individual"
> URI, clients will be able to get to the "display" url, but the google page
> rank that would normally flow from these external links will not.
>
> The specification of a 303 redirect describes it as:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>
>> "The response to the request can be found under a different URI and SHOULD
>> be retrieved using a GET method on that resource. This method exists
>> primarily to allow the output of a POST-activated script to redirect the
>> user agent to a selected resource. The new URI is not a substitute reference
>> for the originally requested resource. The 303 response MUST NOT be cached,
>> but the response to the second (redirected) request might be cacheable.
>>
>>
>>
>> The different URI SHOULD be given by the Location field in the response.
>> Unless the request method was HEAD, the entity of the response SHOULD
>> contain a short hypertext note with a hyperlink to the new URI(s)."
>
>
> Google correctly implements the specification and does not assign the page
> rank of the "individual" URI to the "display" URL as it is "not a substitute
> reference for the originally requested resource".
>
> The same is true of internal links, a high page rank home page will not pass
> page rank on to "display" urls if the pathway to those urls is via
> "individual" uri links.
>
> I am not sure what the solution is here as it seems the realms of SEO and
> the conventions of the web they are built on are not a good fit for semantic
> web best practice.
>
> The most minimal compromise I can think of is to move away from the use of a
> 303 redirect to a redirect that conserves the flow of google page rank.
>
>

Re: Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Gannon Dick

 On 18 July 2014 14:05, Mark
 Fallu 
 wrote:
 
 I am attempting to understand how the the
 CoolURI 303 redirect pattern for the semantic web 
(http://www.w3.org/TR/cooluris/) can be
 implemented
 without negative impact on search engines.
 
 Just a
 quick question:
 
 Is there any reason you want to use
 303s?  
 
 I personally consider it an anti-pattern.
  

Thank you, Melvin. I think so too.

short version:"anti-pattern"

long version:
Eastern Australia is 13 hours ahead of the Central United States so ...
On Saturday night in Dallas there is no semantic difference between praying 
Australians and liquored-up cowboys.  Bug or a Feature ? No, anti-pattern.





Re: Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Melvin Carvalho
On 18 July 2014 14:05, Mark Fallu  wrote:

> I am attempting to understand how the the CoolURI 303 redirect pattern for
> the semantic web (http://www.w3.org/TR/cooluris/) can be implemented
> without negative impact on search engines.
>

Just a quick question:

Is there any reason you want to use 303s?

I personally consider it an anti-pattern.


>
> This pattern appears to allow site content to be indexed, but
> prevents page rank from flowing through internal links due to the use of a
> 303 redirect.
>
> For example in Griffith's Research-Hub:
> http://research-hub.griffith.edu.au
>
> A get request to the URI of Howard Wiseman:
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>
> Will resolve to different urls based on content negotiation.
>
> For RDF:
> wget --header "Accept: application/rdf+xml"
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>
> results in a "303 see other" redirect to the RDF version of the entity:
>
> http://research-hub.griffith.edu.au/rdf/n33a4e2d3057476efaff5ce1884564a8f/n33a4e2d3057476efaff5ce1884564a8f.rdf
>
> For HTML:
> wget --header "Accept: text/html"
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
> results in a "303 see other" redirect to the HTML version of the entity
> (our old friend the "display" version:
>
> http://research-hub.griffith.edu.au/display/n33a4e2d3057476efaff5ce1884564a8f
>
> Note: There will never be a HTML page at
> http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
>  just
> a HTTP response
>
> Links will be presented as the "individual" uri and then redirect to the
> "display" url.
>
> All good so far - this is a perfectly functional example of the Cool URI
> specification at work.  Unfortunately it results in a few issues in
> practice.
>
> If the links we present to the outside world for harvesting eg. via sparql
> endpoint, OAI-PMH or open social widget etc is the canonical "individual"
> URI, clients will be able to get to the "display" url, but the google page
> rank that would normally flow from these external links will not.
>
> The specification of a 303 redirect describes it as:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>
>> "The response to the request can be found under a different URI and
>> SHOULD be retrieved using a GET method on that resource. This method exists
>> primarily to allow the output of a POST-activated script to redirect the
>> user agent to a selected resource. *The new URI is not a substitute
>> reference for the originally requested resource*. The 303 response MUST
>> NOT be cached, but the response to the second (redirected) request might be
>> cacheable.
>>
>
>
> The different URI SHOULD be given by the Location field in the response.
>> Unless the request method was HEAD, the entity of the response SHOULD
>> contain a short hypertext note with a hyperlink to the new URI(s)."
>
>
> Google correctly implements the specification and does not assign the page
> rank of the "individual" URI to the "display" URL as it is "*not a
> substitute reference for the originally requested resource".*
>
>  The same is true of internal links, a high page rank home page will not
> pass page rank on to "display" urls if the pathway to those urls is via
> "individual" uri links.
>
> I am not sure what the solution is here as it seems the realms of SEO and
> the conventions of the web they are built on are not a good fit for
> semantic web best practice.
>
> The most minimal compromise I can think of is to move away from the use of
> a 303 redirect to a redirect that conserves the flow of google page rank.
>
>- "302 Found" redirect is the recommended replacement for 303 for
>clients that do not support HTTP 1.1  and it does allow a certain amount of
>google page rank to flow.
>- "301 Moved Permanently" is a poor fit for the Cool URI pattern, but
>passes on the full page rank of the links.
>- rewriting all URIs the URL would also work, but would break the
>coolURI pattern.
>
> The pragmatist in me feels that if we are going to make a change for the
> purposes of SEO, it might as well be the one with best return, i.e. 301
> redirect.
>
> Note: Indexing is not the problem here, content is indexed.  The issue
> relates to page rank not flowing through a 303 redirect.
>
> I have tested and can confirm that 303 redirects are an issue for a number
> of reasons:
>
>- page rank does not flow through a 303 redirect
>- page rank can not be assigned from a url to a uri with a
>rel=canonical tag if URI does a 303 redirect (preventing aggregation of
>pagerank from external links to URL)
>- URI and URL are indexed separately
>- rdfa schema.org representations of URIs do not translate to URL (ie.
>representation described at URL A, talking about URI B, does not get
>connected to representation described at URL B)
>- url parameters are not passe

Re: Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Michael Brunnbauer

Hello Mark,

I cannot remember this important topic coming up earlier - which is a bit
disturbing.

The problem would be migitated by people using the URI they see for linking.

Why not use the HTML URLs in the HTML pages for internal page rank flow?

How can URIs from sparql endpoints or OAI-PMH contribute to page rank?

A real problem would be RDFa where href also sets the object of a triple.

Regards,

Michael Brunnbauer

On Fri, Jul 18, 2014 at 10:05:17PM +1000, Mark Fallu wrote:
> If the links we present to the outside world for harvesting eg. via sparql
> endpoint, OAI-PMH or open social widget etc is the canonical "individual"
> URI, clients will be able to get to the "display" url, but the google page
> rank that would normally flow from these external links will not.



> 
> The specification of a 303 redirect describes it as:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 
> > "The response to the request can be found under a different URI and SHOULD
> > be retrieved using a GET method on that resource. This method exists
> > primarily to allow the output of a POST-activated script to redirect the
> > user agent to a selected resource. *The new URI is not a substitute
> > reference for the originally requested resource*. The 303 response MUST
> > NOT be cached, but the response to the second (redirected) request might be
> > cacheable.
> >
> 
> 
> The different URI SHOULD be given by the Location field in the response.
> > Unless the request method was HEAD, the entity of the response SHOULD
> > contain a short hypertext note with a hyperlink to the new URI(s)."
> 
> 
> Google correctly implements the specification and does not assign the page
> rank of the "individual" URI to the "display" URL as it is "*not a
> substitute reference for the originally requested resource".*
> 
>  The same is true of internal links, a high page rank home page will not
> pass page rank on to "display" urls if the pathway to those urls is via
> "individual" uri links.
> 
> I am not sure what the solution is here as it seems the realms of SEO and
> the conventions of the web they are built on are not a good fit for
> semantic web best practice.
> 
> The most minimal compromise I can think of is to move away from the use of
> a 303 redirect to a redirect that conserves the flow of google page rank.
> 
>- "302 Found" redirect is the recommended replacement for 303 for
>clients that do not support HTTP 1.1  and it does allow a certain amount of
>google page rank to flow.
>- "301 Moved Permanently" is a poor fit for the Cool URI pattern, but
>passes on the full page rank of the links.
>- rewriting all URIs the URL would also work, but would break the
>coolURI pattern.
> 
> The pragmatist in me feels that if we are going to make a change for the
> purposes of SEO, it might as well be the one with best return, i.e. 301
> redirect.
> 
> Note: Indexing is not the problem here, content is indexed.  The issue
> relates to page rank not flowing through a 303 redirect.
> 
> I have tested and can confirm that 303 redirects are an issue for a number
> of reasons:
> 
>- page rank does not flow through a 303 redirect
>- page rank can not be assigned from a url to a uri with a rel=canonical
>tag if URI does a 303 redirect (preventing aggregation of pagerank from
>external links to URL)
>- URI and URL are indexed separately
>- rdfa schema.org representations of URIs do not translate to URL (ie.
>representation described at URL A, talking about URI B, does not get
>connected to representation described at URL B)
>- url parameters are not passed by a 303 redirect.
>- impact on functinality of google analytics tracking eg. traversing the
>site is seen as a series of direct page visits.
> 
> Essentially - as far as search engines are concerned - every URL and URI is
> an island, with no connections between them.  At best a URL can express a
> rel=canonical back to it's corresponding URI, no pagerank will flow through
> links.
> 
> Any guidance you can provide would be appreciated.
> 
> -- 
> 
> o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> | Mark Fallu
> | Manager, Research Data (Acting)
> | Office for Research
> | Bray Centre (N54) 0.10E
> | Griffith University, Nathan Campus
> | Queensland 4111 AUSTRALIA
> |
> | E-mail: m.fa...@griffith.edu.au
> | Mobile:  04177 69778
> | Phone:  +61 (07) 373 52069
> o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail bru...@netestate.de
++  http://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel


pgpwlzdhcwqRx.pgp
Description: PGP signature


How to write SPARQL queries against Freebase data

2014-07-18 Thread Paul Houle
See

http://blog.databaseanimals.com/how-to-write-sparql-queries-against-freebase-data

and also

http://blog.databaseanimals.com/the-trouble-with-dbpedia

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



Linked Data and Semantic Web CoolURIs, 303 redirects and Page Rank.

2014-07-18 Thread Mark Fallu
I am attempting to understand how the the CoolURI 303 redirect pattern for
the semantic web (http://www.w3.org/TR/cooluris/) can be implemented
without negative impact on search engines.

This pattern appears to allow site content to be indexed, but prevents page
rank from flowing through internal links due to the use of a 303 redirect.

For example in Griffith's Research-Hub: http://research-hub.griffith.edu.au

A get request to the URI of Howard Wiseman:
http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f

Will resolve to different urls based on content negotiation.

For RDF:
wget --header "Accept: application/rdf+xml"
http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f

results in a "303 see other" redirect to the RDF version of the entity:
http://research-hub.griffith.edu.au/rdf/n33a4e2d3057476efaff5ce1884564a8f/n33a4e2d3057476efaff5ce1884564a8f.rdf

For HTML:
wget --header "Accept: text/html"
http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
results in a "303 see other" redirect to the HTML version of the entity
(our old friend the "display" version:
http://research-hub.griffith.edu.au/display/n33a4e2d3057476efaff5ce1884564a8f

Note: There will never be a HTML page at
http://research-hub.griffith.edu.au/individual/n33a4e2d3057476efaff5ce1884564a8f
just
a HTTP response

Links will be presented as the "individual" uri and then redirect to the
"display" url.

All good so far - this is a perfectly functional example of the Cool URI
specification at work.  Unfortunately it results in a few issues in
practice.

If the links we present to the outside world for harvesting eg. via sparql
endpoint, OAI-PMH or open social widget etc is the canonical "individual"
URI, clients will be able to get to the "display" url, but the google page
rank that would normally flow from these external links will not.

The specification of a 303 redirect describes it as:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

> "The response to the request can be found under a different URI and SHOULD
> be retrieved using a GET method on that resource. This method exists
> primarily to allow the output of a POST-activated script to redirect the
> user agent to a selected resource. *The new URI is not a substitute
> reference for the originally requested resource*. The 303 response MUST
> NOT be cached, but the response to the second (redirected) request might be
> cacheable.
>


The different URI SHOULD be given by the Location field in the response.
> Unless the request method was HEAD, the entity of the response SHOULD
> contain a short hypertext note with a hyperlink to the new URI(s)."


Google correctly implements the specification and does not assign the page
rank of the "individual" URI to the "display" URL as it is "*not a
substitute reference for the originally requested resource".*

 The same is true of internal links, a high page rank home page will not
pass page rank on to "display" urls if the pathway to those urls is via
"individual" uri links.

I am not sure what the solution is here as it seems the realms of SEO and
the conventions of the web they are built on are not a good fit for
semantic web best practice.

The most minimal compromise I can think of is to move away from the use of
a 303 redirect to a redirect that conserves the flow of google page rank.

   - "302 Found" redirect is the recommended replacement for 303 for
   clients that do not support HTTP 1.1  and it does allow a certain amount of
   google page rank to flow.
   - "301 Moved Permanently" is a poor fit for the Cool URI pattern, but
   passes on the full page rank of the links.
   - rewriting all URIs the URL would also work, but would break the
   coolURI pattern.

The pragmatist in me feels that if we are going to make a change for the
purposes of SEO, it might as well be the one with best return, i.e. 301
redirect.

Note: Indexing is not the problem here, content is indexed.  The issue
relates to page rank not flowing through a 303 redirect.

I have tested and can confirm that 303 redirects are an issue for a number
of reasons:

   - page rank does not flow through a 303 redirect
   - page rank can not be assigned from a url to a uri with a rel=canonical
   tag if URI does a 303 redirect (preventing aggregation of pagerank from
   external links to URL)
   - URI and URL are indexed separately
   - rdfa schema.org representations of URIs do not translate to URL (ie.
   representation described at URL A, talking about URI B, does not get
   connected to representation described at URL B)
   - url parameters are not passed by a 303 redirect.
   - impact on functinality of google analytics tracking eg. traversing the
   site is seen as a series of direct page visits.

Essentially - as far as search engines are concerned - every URL and URI is
an island, with no connections between them.  At best a URL can express a
rel=canonical back to it's corresponding U

Re: Real-world concept URIs

2014-07-18 Thread 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

2014-07-18 Thread 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


[EKAW 2014] Call for Ph.D. Symposium - DEADLINE IN 48 HOURS

2014-07-18 Thread Mauro Dragoni
Call for Ph.D. Symposium *** DEADLINE IN 48 HOURS ***



The 19th International Conference on Knowledge Engineering and
Knowledge Management

http://www.ida.liu.se/conferences/EKAW14/home.html

24-28 November 2014, Linköping, Sweden



The EKAW 2014 PhD Symposium will provide PhD students an opportunity
to present their research ideas and results in a stimulating
environment, to get feedback from mentors who are experienced research
scientists in the community, to explore issues related to academic and
research careers, and to build relationships with other PhD students
from around the world.

The Symposium is intended for students at each stage of their PhD. PhD
students at the beginning of their work should be able to submit at
least a well-defined problem statement and some ideas about the
proposed approach towards a solution. Students in their second or
third year of their PhD will have to submit their research plan, their
evaluation protocol and their preliminary results. All students will
be will have an opportunity to present their work to an international
audience, to be paired with a mentor, and to discuss their work with
experienced scientists from the research community.

All proposals submitted to the EKAW 2014 PhD Symposium will undergo a
reviewing process with a view to providing detailed and constructive
feedback. The international program committee will select the best
submissions for presentation at the PhD Symposium and inclusion in the
Symposium proceedings.



SUBMISSION INFORMATION
---

We ask the PhD students to submit a 5-8 page description of their
work. All proposals have to be submitted electronically via the
EasyChair conference submission System
athttps://www.easychair.org/conferences/?conf=ekaw2014phd. Submissions
should be structured around the following items which are the key
methodological components required for a sound research narrative:

  1. Problem: describe the core problem of the PhD and motivate its
relevance for the knowledge management, knowledge acquisition and
knowledge representation areas;
  2. State of the art: describe relevant related work and point out
areas that need to be improved;
  3. Proposed Approach: present the approach taken and motivate how
this is novel with respect to existing work;
  4. Methodology: sketch the methodology that is (or will be) adopted;
  5. Evaluation protocol: the approach to be taken for evaluating the
results of the work;
  6. Results: describe the current status of the work and any results
that have been reached so far;
  7. Conclusions and future work: conclude and specify the major items
of future work.

Additional submission requirements:
All submissions must be single-author submissions. Please acknowledge
your PhD advisor(s) and other contributors in the Acknowledgements
section.
Students accepted to present at the PhD Symposium must plan to attend
the Symposium for the whole day in order to gain as much value as
possible from the experience.
Submissions must be in pdf and be formatted according to Springer
Verlag LNCS guidelines.
Accepted papers will be published online as a CEUR doctoral symposium
proceedings volume. We are evaluating the possibility of publishing a
selection of original papers presented at the symposium in a Springer
volume.



TOPICS
---

The symposium focuses on the same topics of the main conference. See
http://www.ida.liu.se/conferences/EKAW14/callsfor/callsforpapers#EKAW-topics



IMPORTANT DATES


  * Abstract Submission: July 20, 2014
  * Full Paper Submission: July 25, 2014
  * Notification: September 10, 2014
  * Camera-Ready: October 1, 2014
  * PhD Symposium: November 24 or 25, 2014



CHAIRS
---

Ying Ding, Indiana University, USA
Chiara Ghidini, Fondazione Bruno Kessler, Italy.



PROGRAM COMMITTEE MEMBERS
--
Sören Auer
Eva Blomqvist
Stefano Borgo
Elena Cabrio
Michelle Cheatham
Paolo Ciancarini
Oscar Corcho
Mathieu d’Aquin
Mauro Dragoni
Aldo Gangemi
Giancarlo Guizzardi
Maria Keet
Juanzi Li
Diana Maynard
Marco Rospocher
Satya Sahoo
Guus Schreiber
Vojtech Svatek
Valentina Tamma
Jun Zhao