W3C home > Mailing lists > Public > public-lod@w3.org > April 2008

RE: [Linking-open-data] watchdog.net and LOD best practices

From: Tom Heath <Tom.Heath@talis.com>
Date: Wed, 16 Apr 2008 13:06:27 +0100
Message-ID: <DD5E887552496241BC701548837A282F06B2292E@nemo.talis.local>
To: "Ed Summers" <ehs@pobox.com>, "Peter Ansell" <ansell.peter@gmail.com>
Cc: <public-lod@w3.org>

Ed,

Thanks for asking the question - it's a good one, and I'd also be keen
to hear the background to this decision from Aaron. As you flag up in
your response re the use of #this, the issue here is much more about
distinguishing Districts from "Documents about Districts" than it is
about slashes or hashes.

Tom.


> -----Original Message-----
> From: public-lod-request@w3.org 
> [mailto:public-lod-request@w3.org] On Behalf Of Ed Summers
> Sent: 16 April 2008 00:33
> To: Peter Ansell
> Cc: public-lod@w3.org
> Subject: Re: [Linking-open-data] watchdog.net and LOD best practices
> 
> 
> On Tue, Apr 15, 2008 at 6:21 PM, Peter Ansell 
> <ansell.peter@gmail.com> wrote:
> >  The insistence on slash URI's having 303 is mostly 
> philosophical if  
> > you are still going to allow hash URI's which people have no real  
> > reason to go away from. When you consider that user agents 
> do not send  
> > the hash part anyway, hence you have no idea at the server whether  
> > they are wanting the resource or just part, so you send back the  
> > result of a slash URL resolution... No need to push someone away  
> > because they didn't follow and arbitrary rule for "non-information  
> > resources".
> 
> I'm really not trying to push anyone away -- and I apologize 
> if it appeared that I was. My exposure to linking data has 
> largely been informed by watching discussions on here and 
> reading documents like How to Publish Linked Data on the Web 
> [1] and Cool URIs for the Semantic Web [2].
> 
> The value of these documents IMHO, is that the provide some 
> pretty clear guidance on URI design w/ httpRange-14 in mind. 
> I know Aaron is not a newcomer to the web or RDF -- so I was 
> genuinely curious about the thought process behind the service.
> 
> > If there is any experimental evidence the Semantic Web  
> will actually 
> > succeed if there are double the number of requests  needed for a 
> > single resolution then it may be interesting to revisit  
> the idea of 
> > assuming people are bad semantic web citizens because they  
> implement 
> > things pragmatically.
> 
> That's why the hash option is there. I'm fairly certain that 
> the watchdog rdf descriptions would just have to use a hash 
> URI in the description to be compliant--no double requests or 
> 303 is necessary.
> For example:
> 
> @prefix : <http://watchdog.net/about/api#> .
> 
> <http://watchdog.net/us/MD-08#this> a :District;
>   :almanac 
> <http://nationaljournal.com/pubs/almanac/2008/people/md/rep_md08.htm>;
>   :area_sqmi 307;
>   :center_lat 39.0231;
>   :center_lng -77.1421;
>   :cook_index "D+20";
>   :est_population 700364;
>   :est_population_year 2005;
>   :median_income 68306;
>   :name "MD-08";
>   :poverty_pct 6.2;  :state <http://watchdog.net/us/md>;  
> :voting true;  :wikipedia 
> <http://en.wikipedia.org/wiki/Maryland's_8th_congressional_district>;
> :zoom_level 10;.
> 
> >  It would however be nice to have link rel="alternate"
> >  type="application/rdf+xml" href="blah.xml" etc. in the 
> head of the  
> > html though to facilitate the discovery of the RDF/N3/JSON 
> materials  
> > automatically. That doesn't imply that the blah.xml has to 303  
> > redirect to a third resource "just in case" though.
> 
> Right it doesn't have to. But the URI used to identify a 
> district would just need a hash part appended to it as above. 
> I'm not really trying to pedantic here, I'm trying to 
> understand the best practices myself.
> 
> //Ed
> 
> [1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
> [2] http://www.w3.org/TR/cooluris/
> 
> 
Received on Wednesday, 16 April 2008 12:07:15 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:16 UTC