Re: Please allow JS access to Ontologies and LOD

Hi Martin,

A few people are considering setting up a network of JS accessible 
proxies which can be used to access the web of linked data from JS, 
however this isn't very HTTP friendly, could cost a lot bandwidth wise, 
and is more of an interim measure - thus trying to put pressure on to 
get as much linked data & ontologies JS accessible as possible before 
taking this route.

Best,

Nathan

Martin Hepp wrote:
> Hi Nathan:
> 
> Would it be an option that someone provides a service that resolves 
> purls to their current resource locations and adds the JS/CORS header 
> info to that service? I mean, one could use a service other than 
> purl.org to resolve a purl.org URI.
> 
> Something like cors4purl.org.
> 
> Whenever your JS encounters a http://purl/.*$ URI, you fetch 
> http://cors4purl.org/$1.
> 
> Not the most beautiful solution, but likely a clean, pragmatic way to 
> make the many purl.org-based vocabularies accessible for client-side 
> scripts.
> 
> Martin
> 
> On 27.10.2010, at 22:14, Nathan wrote:
> 
>> Hi Martin,
>>
>> Great work! sadly though purl.org currently doesn't allow JS/CORS 
>> access so it won't work :( this is true for everybody who use PURLz.
>>
>> see: 
>> http://groups.google.com/group/persistenturls/browse_thread/thread/d4c5d9880b4fb5fb 
>>
>>
>> for the request to add, please do add weight if you want them to make 
>> it so - note that this will allow the redirects to be JS/CORS 
>> compatible, it's still up to each end URI/domain to allow CORS support 
>> (as martin has done).
>>
>> Best,
>>
>> Nathan
>>
>> Martin Hepp wrote:
>>> Hi Nathan, all:
>>> I just fixed this for GoodRelations
>>>   http://purl.org/goodrelations/v1
>>> and the Vehicle Sales Ontology (VSO):
>>>  http://purl.org/vso/ns
>>> Best wishes
>>> Martin
>>> On 23.10.2010, at 03:28, Nathan wrote:
>>>> Hi Ian,
>>>>
>>>> Thanks, I can confirm the change has been successful :)
>>>>
>>>> However, one small note is that the conneg URIs such as 
>>>> http://productdb.org/gtin/00319980033520 do not expose the header, 
>>>> thus can't be used.
>>>>
>>>> In order to test yourself, simply do a curl -I request on the 
>>>> resource, for instance:
>>>>
>>>> curl -I http://productdb.org/gtin/00319980033520.rdf
>>>>
>>>> Also, I've just uploaded a small script which lets you enter a uri 
>>>> of an RDF/XML document, it'll try and pull it, parse it and display 
>>>> it as turtle for you - which is a good test of both CORS and the 
>>>> script ;)
>>>> http://webr3.org/apps/play/api/test
>>>>
>>>> FYI, Dan has also made the change so the FOAF vocab is now exposed 
>>>> to JS.
>>>>
>>>> Best and thanks again,
>>>>
>>>> Nathan
>>>>
>>>> Ian Davis wrote:
>>>>> Hi Nathan,
>>>>> I implemented this header on http://productdb.org/ (since I had the
>>>>> code open). Can someone comfirm that it does what's expected (i.e.
>>>>> allows off-domain requesting of data from productdb.org)
>>>>> One important thing to note. The PHP snippet you gave was slightly
>>>>> wrong. The correct form is:
>>>>> header("Access-Control-Allow-Origin: *");
>>>>> Cheers,
>>>>> Ian
>>>>> On Sat, Oct 23, 2010 at 12:04 AM, Nathan <nathan@webr3.org> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Currently nearly all the web of linked data is blocked from access 
>>>>>> via
>>>>>> client side scripts (javascript) due to CORS [1] being implemented 
>>>>>> in the
>>>>>> major browsers.
>>>>>>
>>>>>> Whilst this is important for all data, there are many of you 
>>>>>> reading this
>>>>>> who have it in your power to expose huge chunks of the RDF on the 
>>>>>> web to JS
>>>>>> clients, if you manage any of the common ontologies or anything in 
>>>>>> the LOD
>>>>>> cloud diagram, please do take a few minutes from your day to 
>>>>>> expose the
>>>>>> single http header needed.
>>>>>>
>>>>>> Long story short, to allow js clients to access our "open" data we 
>>>>>> need to
>>>>>> add one small HTTP Response header which will allow HEAD/GET and POST
>>>>>> requests - the header is:
>>>>>> Access-Control-Allow-Origin "*"
>>>>>>
>>>>>> This is both XMLHttpRequest (W3C) and XDomainRequest (Microsoft) 
>>>>>> compatible
>>>>>> and supported by all the major browser vendors.
>>>>>>
>>>>>> Instructions for common servers follow:
>>>>>>
>>>>>> If you're on Apache then you can send this header by simply adding 
>>>>>> the
>>>>>> following line to a .htaccess file in the dir you want to expose 
>>>>>> (probably
>>>>>> site-root):
>>>>>> Header add Access-Control-Allow-Origin "*"
>>>>>>
>>>>>> For NGINX:
>>>>>> add_header Access-Control-Allow-Origin "*";
>>>>>> see: http://wiki.nginx.org/NginxHttpHeadersModule
>>>>>>
>>>>>> For IIS see:
>>>>>> http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx
>>>>>>
>>>>>> In PHP you add the following line before any output has been sent 
>>>>>> from the
>>>>>> server with:
>>>>>> header("Access-Control-Allow-Origin", "*");
>>>>>>
>>>>>> For anything else you'll need to check the relevant docs I'm afraid.
>>>>>>
>>>>>> Best & TIA,
>>>>>>
>>>>>> Nathan
>>>>>>
>>>>>> [1] http://dev.w3.org/2006/waf/access-control/
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
> 
> 
>

Received on Wednesday, 27 October 2010 20:39:40 UTC