Web Science and Digital Libraries Research Group

Extending our previous discussion about how the proposed rel="identifier" is different from rel="canonical" (spoiler alert: "canonical" is only for pages with duplicative text ), here I summarize various discussions about why we can't use rel="bookmark" for the proposed scenarios .  We've already given a brief review of why rel="bookmark" won't work (spoiler alert: it is explicitly prohibited for HTML <link> elements or HTTP Link: headers) but here we more deeply explore the likely original semantics.  I say "likely original semantics" because: the short phrases in the IANA link relations registry ("Gives a permanent link to use for bookmarking purposes") and the HTML5 specification ("Gives the permalink for the nearest ancestor section") are not especially clear, nor is the example in the HTML5 specification.  rel="bookmark" exists to address a problem, anonymous co...

The rel="identifier" draft has been submitted to the IETF.  Some of the feedback we've received via Twitter and email are variations of 'why don't you use rel="canonical" to link to the DOI?'  We discussed this in our original blog post about rel="identifier" , but in fairness that post discussed a great deal of things and through updates and comments it has become quite lengthy.  The short answer is that rel="canonical" handles cases where there are two or more URIs for a single resource (AKA " URI aliases "), whereas  rel="identifier" specifies relationships between multiple resources. Having two or more URIs for the same resource is also known as " DUST: different URLs, similar text ".  This is common place with SEO and catalogs (see the 2009 Google blog post and help center article about rel="canonical").  RFC 6596 gives abstract examples, but below we will examine real world e...

Since the advent of the web, more elements of scholarly communication are occurring online . A world that once consisted mostly of conference proceedings, books, and journal articles now includes blog posts, project websites, datasets, software projects, and more. Efforts like LOCKSS , CLOCKSS , and Portico preserve the existing journal system, but there is no similar dedicated effort for the web presence of scholarly communication . Because web-based scholarly communication is born on the web, it can benefit from web archiving . This is complicated by the complexity of scholarly objects. Consider a dataset on the website Figshare , whose landing page is shown in Fig. 1. Each dataset on Figshare has a landing page consisting of a title, owner name, brief description, licensing information, and links to bibliographic metadata in various forms. If an archivist merely downloads the dataset and ignores the rest, then a future scholar using their holdings is denied context and addit...

The Coalition for Networked Information (CNI) Spring 2017 Membership Meeting was held April 3-4, 2017 in Albuquerque, NM.  As before, the presentations were of very high quality but the eight-way (!) split of presentations means that you're going to miss some good presentations.  The full schedule is available, but this trip report will focus on the sessions that I was able to attend.   Fortunately, the attendees did well-covered in Twitter ( #cni17s ), and the tweets are collected by both CNI ( Day 1 , Day 2 ) and Michael Collins ( Day 1 , Day 2 ).  The presentation slides are being collected at OSF .     The first day began with a plenary by Alison J. Head , representing Project Information Literacy (PIL).  Alison's talk was entitled "What today's university students have taught us", and these slides from not quite a year ago were similar to what she presented at CNI.   Alison has done extensive research about how undergraduates use Wi...