Fwd: Europeana launches Linked Open Data Pilot and Animation
Dear all (apologies for cross-posting) data.europeana.eu has already existed for several months, but I thought it could be useful to share the following re-release with you, since all the metadata there is now CC0. We of course wish to release even more in the coming months. We hope in the meantime that what we release will be used in some services. We stand ready to help anyone who'd be interested! Best, Antoine Original Message Subject:Europeana launches Linked Open Data Pilot and Animation Date: Fri, 17 Feb 2012 11:57:33 +0100 Dear Partners, As Linked Open Data (LOD) is gaining traction in the information world right now, Europeana has just launched an _animation http://vimeo.com/36752317_ to explain something about it and its benefits for users and data providers. As major heritage institutions are embracing the concept and making their data openly available, Europeana is also* *facilitating LOD developments. We've published our first dataset comprising _2.4 million objects http://data.europeana.eu_under CC0. Not only can this data be enriched to improve user experience, but it can also be used to develop innovative applications and help create new web services. Support for Open Data innovation is also at the root of Europeana’s new _Data Exchange Agreement http://pro.europeana.eu/support-for-open-data_, the contract that you, as partners, are asked to agree to when your metadata goes into Europeana. The Data Exchange Agreement has now been signed by all the national libraries, by leading national museums such as the Rijksmuseum, Amsterdam, and by many of the content providers for entire countries, such as Sweden’s National Heritage Board. The new Data Exchange Agreement dedicates the metadata to the Public Domain and comes into effect on 1 July 2012, after which all metadata in Europeana will be available as Open Data. Europeana has just put out a press release http://bit.ly/w6tS2Y about the animation and Linked Open Data pilot. It would be valuable if you could translate the release, put it on your website, circulate it to your press lists and forward it to your networks. With regards, The Europeana Team For more information see: http://bit.ly/w6tS2Y Linked Open Data Animation: http://vimeo.com/36752317
Re: PURLs don't matter, at least in the LOD world
On 17/02/12 21:08, Kingsley Idehen wrote: On 2/17/12 2:18 PM, David Booth wrote: On Fri, 2012-02-17 at 18:48 +, Hugh Glaser wrote: [ . . . ] What happens if I have http://purl.org/dbpedia/Tokyo, which is set to go to http://dbpedia.org/resource/Tokyo? I have (a), (b) and (c) as before. Now if dbpedia.org goes Phut!, we are in exactly the same situation - (b) gets lost. No, the idea is that the administrator for http://purl.org/dbpedia/ updates the redirect, to point to whatever new site is hosting the dbpedia data, so the http://purl.org/dbpedia/Tokyo still works. David, But any admin that oversees a DNS server can do the same thing. What's special about purl in this context? Precisely that they don't require an admin with power over the DNS registration :) To me the PURL design pattern is about delegation authority and it's an important pattern. Two specific use cases at different extremes: (1) An individual is creating a small vocabulary that they would like to see used widely but don't have a nice brand-neutral stable domain of their own they can use for the purpose. This one has already been covered in the discussion. (2) I'm a big organization, say the UK Government. I want to use a particular domain (well a set of subdomains) for publishing my data, say *.data.gov.uk. The domain choice is important - it has credibility and promises long term stability. Yet I want to decentralize the publication itself, I want different departments and agencies to publish data and identifiers within the subdomains. The subdomains are supposed to be organization-neural yet the people doing the publication will be based in specific organizations. The PURL design pattern (though not necessarily the specific PURL implementation) is an excellent way to manage the delegation that makes that possible. So my summary answer to Hugh is - they are much more important to the publisher than to the consumer. Dave
Re: PURLs don't matter, at least in the LOD world
A quick related question - does anyone know the status of purl.oclc.org - there was a point in time where the service suggested that this new hostname was going to be the new proper host for purl.org urls. I hope they have abandoned this idea, as one sure way to affect url longevity is to include a organisational brand in it ;) Ben On Feb 18, 2012 1:02 PM, Dave Reynolds dave.e.reyno...@gmail.com wrote: On 17/02/12 21:08, Kingsley Idehen wrote: On 2/17/12 2:18 PM, David Booth wrote: On Fri, 2012-02-17 at 18:48 +, Hugh Glaser wrote: [ . . . ] What happens if I have http://purl.org/dbpedia/Tokyo, which is set to go to http://dbpedia.org/resource/**Tokyohttp://dbpedia.org/resource/Tokyo ? I have (a), (b) and (c) as before. Now if dbpedia.org goes Phut!, we are in exactly the same situation - (b) gets lost. No, the idea is that the administrator for http://purl.org/dbpedia/ updates the redirect, to point to whatever new site is hosting the dbpedia data, so the http://purl.org/dbpedia/Tokyo still works. David, But any admin that oversees a DNS server can do the same thing. What's special about purl in this context? Precisely that they don't require an admin with power over the DNS registration :) To me the PURL design pattern is about delegation authority and it's an important pattern. Two specific use cases at different extremes: (1) An individual is creating a small vocabulary that they would like to see used widely but don't have a nice brand-neutral stable domain of their own they can use for the purpose. This one has already been covered in the discussion. (2) I'm a big organization, say the UK Government. I want to use a particular domain (well a set of subdomains) for publishing my data, say *. data.gov.uk. The domain choice is important - it has credibility and promises long term stability. Yet I want to decentralize the publication itself, I want different departments and agencies to publish data and identifiers within the subdomains. The subdomains are supposed to be organization-neural yet the people doing the publication will be based in specific organizations. The PURL design pattern (though not necessarily the specific PURL implementation) is an excellent way to manage the delegation that makes that possible. So my summary answer to Hugh is - they are much more important to the publisher than to the consumer. Dave
RE: PURLs don't matter, at least in the LOD world
Ben, purl.oclc.org is a DNS alias for purl.org and has been since the beginning. There are several others. These domain names work the same from an HTTP protocol POV, but if you're using them as identifiers in RDF don't assume they are interchangeable. Jeff From: Ben O'Steen [mailto:bost...@gmail.com] Sent: Saturday, February 18, 2012 9:19 AM To: Dave Reynolds Cc: public-lod@w3.org Subject: Re: PURLs don't matter, at least in the LOD world A quick related question - does anyone know the status of purl.oclc.org - there was a point in time where the service suggested that this new hostname was going to be the new proper host for purl.org urls. I hope they have abandoned this idea, as one sure way to affect url longevity is to include a organisational brand in it ;) Ben On Feb 18, 2012 1:02 PM, Dave Reynolds dave.e.reyno...@gmail.com wrote: On 17/02/12 21:08, Kingsley Idehen wrote: On 2/17/12 2:18 PM, David Booth wrote: On Fri, 2012-02-17 at 18:48 +, Hugh Glaser wrote: [ . . . ] What happens if I have http://purl.org/dbpedia/Tokyo, which is set to go to http://dbpedia.org/resource/Tokyo? I have (a), (b) and (c) as before. Now if dbpedia.org goes Phut!, we are in exactly the same situation - (b) gets lost. No, the idea is that the administrator for http://purl.org/dbpedia/ updates the redirect, to point to whatever new site is hosting the dbpedia data, so the http://purl.org/dbpedia/Tokyo still works. David, But any admin that oversees a DNS server can do the same thing. What's special about purl in this context? Precisely that they don't require an admin with power over the DNS registration :) To me the PURL design pattern is about delegation authority and it's an important pattern. Two specific use cases at different extremes: (1) An individual is creating a small vocabulary that they would like to see used widely but don't have a nice brand-neutral stable domain of their own they can use for the purpose. This one has already been covered in the discussion. (2) I'm a big organization, say the UK Government. I want to use a particular domain (well a set of subdomains) for publishing my data, say *.data.gov.uk. The domain choice is important - it has credibility and promises long term stability. Yet I want to decentralize the publication itself, I want different departments and agencies to publish data and identifiers within the subdomains. The subdomains are supposed to be organization-neural yet the people doing the publication will be based in specific organizations. The PURL design pattern (though not necessarily the specific PURL implementation) is an excellent way to manage the delegation that makes that possible. So my summary answer to Hugh is - they are much more important to the publisher than to the consumer. Dave
Re: [http-range14] how to publish RDF for Information Resources
On 17 Feb 2012, at 23:14, Kjetil Kjernsmo wrote: In general, the RDFa embedded metadata approach can be replaced by using the link element href in XHTML to pointing to an external RDF document, where the rel=”meta” attribute can be used to indicate a relationship between resources. Yes, but rel=meta is not standardized as far as I know, see http://www.w3.org/TR/html4/types.html#type-links rel=meta is standardized: http://www.w3.org/TR/rdf-syntax-grammar/#section-rdf-in-HTML http://www.w3.org/TR/cooluris/#linking Best, Richard
Re: PURLs don't matter, at least in the LOD world
On 2/18/12 7:57 AM, Dave Reynolds wrote: On 17/02/12 21:08, Kingsley Idehen wrote: On 2/17/12 2:18 PM, David Booth wrote: On Fri, 2012-02-17 at 18:48 +, Hugh Glaser wrote: [ . . . ] What happens if I have http://purl.org/dbpedia/Tokyo, which is set to go to http://dbpedia.org/resource/Tokyo? I have (a), (b) and (c) as before. Now if dbpedia.org goes Phut!, we are in exactly the same situation - (b) gets lost. No, the idea is that the administrator for http://purl.org/dbpedia/ updates the redirect, to point to whatever new site is hosting the dbpedia data, so the http://purl.org/dbpedia/Tokyo still works. David, But any admin that oversees a DNS server can do the same thing. What's special about purl in this context? Precisely that they don't require an admin with power over the DNS registration :) To me the PURL design pattern is about delegation authority and it's an important pattern. Two specific use cases at different extremes: (1) An individual is creating a small vocabulary that they would like to see used widely but don't have a nice brand-neutral stable domain of their own they can use for the purpose. This one has already been covered in the discussion. (2) I'm a big organization, say the UK Government. I want to use a particular domain (well a set of subdomains) for publishing my data, say *.data.gov.uk. The domain choice is important - it has credibility and promises long term stability. Yet I want to decentralize the publication itself, I want different departments and agencies to publish data and identifiers within the subdomains. The subdomains are supposed to be organization-neural yet the people doing the publication will be based in specific organizations. The PURL design pattern (though not necessarily the specific PURL implementation) is an excellent way to manage the delegation that makes that possible. So my summary answer to Hugh is - they are much more important to the publisher than to the consumer. Dave Dave, Don't publishers need to have admin access en route to exploiting the delegation services at purl.org? By this I mean: we are moving from DNS admin to purl.org service admin, per account. At some point in the Linked Data publishing value chain we always hit the admin level privileges matter :-) Ultimately, I believe this issue is one resolved in the Read-Write Web realm where folks control their own data spaces and use those data spaces as launchpads for their Linked Data publishing -- ditto Identity claims declaration. Thus, instead of depending on a single delegation service like purl.org, we end up with a federation of individually controlled Linked Data spaces. I've put out a number of demos that showcase declaration of verifiable identity claims via blog posts, tweets, simple html docs etc. These identity claims are held in profile documents that are really conduits to Linked Data spaces. Each of these spaces is endowed with its own proxy/wrapper URI capability which enables the kind of Linked Data graph portability that folks ultimately expect of a federated Web. Anyway, I agree that purl.org serves a purpose (for sure) on the publishing side. At the same time, I remain unconvinced about the longevity and uniqueness of its value with regards to Linked Data. -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
