W3C home > Mailing lists > Public > public-lod@w3.org > October 2010

Re: Please allow JS access to Ontologies and LOD

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Wed, 27 Oct 2010 22:34:14 +0200
Cc: Ian Davis <lists@iandavis.com>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>
Message-Id: <4FF0DBE0-EB4B-425C-B125-02F9B5CB2612@ebusiness-unibw.org>
To: nathan@webr3.org
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:35:07 UTC

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