Re: Question on moving linked data sets
Hi Antoine, First, congratulations on http://data.bnf.fr/ that is a major milestone! On Thu, Apr 19, 2012 at 10:23 AM, Antoine Isaac ais...@few.vu.nl wrote: We can ask for the people we know to change their links. But identifying the users of URIs seems too manual, error-prone a process. And of course in general we do not want links to be broken. Currently we have done the following: - a 301 moved permanently redirection from the stitch.cs.vu.nl/rameau prototype to data.bnf.fr. - an owl:sameAs statement between the prototype URIs and the production ones, so that a client searching for data on the old URI gets data that enables it to make the connection with the original resource (URI) it was seeking data about. Does that seem ok? What should we do, otherwise? As you know when the SKOS concepts published at lcsh.info moved to id.loc.gov I had a similar situation :-) Like you I chose to do a mixture of technical and social things: - publish information about the move to relevant discussion lists - put some information up at lcsh.info about the move - permanently redirect (301) all resources to their new location (easy since it was the same app, and mod_rewrite could do it) - after a year of redirects I shut down lcsh.info and did not renew the domain (interestingly someone is squatting on it right now attempting to sell it, I think) Generally I think the linked data community should be encouraged to check their links, respect 301 redirects, and update their own link database appropriately. This is what Google and other major search engines do [1], and it's how the Web was designed to work, and continues to grow. While it's certainly cool when URIs don't change [1] I think it is somewhat irrational to expect URIs to be permanent. I hear people gripe about broken URLs in the digital preservation community quite a bit and it is pretty irritating, since any data that isn't actively used tends to rot...URLs really aren't that different. Of course there is certainly value in stable identifiers [1], but I think there is an opportunity for documenting and encouraging best practices on how to manage change (especially with respect to identifiers) in Linked Data. URNs, Namespaces and Registries [2] is partly helpful here, but a more succinct and URI focused presentation is needed. Or maybe a best practice document like this already exists and I haven't seen it yet. If that is the case I trust someone will let me know :-) //Ed [1] http://www.w3.org/Provider/Style/URI.html [2] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50
Re: Question on moving linked data sets
On Thu, Apr 19, 2012 at 11:02 AM, Bernard Vatant bernard.vat...@mondeca.com wrote: My take on this would be to use dcterms:isReplacedBy links rather than owl:sameAs Description of the concepts by BNF might change in the future and although the original identifier is the same, the description might be out of sync at some point. I really like the idea of avoiding the owl:sameAs quagmire with an assertion that has less ontological consequences. When publishing data about data.bnf resources perhaps it might be a bit simpler to use dcterms:replaces instead, e.g. http://data.bnf.fr/ark:/12148/cb14521343b dcterns:replaces http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b . //Ed
Re: Question on moving linked data sets
On Thu, Apr 19, 2012 at 1:23 PM, Ed Summers e...@pobox.com wrote: http://data.bnf.fr/ark:/12148/cb14521343b dcterns:replaces http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b . s/dcterns/dcterms/ //Ed
Re: PURLs don't matter, at least in the LOD world
On Fri, Feb 17, 2012 at 7:02 PM, David Wood da...@3roundstones.com wrote: Given what I personally know of the state of US Government agencies, I'll take your bet whether the Web services of the Library of Congress or OCLC lasts longer :) You might look back at the tortured history of id.loc.gov before we agree to a figure. At least w/ the tortured history of id.loc.gov and lcsh.info I was able to permanently redirect lcsh.info to the appropriate places on id.loc.gov when lcsh.info was slated for retirement. That way anybody who was scrubbing their links (notably the search engines more than the semantic web community) would have updated their links. I'm with Hugh, putting all your identifier eggs in the basket of purl.org (or any 3rd party service) isn't an excuse for not thoughtfully managing your URL namespaces and DNS. Perhaps that's tilting at windmills, but so be it. In my opinion more still needs to be done to educate people about how web architecture actually works instead of getting them to invest in niche software solutions, maintained by a handful of people with consulting contracts on the line. //Ed
Re: Explaining the benefits of http-range14 (was Re: [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs) )
On Wed, Oct 19, 2011 at 12:59 PM, Leigh Dodds leigh.do...@talis.com wrote: So, can we turn things on their head a little. Instead of starting out from a position that we *must* have two different resources, can we instead highlight to people the *benefits* of having different identifiers? That makes it more of a best practice discussion and one based on trade-offs: e.g. this class of software won't be able to process your data correctly, or you'll be limited in how you can publish additional data or metadata in the future. I don't think I've seen anyone approach things from that perspective, but I can't help but think it'll be more compelling. And it also has the benefits of not telling people that they're right or wrong, but just illustrate what trade-offs they are making. I agree Leigh. The argument that you can't deliver an entity like a Galaxy to someone's browser sounds increasingly hollow to me. Nobody really expects that, and the concept of a Representation from WebArch/REST explains it away to most technical people. Plus, we now have examples in the wild like OpenGraphProtocol that seem to be delivering drinks, politicians, hotels, etc to machine agents at Facebook just fine. But there does seem to be a valid design pattern, or even refactoring pattern, in httpRange-14 that is worth documenting. Perhaps a good place would be http://patterns.dataincubator.org/book/? I think positioning httpRange-14 as a MUST instead of a SHOULD or MAY made a lot of sense to get the LOD experiment rolling. It got me personally thinking about the issue of identity in a practical way as I built web applications, that I probably wouldn't otherwise have otherwise done. But it would've been easier if grappling with it was optional, and there were practical examples of where it is useful, instead of having it be an issue of dogma. //Ed
REST and Linked Data (was Minting URIs)
Hi Michael, On Fri, Apr 15, 2011 at 1:57 PM, Michael Hausenblas michael.hausenb...@deri.org wrote: I find [1] a very useful page from a pragmatic perspective. If you're more into books and not only focusing on the data side (see 'REST and Linked Data: a match made for domain driven development?' [2] for more details on data vs. API), I can also recommend [3], which offers some more practical guidance in terms of URI space management. Thanks for the reference to the recent REST and Linked Data [1] paper, I had missed it till now. I had some comments and questions, which I figured couldn't hurt (too much?) to be discussed here: Typically a REST service will assume the resource being transferred in these representations can be considered a document; in the terminology of the following section, an ‘information resource’. I guess in some ways this is a minor quibble, but this seems to me to be a fairly common misconception of REST in the Linked Data community. In his dissertation Roy says this about resources [2]: The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. today's weather in Los Angeles), a collection of other resources, a non-virtual object (e.g. a person), and so on. It is actually pretty common to use URLs to identify real world things when designing a REST API for a domain model. However, if a developer implements some server side functionality to allow (for example) a product to be deleted with an HTTP DELETE to the right URL, they would typically be more concerned with practical issues such as authentication, than with the existential ramifications of deleting the product (should all instances of the product be recalled and destroyed?). Section 3.3 of the REST and Linked Data paper goes on to say: Linked Data services, in implementing the “HTTP range issue 14” solution [12], add semantics to the content negoti- ation to distinguish between URIs that are non-information resources (identifiers for conceptual or real-world objects) and URIs that are information resources (documents) that describe the non-information resources. This is because as- sertions in the RDF graph are usually relationships that ap- ply to the non-information resource, but Linked Data over- loads URI usage so that it is also a mechanism for retrieving triples describing that resource (in a document, i.e. an in- formation resource). (This is a change iin behaviour from earlier use of HTTP URIs in RDF, when they were not ex- pected to be dereferenced.) Was there really a chapter in the history of the Semantic Web where HTTP URIs in RDF were not expected to resolve? Wouldn't that have removed all the machinery for the Web from the Semantic Web? I only really started paying attention to RDF when the Linked Data effort (SWEO) picked up, so I'm just generally interested in this pre-history, and other people's memory of it. Minor quibbles aside, as a web developer I'm a big supporter of the paper's conclusions, which promote REST's notion of Hypertext As The Engine Of Application State (HATEOS), and the semantics that the HTTP Connector provides, in the Linked Data space: 3. Services that publish Linked Data resources should pay careful consideration to HATEOAS as a viable altern- ative SPARQL, and identify resources to enable REST- ful use of the API. 4. RESTful methods should be developed for the write- enabled Web of Data. Thanks to the authors (cc'd here) for writing that down and presenting it forcefully. //Ed [1] http://ws-rest.org/2011/proc/a5-page.pdf [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
Re: [ANN] Linked Open Colors
Hi Sergio, Thanks for the update about this new, much needed service! While perusing the data from the command line with rapper I noticed that: http://data.colourphon.co.uk/id/colourscheme/triadic/ff6347 rdfs:label triadic colours to compliment Coral (ff6347) . ISO 01.070 [1] clearly defines this color as Tomato. I think we can all agree that the identity of colors is a solved problem, and it would be great if this Linked Data service could be updated to reflect this. I started a Doodle Poll to see if we can find a time to meet to discuss whether a W3C Working Group or Incubator Group might be needed to resolve this issue. //Ed [1] http://bit.ly/gWCSql [2] http://www.doodle.com/geyvyrx4wzgvky5s
Re: Low Quality Data (was before Re: AW: ANN: LOD Cloud - Statistics and compliance with best practices)
Somewhat related: the CPAN folks coined their own term for code quality (kwalitee), with precise measures, which takes some of the subjectiveness out of the equation: http://qa.perl.org/phalanx/kwalitee.html Perhaps something like this could work for linked data quality? //Ed
Re: empirical cloud
Hi Antoine: On Tue, Sep 21, 2010 at 3:58 AM, Antoine Isaac ais...@few.vu.nl wrote: By complete chance I spotted a small bibsonomy.org node attached to semanticweb.org through dblp.l3s.de. But there is also a www.bibsonomy.org node (much bigger). Are they supposed to be the same? Are there other cases? No they're not supposed to be the same, at least in the little visualization I did. If there's a sensible heuristic for merging them I'd be willing to try it out though. //Ed
empirical cloud
The discussion about updating the Linking Open Data cloud got me thinking it would be interesting to try to visualize the actual owl:sameAs links in the Billion Triple Challenge dataset [1]. It turned out to be relatively easy to get something somewhat workable with tools like zgrep, sort, uniq, a couple of custom scripts, and the handy ProtoVis library [2]. You can view the result at: http://inkdroid.org/empirical-cloud/ If you notice the links to the rdf/xml and Turtle you'll see I tried my hand at representing the underlying data using void, foaf and dcterms. There's definitely room for improvement, so if you are so inclined please tinker with it and send me a pull request on GitHub [3]. Thanks to Gunnar Grimnes and Dan Brickley for ideas and help. //Ed [1] http://challenge.semanticweb.org/ [2] http://vis.stanford.edu/protovis/ [3] http://github.com/edsu/empirical-cloud
Re: LOB - linked open bard
Hi Toby, Do you have idea where the file URIs are coming from? rapper -o turtle http://ontologi.es/lob/ //Ed On Fri, Sep 3, 2010 at 7:44 PM, Toby Inkster t...@g5n.co.uk wrote: Every play by Shakespeare in RDF: http://ontologi.es/lob/ For example: http://ontologi.es/lob/Hamlet.ttl Two Noble Kinsmen is not included, as I couldn't find a good XML version to convert to RDF, and Shakespeare only co-wrote it anyway.
Re: Semantic Web at SXSW
I wonder if it might be worthwhile approaching Manu Sporny about putting in a proposal to talk about rdfa, microformats, his recent work with json, or something else relevant/timely that he thinks might fit? As Dan Brickley pointed out recently [1], the semweb/ linkeddata crowd really share 99.9% of their geek DNA with the microformats community...and Manu has done a really great job bridging the two communities. Microformats have been a popular topic at past sxsw conferences. Thanks for continuing to push on this Juan. //Ed [1] http://lists.w3.org/Archives/Public/public-lod/2010Jul/0020.html
Fwd: Free Linked Data Webinar
This could be of potential interest to Linked Data folks who work in cultural heritage institutions (libraries, archives, musuems, etc). //Ed -- Forwarded message -- From: Roy Tennant roytenn...@gmail.com Date: Fri, May 21, 2010 at 5:15 PM Subject: [CODE4LIB] Free Linked Data Webinar To: code4...@listserv.nd.edu My colleague Ralph LeVan, whom many of you know, is giving a free webinar on Linked Data in our OCLC Research webinar series Technical Advances for Innovation in Cultural Heritage Institutions (TAI CHI). It will be on 27 May at 2PM EDT. To find out more and to register go here: http://www.oclc.org/research/news/2010-05-21.htm Also, there will be a recording made available afterwards. Anyone who has heard Ralph speak knows that he is gifted at making complex topics understandable. So if you're wondering about what all the fuss is about regarding Linked Data, this will be something not to miss. Thanks, Roy Tennant OCLC Research
Re: rdf/json
Perhaps this has already been suggested, but the linked-data-api folks have an overview of json serializations for rdf [1] that might be of some interest. //Ed [1] http://code.google.com/p/linked-data-api/wiki/JSONFormats
Re: Linked data in packaged content (ePub)
On Tue, Apr 27, 2010 at 4:40 PM, Stuart A. Yeates syea...@gmail.com wrote: Does anyone know of any other attempts to put linked data into packages like this? While arguably not Linked Data per-se, you might be interested in work being done on the Open Publication Distribution System (OPDS) [1], which aims to use Atom for making metadata about ebooks available. A key part of an OPDS feed are opds:acquisition links between an atom:entry and a epub document identified with a URI and a media type, for example: link type=application/epub+zip href=http://www.feedbooks.com/book/4440.epub; rel=http://opds-spec.org/acquisition/ Implementors include people at O'Reilly, Internet Archive, Ibis Reader, FeedBooks, to name a few. Much of the work is actually going on in open bi-weekly conference calls, and on a discussion list [3] if you are interested. On a recent call Hadrien Gardeur of Feedbooks was talking about embedding opds atom documents in the ebook serializations, so it might be worthwhile pinging him and/or the discussion list to see where things are at. //Ed [1] http://code.google.com/p/openpub/wiki/CatalogSpecDraft [2] http://ibisreader.com/ [3] http://groups.google.com/group/openpub
Re: LOD Camp at WWW2010....
Hi Ivan, So it looks like students could go to the entire day of Linked Open Data Camp by paying $75.00? //Ed On Tue, Apr 20, 2010 at 12:19 PM, Ivan Herman i...@w3.org wrote: This is just a reminder that there will be an LOD camp at the WWW Conference next week in Raleigh: http://www.w3.org/2010/04/w3c-track.html you should sign up on http://esw.w3.org/topic/LODCampW3CTrack you can also add your favourite topic right now on the wiki page, or leave for the discussion over there... Ivan Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Re: Hungarian National Library published its entire OPAC and Digital Library as Linked Data
Sorry I had a small typo in that oai-ore example I included. I meant to type ore:aggregates instead of ore-aggregates. I also meant to include assertions about the format of the files, which can be handy to have. //Ed http://oszkdk.oszk.hu/resource/DRJ/404 dc:creator http://nektar.oszk.hu/resource/auth/33589, Jókai Mór,, (1825-1904.) ; dc:date cop. 2006 ; dc:description Működési követelmények: Adobe Reader / MS Reader , Főcím a címképernyőről, Szöveg (pdf : 1.2 MB) (lit : 546 KB) ; dc:identifier , 963-606-169-6 (pdf), 963-606-170-X (lit) ; dc:language hun ; dc:publisher Szentendre : Mercator Stúdió ; dc:subject http://nektar.oszk.hu/resource/auth/magyar_irodalom, magyar irodalom. ; dc:title Dekameron ; dc:type book, elbeszélés., elektronikus dokumentum., no type provided ; ore:aggregate http://oszkdk.oszk.hu/storage/00/00/04/04/dd/1/dekameron.pdf, http://oszkdk.oszk.hu/storage/00/00/04/04/dd/2/dekameron.lit . http://oszkdk.oszk.hu/storage/00/00/04/04/dd/1/dekameron.pdf dc:format application/pdf . http://oszkdk.oszk.hu/storage/00/00/04/04/dd/2/dekameron.lit dc:format application/x-ms-reader .
Re: CoIN: Composition of Identifier Names
2010/4/13 Richard Cyganiak rich...@cyganiak.de:
I think that URI Templates [3] might be a handy companion syntax for CoIN
and I wonder if they could be integrated into CoIN. I'm thinking more about
the general curly-brace-syntax rather than the fancy details. So perhaps you
could start with something like
http://example.org/publ/{publisher}/{document}
http://example.org/publ/{publisher}/{document}/rev/{date}
http://example.org/profiles/{name}
I second the idea of exploring the use of URI Templates for
documenting how to construct a URL from other data. I'm not sure if
it's part of the latest URI Templates draft [1], but OpenSearch allows
parameter names to be defined with namespaces [2]. For example:
?xml version=1.0 encoding=UTF-8?
OpenSearchDescription xmlns=http://a9.com/-/spec/opensearch/1.1/;
xmlns:geo=http://a9.com/-/opensearch/extensions/geo/1.0/;
Url type=application/vnd.google-earth.kml+xml
template=http://example.com/?q={searchTerms}pw={startPage?}bbox={geo:box?}format=kml/
/OpenSearchDescription
Note, the use of the geo namespace and the geo:box parameter name? So
you could imagine a URL template that referenced names from an RDF
vocabulary:
Url type=application/rdf+xml
template=http://example.com/user/{foaf:mbox_sha1sum}; /
OpenSearch was an incubator for the ideas that led to the URI
Templates draft, and is built into many modern web browsers (IE,
Firefox, Chrome).
//Ed
[1] http://tools.ietf.org/html/draft-gregorio-uritemplate-04
[2] http://www.opensearch.org/Specifications/OpenSearch/1.1#Parameter_names
Re: Using predicates which have no ontology?
Hi Michael, Would it be hard to remove the empty literal assertions? e.g. -- http://www.iana.org/assignments/relation/alternate a awol:RelationType ; rdfs:label alternate ; dcterms:dateAccepted ; dcterms:description ; rdfs:isDefinedBy http://www.iana.org/go/rfc4287 . -- It's interesting that the latest efforts to create a Link Relation Registry seem to be intentionally avoiding publishing machine readable data for the registry [1]. I was wondering if Mark Nottingham's efforts to revamp link relations might present a good opportunity for us to lobby the IETF to start publishing a bit of RDFa for the link relations registry... //Ed [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-09#appendix-A
JISC Grant Funding for Linked Data
I just noticed that a recent JISC Grant Funding Call [1] includes some funding available for Linked Data publishing projects by higher education institutions in the UK: Strand B - Expose Projects that enable content to be made available on the Web using structured data, in particular linked data which increases its potential value to researchers, teachers and learners. Total funds: £750,000. Up to 20 projects will be funded. Maximum funding for any one project is £100,000. A Briefing Document is available alongside this call, which outlines key background and scope information to which bidders should refer. The deadline for receipt of proposals in response to this call is 12 noon UK time on Tuesday 20 April 2010. //Ed [1] http://www.jisc.ac.uk/fundingopportunities/funding_calls/2010/03/210depositexpose.aspx
Re: Linking HTML pages and data
Hi Sean, On Tue, Feb 16, 2010 at 7:39 AM, Sean Bechhofer sean.bechho...@manchester.ac.uk wrote: A simple (possibly dumb) question. Is there a standard mechanism for linking an HTML page to the non-information resource that it describes? Not a dumb question at all--at least for me :-) I've been using the link pattern that Chris Bizer, Richard Cyganiak and Tom Heath documented in How To Publish Linked Data On The Web [1] for discovery of RDF documents that are related to a given HTML document. But you are asking about the relation between a document and the the *thing* being described. I agree with Damien that foaf:primaryTopic seems like it could work, and that one possibility would be to slip a bit of RDFa into the HTML document that asserted: foaf:primaryTopic http://dbpedia.org/resource/Mogwai_(band) . I also agree w/ Kingsley that it would be neat to also have a link pattern that non-RDFa folks could use: link rel=http://xmlns.com/foaf/0.1/primaryTopic; href=http://dbpedia.org/resource/Mogwai_(band) title=Mogwai / Or if mnot's Web Linking RFC is approved it would open the door to using the Link HTTP Header: Link: http://dbpedia.org/resource/Mogwai_(band); rel=http://xmlns.com/foaf/0.1/primaryTopic;; title=Mogwai Registering [3] primaryTopic as a link relation type would tighten it up a bit, as well as help advertise the pattern. link rel=primaryTopic href=http://dbpedia.org/resource/Mogwai_(band) title=Mogwai / At any rate, I'd be interested to hear if other people have other approaches to this. It would be nice to have a little recipe (w3c note?) people could follow when making these sorts of assertions on the web. Assuming one isn't there already of course :-) //Ed PS. the oai-ore folks had a similar use case to link descriptions to the thing being described. They ended up creating a new term oai:describes [4], and documented ways of layering assertions into rdf [5], atom [6] and html [7] documents. I think the vocabulary is probably too specific to aggregations and resource maps to be useful in the general case you are talking about though. PSS. I really just wanted to type Mogwai a bunch of times :-) [1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/#discovery [2] http://tools.ietf.org/html/draft-nottingham-http-link-header-07 [3] http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-6.2 [4] http://www.openarchives.org/ore/1.0/vocabulary#ore-describes [5] http://www.openarchives.org/ore/1.0/rdfxml#remtoaggr [6] http://www.openarchives.org/ore/1.0/atom#metadata [7] http://www.openarchives.org/ore/1.0/discovery#HTMLLinkElement
Re: Linking HTML pages and data
On Tue, Feb 16, 2010 at 5:51 PM, Ian Davis li...@iandavis.com wrote: You can see it in use on data.gov.uk: http://education.data.gov.uk/doc/school/56 contains: link rel=primarytopic href=http://education.data.gov.uk/id/school/56; / Wow, thanks Ian. I hadn't noticed this pattern in use at data.gov.uk. It seems like a worthwhile pattern to encourage people to follow, by adding it to the How to Publish Linked Data on the Web [1] ... or elsewhere? //Ed [1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
Re: [pedantic-web] ANN: 20th Century Press Archives as ORE / Linked Data application - Technical Preview
On Mon, Dec 28, 2009 at 8:07 AM, Neubert Joachim j.neub...@zbw.eu wrote: Please feel invited to take a look at it - we would highly appreciate any feedback about our approach. Thanks for announcing this Joachim. It is great to see more linked data as rdfa getting out on the web. I'm particularly excited because of your use of the oai-ore vocabulary to make historic newspaper archives available, since we are doing something similar at the Library of Congress [1]. You must've done something right because I just wrote a little naive crawler [2] in a matter of minutes to pull down what looks like all the rdfa you've put out there so far. It seem to have collected about 11,427 triples [3]. My rdfsum unix command line hack [4] came up with these rdf:type counts: 1533 http://www.openarchives.org/ore/terms/AggregatedResource 526 http://www.openarchives.org/ore/terms/ResourceMap 526 http://www.openarchives.org/ore/terms/Aggregation 336 http://zbw.eu/namespaces/skos-extensions/PmPage 185 http://purl.org/ontology/bibo/Article 2 http://zbw.eu/namespaces/skos-extensions/PmPersonFolder 2 http://zbw.eu/namespaces/skos-extensions/PmCollection Does that sound about right for this initial release? I noticed that you have chosen to link to names in the German National Authority file like: http://zbw.eu/beta/pm20/person/00012 dct:subject http://d-nb.info/gnd/118646419 . I seem to remember hearing at SWIB09 [5] that the Deutsche National Bibliothek was thinking about minting URIs for entries in the authority file that follow Linked Data best practices (hash or 303, etc). Were you planning on modifying these appropriately when those URLs became available? Right now the d-nb URL returns 200 OK, and it isn't a hash URI. Theoretically it would be pretty easy to layer in some rdfa into the page at d-nb that describes: http://d-nb.info/gnd/118646419#person But I realize this is somewhat out of your control. I guess it would also be possible to create a partial PURL [6] for http://d-nb.info/gnd/ that would redirect, since I think the new PURL software supports 303. I was also interested to see that you have published some SKOS Extensions [7] that are used to type each ore:Aggregation as a specialization of skos:Concept: http://zbw.eu/beta/pm20/person/00012 a ore:Aggregation, http://zbw.eu/namespaces/skos-extensions/PmPersonFolder ; skos:prefLabel Abbe, Ernst; 1840-1905 (PM20 Personenarchiv)@de, Abbe, Ernst; 1840-1905 (PM20 Persons Archives)@en . It looks like the rdf that comes back for your skos extensions vocabulary (nice hack with the rdf validator btw) doesn't define PmPersonFolder--but perhaps I missed it? I'm guessing from the skos:prefLabel assertion that the PmPersonFolder is a specialization of skos:Concept? Would it be OK for me to experiment with pulling down the aggregated resource bitstreams (jpg, etc) and storing them on disk? It would just be a single threaded little script. Part of the rationale behind the ore use at LC [1] is to foster LOCKSS [8] scenarios where digital objects are easier to meaningfully harvest. Anyhow, I have rattled on enough for now I suppose -- I mainly wanted to say how exciting it was to see your announcement, being from the digital library tribe in the linked data community :-) //Ed [1] http://chroniclingamerica.loc.gov [2] http://inkdroid.org/bzr/ptolemy/crawl.py [3] http://inkdroid.org/data/pm20.txt [4] http://inkdroid.org/bzr/bin/rdfsum [5] http://www.swib09.de/ [6] http://purl.org [7] http://zbw.eu/namespaces/skos-extensions/ [8] http://en.wikipedia.org/wiki/LOCKSS
Re: RDF Update Feeds
At the Library of Congress we've been experimenting with using an Atom feed to alert subscribers to new resources available at id.loc.gov [1]. The approach is similar to what Niklas' is doing, although we kind of independently arrived at this approach (which was nice to discover). Creates, updates and deletes happen on a weekly basis, so it's important for us to let interested parties know what has changed. We ended up using Atom Tombstones [2] for representing the deletes. And Atom Feed Paging and Archiving (RFC 5005) [3] to allow clients to drill backwards through time. I just noticed Link Relations for Simple Version Navigation [4] get announced on an Atom related discussion list, which looks like it could be useful as well, if you maintain a version history. I'd be interested in any feedback anyone has about using this approach. //Ed [1] http://id.loc.gov/authorities/feed/ [2] http://ietfreport.isoc.org/all-ids/draft-snell-atompub-tombstones-06.txt [3] http://tools.ietf.org/rfc/rfc5005.txt [4] http://www.ietf.org/id/draft-brown-versioning-link-relations-03.txt
Re: RDF Update Feeds
On Fri, Nov 20, 2009 at 11:05 AM, Nathan nat...@webr3.org wrote: is this not the same as (or vi similar to) the court approach outlined here: http://code.google.com/p/court/ by Niklas Yes, absolutely. Although I had no idea of Niklas' work at the time. That's why I said: At the Library of Congress we've been experimenting with using an Atom feed to alert subscribers to new resources available at id.loc.gov [1]. The approach is similar to what Niklas' is doing, although we kind of independently arrived at this approach (which was nice to discover). :-) //Ed
Re: Top three levels of Dewey Decimal Classification published as linked data
On Thu, Aug 20, 2009 at 3:53 AM, Bernard Vatantbernard.vat...@mondeca.com wrote: http://dewey.info/class/641/ cc:attributionName OCLC Online Computer Library Center, Inc. ; cc:attributionURL http://www.oclc.org/dewey/ ; cc:morePermissions http://www.oclc.org/dewey/about/licensing/ ; dct:hasVersion http://dewey.info/class/641/2009/08/ ; dct:language de^^dct:RFC4646 ; a skos:Concept ; xhtml:license http://creativecommons.org/licenses/by-nc-nd/3.0/ ; skos:broader http://dewey.info/class/64/2003/08/about.de ; skos:inScheme http://dewey.info/scheme/2003/08/about.de ; skos:notation 641^^http://dewey.info/schema-terms/Notation ; skos:prefLabel Food drink@en, Essen und Trinken@de . Maybe rather : skos:broader http://dewey.info/class/64/2003/ ; skos:inScheme http://dewey.info/scheme/2003/08/ ; Yes, thanks Bernard. In my haste I forgot to remove the language specific-ness from the skos:broader assertions in my email to Michael. I might actually recommend that the version information is removed from the object in the broader relation too: http://dewey.info/class/641/ skos:broader http://dewey.info/class/64/2003/ . As it stands now a document URI is being used in the object position, instead of the URI for the concept. uqbar:~ ed$ curl -I http://dewey.info/class/64/2003/08/about.de HTTP/1.1 200 OK Date: Thu, 20 Aug 2009 09:27:32 GMT Server: Apache/2.2.11 (Unix) PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Location: http://dewey.info/class/64/2003/08/about.de.rdf Vary: Accept Content-Length: 2115 Content-Type: application/rdf+xml //Ed
Re: Top three levels of Dewey Decimal Classification published as linked data
Hi Michael, This is really exciting news, especially for those of us Linked Data enthusiasts in the world of libraries and archives. Congratulations! I haven't fully read the wiki page yet, so I apologize if this question is already answered there. I was wondering why you chose to mint multiple URIs for the same concept in different languages. For example: uqbar:~ ed$ rapper -o turtle http://dewey.info/class/641/ @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix xhtml: http://www.w3.org/1999/xhtml/vocab# . @prefix cc: http://creativecommons.org/ns# . @prefix dct: http://purl.org/dc/terms/ . @prefix skos: http://www.w3.org/2004/02/skos/core# . http://dewey.info/class/641/2009/08/about.en cc:attributionName OCLC Online Computer Library Center, Inc. ; cc:attributionURL http://www.oclc.org/dewey/ ; cc:morePermissions http://www.oclc.org/dewey/about/licensing/ ; dct:isVersionOf http://dewey.info/class/641/ ; dct:language en^^dct:RFC4646 ; a skos:Concept ; xhtml:license http://creativecommons.org/licenses/by-nc-nd/3.0/ ; skos:broader http://dewey.info/class/64/2009/08/about.en ; skos:inScheme http://dewey.info/scheme/2009/08/about.en ; skos:notation 641^^http://dewey.info/schema-terms/Notation ; http://dewey.info/class/641/2003/08/about.de cc:attributionName OCLC Online Computer Library Center, Inc. ; cc:attributionURL http://www.oclc.org/dewey/ ; cc:morePermissions http://www.oclc.org/dewey/about/licensing/ ; dct:isVersionOf http://dewey.info/class/641/ ; dct:language de^^dct:RFC4646 ; a skos:Concept ; xhtml:license http://creativecommons.org/licenses/by-nc-nd/3.0/ ; skos:broader http://dewey.info/class/64/2003/08/about.de ; skos:inScheme http://dewey.info/scheme/2003/08/about.de ; skos:notation 641^^http://dewey.info/schema-terms/Notation ; skos:prefLabel Essen und Trinken@de . ... I kind of expected the assertions to hang off of a language and version agnostic URI, with perhaps dct:hasVersion links to previous versions. http://dewey.info/class/641/ cc:attributionName OCLC Online Computer Library Center, Inc. ; cc:attributionURL http://www.oclc.org/dewey/ ; cc:morePermissions http://www.oclc.org/dewey/about/licensing/ ; dct:hasVersion http://dewey.info/class/641/2009/08/ ; dct:language de^^dct:RFC4646 ; a skos:Concept ; xhtml:license http://creativecommons.org/licenses/by-nc-nd/3.0/ ; skos:broader http://dewey.info/class/64/2003/08/about.de ; skos:inScheme http://dewey.info/scheme/2003/08/about.de ; skos:notation 641^^http://dewey.info/schema-terms/Notation ; skos:prefLabel Food drink@en, Essen und Trinken@de . See how multiple skos:prefLabel assertions can be made using the same subject? To illustrate why I think this is important consider how someone may use the resources at dewey.info: http://openlibrary.org/b/OL11604988M dct:subject http://dewey.info/class/641/ . If we follow our nose to http://dewey.info/class/641 we will get back some RDF, but the description we get isn't about the subject http://dewey.info/class/641/ so what are we to make of the above assertion? Another unrelated thing I noticed is that the RDFa doesn't seem to be usable by the RDFa Distiller: http://tinyurl.com/nm8lfa Sorry if this was too long. Let me just say again how exciting it is to see this work coming out of OCLC. //Ed
Chronicling America and Linked Data pt. 2
I forgot to mention that if you are interested in reading more about the use of the Object Reuse and Exchange vocabulary (OAI-ORE) in linked data, and web based digital repositories you'll want to check out this recent paper from LDOW2009: H. Van de Sompel, C. Lagoze, M. Nelson, S. Warner, R. Sanderson, P. Johnston. Adding eScience Assets to the Data Web. Linked Data on the Web (LDOW2009). April 20th 2009. Madrid, Spain. http://events.linkeddata.org/ldow2009/papers/ldow2009_paper8.pdf //Ed
Chronicling America and Linked Data
There is a new pool of linked-data up at the Library of Congress in the Chronicling America application [1]. Chronicling America is the web view on data collected for the National Digital Newspaper Program (NDNP). NDNP is a 20-year joint project of the National Endowment for the Humanities and the Library of Congress to digitize and aggregate historic newspaper in the United States. Right now there are close to a million digitized newspaper pages available, and information about 140,000 newspaper titles...all of which have individual web views, for example: Newspaper Title: San Francisco Call [2] Issue: San Francisco Call, 1895-03-05 [3] Page: San Francisco Call, 1895-03-05, page sequence 1 [4] If you view source on them you should be able to auto-discover the application/rdf+xml representations that bundle up information about the newspaper titles, issues and pages. You can also browse around using a linked data viewer like uriburner [5]. The implementation is a moving target, but you'll see we've cherry picked a few vocabularies: Dublin Core [6], Bibliographic Ontology [7], FOAF [8], and Object Reuse and Exchange (OAI-ORE) [9]. ORE in particular was extremely useful to us, since we wanted to enable the application's repository function, by exposing the digital objects (image files, ocr/xml files, pdfs) that make up the individual Page resources. For example: http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1#page ore:aggregates http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1.jp2, http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1.pdf, http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1/ocr.txt, http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1/ocr.xml, http://chroniclingamerica.loc.gov/lccn/sn84026749/1905-01-29/ed-1/seq-1/thumbnail.jpg . The idea is to enable the harvesting of these repository objects out of the Chronicling American webapp. The only links out we have so far are from Newspaper Titles to the geographic regions that they are about, and languages. So for example: http://chroniclingamerica.loc.gov/lccn/sn85066387#title dcterms:coverage http://dbpedia.org/resource/San_Francisco%2C_California, http://sws.geonames.org/5391959/ ; dcterms:language http://www.lingvoj.org/lang/en . Just these minimal links provide a huge amount of data enrichment to our original data. We also needed to create a handful of new vocabulary terms, which we made available as RDFa [10]. I would be interested in any feedback you have. Also, please feel free to fire up linked-data bots to crawl the space. //Ed [1] http://chroniclingamerica.loc.gov [2] http://chroniclingamerica.loc.gov/lccn/sn85066387/ [3] http://chroniclingamerica.loc.gov/lccn/sn85066387/1895-03-05/ed-1/ [4] http://chroniclingamerica.loc.gov/lccn/sn85066387/1895-03-05/ed-1/seq-1/ [5] http://linkeddata.uriburner.com/about/html/http/chroniclingamerica.loc.gov/lccn/sn84026749%23title [6] http://dublincore.org/ [7] http://bibliontology.com/ [8] http://xmlns.com/foaf/spec/ [9] http://www.openarchives.org/ore/1.0/vocabulary.html [10] http://chroniclingamerica.loc.gov/terms/
Re: Chronicling America and Linked Data pt. 2
On Tue, May 26, 2009 at 12:33 PM, Dan Brickley dan...@danbri.org wrote: BTW Ed, Chronicling America looks great. Nice work as ever :) Is there any people-describing data in there, or will there be? Thanks Dan. It's funny you ask, because so far the predominant users of Chronicling America have been genealogists looking for people :-) At the moment (apart from metadata about newspaper titles, and issues) we only have OCR for the pages, which allows us to see what words appear where on the page for indexing and highlighting. We definitely want to do more mining of the text, looking for names, dates, places, etc embedded in the articles. Part of the hope is that by releasing the data interested people can mine it themselves, and publish assertions like: http://chroniclingamerica.loc.gov/lccn/sn86069133/1909-02-02/ed-1/seq-7#page dct:subject http://dbpedia.org/resource/Abraham_Lincoln . Perhaps we'll eventually get around to providing functionality in the app that makes it easy to do this sort of annotation. At the moment there aren't any plans to do so, but we're already tossing around ideas for a new user interface, so I am hopeful. If you have any ideas please feel free to send them here or to me privately. //Ed
Re: Suggestions/existing material for Linked Data tutorial?
On Fri, Nov 14, 2008 at 6:40 AM, Yves Raimond [EMAIL PROTECTED] wrote: We plan to publish, with Keith, a small how-to for doing a hands-on tutorial like the Web-of-data 101 session we did at the WOD-PD event. With Richard's permission, we'll also take a few things from his session, where he used some of the data we created during our session. The goal of this how-to is to make it easy for people to reproduce the tutorial in different places. This would be extremely helpful to me and some others who are thinking of doing a linked-data tutorial at code4lib2009 [1]. Please post a message here when any of the materials materialize! //Ed [1] http://code4lib.org/2009
Re: Linked data at Freebase
Hi Yves: Wow, this is exciting news! I wonder would it be a quick fix to get the service doing a 303 instead of a 302: uqbar:~ ed$ curl -I http://rdf.freebase.com/ns/en.blade_runner HTTP/1.0 302 FOUND Server: PasteWSGIServer/0.5 Python/2.4.4 Date: Wed, 29 Oct 2008 04:10:11 GMT content-type: text/html; charset=utf-8 location: http://rdf.freebase.com/rdf/en/blade_runner pragma: no-cache cache-control: no-cache Connection: close Also, could the HTML views (e.g. http://www.freebase.com/view/en/blade_runner) have a bit of autodiscovery for the data view? head ... link rel=alternate type=application/turtle href=http://rdf.freebase.com/rdf/en/blade_runner; title=rdf / ... /head This would allow agents that care about the RDF view to be able to discover it while browsing the web of documents. Nice work! //Ed PS. You can use Vapour the Linked Data Validator to help with some of this checking: for example http://idi.fundacionctic.org/vapour?vocabUri=http%3A%2F%2Frdf.freebase.com%2Fns%2Fen.blade_runnerclassUri=http%3A%2F%2FpropertyUri=http%3A%2F%2FinstanceUri=http%3A%2F%2FdefaultResponse=dontmind On Wed, Oct 29, 2008 at 4:37 AM, Yves Raimond [EMAIL PROTECTED] wrote: Hello! Live from ISWC2008, I thought most of the people on this list would be interested in that: http://rdf.freebase.com/ Freebase now produces linked data! (now, to see whether it links to other datasets :-) ) Cheers! y
Re: Drilling into the LOD Cloud
On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello [EMAIL PROTECTED] wrote: I really support your idea for a lod cloud that's actually useful to write queries, i promise we'll do the best from sindice to deliver one such a thing. That sounds like a great idea for a service. Right now I just need a little diagram that illustrates the links between resources in the LOD cloud; and the diversity of descriptions from each provider. But, I guess I should stop begging on here, and just create it eh? Thanks for the feedback, //Ed
Re: Drilling into the LOD Cloud
Yep, that's the plan .. just wondering if someone had some slideware content to that effect already :-) //Ed On Mon, Sep 22, 2008 at 4:42 PM, Kingsley Idehen [EMAIL PROTECTED] wrote: Ed Summers wrote: On Mon, Sep 22, 2008 at 1:28 PM, Giovanni Tummarello [EMAIL PROTECTED] wrote: I really support your idea for a lod cloud that's actually useful to write queries, i promise we'll do the best from sindice to deliver one such a thing. That sounds like a great idea for a service. Right now I just need a little diagram that illustrates the links between resources in the LOD cloud; and the diversity of descriptions from each provider. But, I guess I should stop begging on here, and just create it eh? Thanks for the feedback, //Ed Ed, Are you not able to add additional rdf:type links between DBpedia and the following: 1. Yago 2. OpenCyc 3. UMBEL Then between UMBEL and OpenCyc: 1. owl:sameAs 2. owl:equivalentClass Then between OpenCyc and Wordnet: 1. owl:sameAs -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Library of Congress Subject Headings as SKOS Linked Data
I'd like to announce an experimental linked-data, SKOS representation of the Library of Congress Subject Headings (LCSH) [1] ... and also ask for some help. The Library of Congress has been participating in the W3C Semantic Web Deployment Working Group, and has converted LCSH from the MARC21 data format [2] to SKOS. LCSH is a controlled vocabulary used to index materials that have been added to the collections at the Library of Congress. It has been in active development since 1898, and was first published in 1914 so that other libraries and bibliographic utilities could use and adapt it. The lcsh.info service makes 266,857 subject headings available as SKOS concepts, which amounts to 2,441,494 triples that are separately downloadable [3] (since there isn't a SPARQL endpoint just yet). At the last SWDWG telecon some questions came up about the way concepts are identified, and made available via HTTP. Since we're hoping lcsh.info can serve as an implementation of SKOS for the W3C recommendation process we want to make sure we do this right. So I was hoping interested members of the linked-data and SKOS communities could take a look and make sure the implementation looks correct. Each concept is identified with a URI like: http://lcsh.info/sh95000541#concept When responding to requests for concept URIs, the server content negotiates to determine which representation of the concept to return: - application/xhtml+xml - application/json - text/n3 - application/rdf+xml This is basically the pattern that Cool URIs for the Semantic Web discusses as the Hash URI with Content Negotiation [4]. An additional point that is worth mentioning is that the XHTML representation includes RDFa, that also describes the concept. At the moment the LCSH/SKOS data is only linked to itself, through assertions that involve skos:broader, skos:narrower, and skos:related. But the hope is that minting URIs for LCSH will allow it to be mapped and/or linked to concepts in other vocabularies: dbpedia, geonames, etc. Any feedback, criticisms, ideas are welcome either on either the public-lod [5] or public-swd-wg [6] discussion lists. Thanks for reading this far! //Ed [1] http://lcsh.info [2] http://www.loc.gov/marc/ [3] http://lcsh.info/static/lcsh.nt [4] http://www.w3.org/TR/cooluris/#hashuri [5] http://lists.w3.org/Archives/Public/public-lod/ [6] http://lists.w3.org/Archives/Public/public-swd-wg/
