On doing a bit of spring cleaning around here, I’ve noticed that we haven’t been linking very clearly to the project blog for ‘Linking Lives‘, the Locah continuation project, so here it is:
http://linkinglives.archiveshub.ac.uk
Linking Lives is exploring ways to present Linked Data. It’s aiming to show that archives can benefit from being presented as a part of the diverse data sources on the Web to create full biographical pictures, enabling researchers to make connections between people and events.
Here’s the blurb from the Linking Lives ‘About Us’ page:
“The Linking Lives project (2011-12) is a follow on from the Locah project (2010-11) that created Linked Data for a sub-set of Archives Hub and Copac data. The Locah blog documents the whole process, from the data modelling through to decisions about URIs, external datasets and visualisation work.
The primary aim of Linking Lives is to explore ways to present Linked Data for the benefit of research. The Archives Hub data is rich in information about people and organisations, but many researchers want to access a whole range of data sources in order to get a full perspective for their research. We should recognise that researchers may not just be interested in archives. Indeed, they may not really have thought about using primary source material, but they may be very interested in biographical information, known and unknown connections, events during a person’s lifetime, etc. We want to show that archives can benefit from being presented not in isolation, but as a part of all of the diverse data sources that can be found to create a full biographical picture, and to enable researchers to make connections between people and events to create different narratives.
We will create a new Web interface that presents useful resources relating to individual people, and potentially organisations as well. We will explore various external data sources, assessing their viability and ease of use from both a Linked Data perspective (adding them to our Linked Data output) and a researcher’s perspective (adding them to the user interface).
We have many ideas about what we can do – the possibilities for this type of work are endless – but with limited time and resources we will have to prioritise, test out various options and see what works and what doesn’t and what each option requires to implement.
In addition to the creation of an interface, we want to think about the pressing issues for Linked Data: provenance, trust, authenticity. By creating an interface for researchers, we will be able to gain a greater appreciation of whether this type of approach is effective. We will be evaluating the work, asking researchers to feedback to us, and, of course, we will also be able to see evidence of use of the site through our Web logs.
We’ll be updating you via this blog, and we are very interested in any thoughts that you have about the work, so please do leave comments, or contact us directly.”
96LineAcceleravp-火箭vp加速器官网
Posted on by Adrian Stevenson
Jane has just posted on the Archives Hub blog about our LOCAH continuation project, ‘Linking Lives’, starting in September. I suggest you head straight over and read all about it.
96LineAcceleravp-火箭vp加速器官网
Posted on by petej
I spent the last couple of days in Manchester at the “end of programme” meeting for the JISCexpo programme under which LOCAH is funded. It was a pretty busy couple of days with representatives of all the projects talking about their projects and their experiences and some of the issues arising.
Yesterday I found myself as “scribe” for a discussion on the “co-referencing” question, i.e. how to deal with the fact that different data providers assign and use different URIs for “the same thing”. And these are my rather hasty notes of that discussion.
the creation/use of co-references is inevitable; people will always end up creating URIs for things for which URIs already exist;
one approach to this problem has been the use of the owl:sameAs property. However, using this property makes a very “strong” assertion of equivalence with consequences in terms of inferencing
the actual use of properties sometimes introduces a dimension of “social/community semantics” that may be at odds with the “semantics” provided by the creator/owner of a term
the notion of “sameness” is often qualified by a degree of confidence, a “similarity score”, rather than being a statement of certainty
the notion of “sameness”/similarity is often context-sensitive: rather than saying “X and Y are names for the same thing in all contexts”, we probably want to say something closer to “for the purposes of this application, or in this context, it’s sufficient to work on the basis that X and Y are names for the same thing”
is there a contrast between approaches based on “top-down” “authority” and those based more on context-dependent “grouping”?
how do we “correct” assertions which turn out to be “wrong”?
we decide whether to make use of such assertions made by other parties, and those decisions are based on an understanding of their source: who made them, on what basis etc.
such assessment may include a consideration of how many sources made/support an assertion
it is easy for assertions of similarity to become “detached” from such information about provenance/attribution (if it is provided at all!)
Some references:
“Identity Links” in Tom Heath and Chris Bizer, Linked Data: Evolving the Web into a Global Data Space
Glaser, H., Millard, I., Jaffri, A., Lewy, T. and Dowling, B. (2008). 如何使用伕理IP-百度经验:2021-1-5 · 如何使用伕理IP,平时大家可能会碰到访问某些资源受限的情况，只允许某地IP地址进行访问，如何将自己的IP地址伪装成别地方的IP呢，如果只是进行简单的网页访问，那么使用伕理服务器就能完成。下面给大家介绍如何使用搜狗浏览器设置伕理进行上网。
Ben O’Steen, 爬虫使用免费伕理池_zhengyiming的博客-CSDN博客:2021-8-10 · 爬虫使用免费伕理池 最近研究使用伕理ip结合进爬虫，众防止爬虫受到封ip的反爬虫措施而无法继续进行爬取，然后找了一阵，原本想着自己写个爬虫爬取免费的一些伕理ip的网页，但是后面想了想，我伔不用重复造轮子！
96LineAcceleravp-火箭vp加速器官网
Posted on by Adrian Stevenson
At the JISCEXPO Programme meeting today I led a session on ‘Explaining linked data to your Pro Vice Chancellor’, and this post is a summary of that session. The attendees were: myself (Adrian Stevenson), Rob Hawton, 免费ip伕理ip, and 手机免费ip伕理, with later contributions from Chris Gutteridge.
It seemed clear to us that this is really about focussing on institutional administrative data, as it’s probably harder to sell the idea of providing research data in linked data form to the Pro VC. Linked data probably doesn’t allow you to do things that couldn’t do by other means, but it is easier than other approaches in the long run, once you’ve got your linked data available. Linked Data can be of value without having to be open:
“Southampton’s data is used internally. You could draw a ring around the data and say ‘that’s closed’, and it would still have the same value.”
== Benefits ==
Quantifying the value of linked data efficiencies can be tricky, but providing open data allows quicker development of tools, as the data the tools hook into already exist and are standardised.
== Strategies ==
Don’t mention the term ‘linked data’ to the Pro VC, or get into discussing the technology. It’s about the outcomes and the solutions, not the technologies. Getting ‘Champions’ who have the ear of the Pro VC will help. Some enticing prototype example mash-up demonstrators that help sell the idea are also important. Also, pointing out that other universities are deploying and using linked open data to their advantage may help. Your University will want to be part of the club.
Making it easy for others to supply data that can be utilised as part of linked data efforts is important. This can be via Google spreadsheets, or e-mailing spreadsheets for example. You need to offload the difficult jobs to the people who are motivated and know what they’re doing.
It’s worth emphasising that linked data simplifies the Freedom of Infomataion (FOI) process. We can say “yes, we’ve already published that FOI data”. You have a responsibility to publish this data if asked via FOI anyway. This is an example of a Sheer curation approach.
Linked data may provide decreased bureaucracy. There’s no need to ask other parts of the University for their data, wasting their time, if it’s already published centrally. Examples here are estates, HR, library, student statistics.
== Targets ==
Some possible targets are: saving money, bringing in new business, funding, students.
The potential for increased business intelligence is a great sell, and Linked Data can provide the means to do this. Again, you need to sell a solution to a problem, not a technology. The University ‘implementation’ managers need to be involved and brought on board as well as the as the Pro VC.
It can be a problem that some institutions adopt a ‘best of breed’ policy with technology. Linked data doesn’t fit too well with this. However, it’s worth noting that Linked Data doesn’t need to change the user experience.
A lot of the arguments being made here don’t just apply to linked data. Much is about issues such as opening access to data generally. It was noted that there have been many efforts from JISC to solve the institutional data silo problem.
If we were setting a new University up from scratch, going for Linked Data from the start would be a realistic option, but it’s always hard to change currently embedded practice. Universities having Chief Technology Officers would help here, or perhaps a PVC for Technology?
96LineAcceleravp-火箭vp加速器官网
Posted on by Jane Stevenson
This is a summary of a break-out group discussion at the JISC Expo Programme meeting, July 2011, looking at ‘Skills required for Linked Data’.
We started off by thinking about the first steps when deciding to create Linked Data. We took a step back from the skills required and thought more about the understanding and the basic need and the importance of putting the case for Linked Data (or otherwise).
Why do you want Linked Data? Maybe you are producing data that others will find interesting and link into? If you give your data identifiers, others can link into it. But is Linked Data the right approach? Is what you really want open data more than Linked Data? Or just APIs into the data? Sometimes a simpler solution may give you the benefits that you are after.
Are you the authority on the data? Is someone else the authority? Do you want to link into their stuff? These are the sorts of questions you need to be thinking about.
There does appear to be a move of Linked Data a ‘clique’ into the mainstream – this should make it easier to understand and engage with. There are more tutorials, more support, more understanding. New tools will be developed that will make the process easier.
We felt that there is still a need for more support and more tutorials. We should move towards a critical mass, where questions raised are being answered and developers have more of a sense that there is help out there and they will get those answers. It can really help talking to other developers, so providing opportunities for this is important. The JISC Expo projects were tasked with providing documentation – explaining what they have done clearly to help others. We felt that these projects have helped to progress the Linked Data agenda and that it is an important encouraging people to acquire these skills to require processes and results to be written up.
Realistically, for many people, expertise needs to be brought in. Most organisations do not have resources to call upon. Often this is going to be cheaper than up-skilling – a steep learning curve can take weeks or months to negotiate whereas someone expert in this domain could do the work in just a few days. We talked about a role for (JISC) data centres in contributing to this kind of thing. However, we did acknowledge the important contribution that conferences, workshops and other events play in getting people familiar with Linked Data from a range of perspectives (as users of the data as well as providers). It can be useful to have tutorials that address your particular domain – data that you are familiar with. Maybe we need a combination of approaches – it depends where you are starting from and what you want to know. But for many people, the need to understand why Linked Data is useful and worth doing is an essential starting point.
We saw the value in having someone involved who is outward facing – otherwise there is a danger of a gap between the requirements of people using your data and what you are doing. There is a danger of going off in the wrong direction.
We concluded that for many, Linked Data is still a big hill to climb. People do still need hand-ups. We also agreed that Linked Data will get good press if there are products that people can understand – they need to see the benefits.
As maybe there is still an element of self-doubt about Linked Data, it is essential not just to output the data but to raise its profile, to advocate what you have done and why. Enthusiasm can start small but it can quickly spread out.
Finally, we agreed that people don’t always know where products are built around Linked Data. So, you may not realise how it is benefitting you. We need to explain what we have done as well as providing the attractive interface/product and we need to relate it to what people are familiar with.
96LineAcceleravp-火箭vp加速器官网
Posted on by Adrian Stevenson
Archives Hub EAD to RDF XSLT Stylesheet
免费高匿伕理ip地址 Although this is the ‘final’ formal post of the LOCAH JISC project, it will not be the last post. Our project is due to complete at the end of July, and we still have plenty to do, so there’ll more blog posts to come.
User this product is for: Archives Hub contributors, EAD aware archivists, software developers, technical librarians, JISC Discovery Programme (SALDA Project), 海外伕理ip.
We consider the Archives Hub EAD to RDF XSLT stylesheet to be a key product of the Locah project. The stylesheet encapsulates both the Locah developed Linked Data model and provides a simple standards-based means to transform archival data to Linked Data RDF/XML. The stylesheet can straightforwardly be re-used and re-purposed by anyone wishing to transform archival data in EAD form to Linked Data ready RDF/XML.
The stylesheet is available directly from http://data.archiveshub.ac.uk/xslt/ead2rdf.xsl
The stylesheet is the primary source from which we were able to develop data.archiveshub.ac.uk, our main access point to the Archives Hub Linked Data. Data.archiveshub.ac.uk provides access to both human and machine-readable views of our Linked Data, as well as access to our SPARQL endpoint for querying the Hub data and a bulk download of the entire Locah Archives Hub Linked Dataset.
The stylesheet also provided the means necessary to supply data for our first ‘Timemap’ visualisation prototype. This visualisation currently allows researchers to access the Hub data by a small range of pre-selected subjects: travel and exploration, science and politics. Having selected a subject, the researcher can then drag a time slider to view the spread of a range of archive sources through time. If a researcher then selects an archive she/he is interested in on the timeline, a pin appears on the map below showing the location of the archive, and an call out box appears providing some simple information such as the title, size and dates of the archive. We hope to include data from other Linked Data sources, such as Wikipedia in these information boxes.
This visualisation of the Archives Hub data and links to other data sets provides an intuitive view to the user that would be very difficult to provide by means other than exploiting the potential of Linked Data.
Please note these visualisations are currently still work in progress:
Science
Politics
Travel and exploration
Screenshots:
Data.archiveshub.ac.uk home page:
Screenshot of data.archiveshub.ac.uk homepage
Prototype visualisation for subject ‘science’ (work in progress):
Locah Visualisation for subject ‘science’
Working prototype/product:
http://data.archiveshub.ac.uk/ead2rdf/
There are a large number of resources available on the Web for using XSLT stylesheets, as well as our own ‘XSLT’ tagged blog posts.
Instructional documentation:
Our instructional documentation can be found in a series of posts, all tagged with ‘国外免费伕理ip地址‘. We provide instructional posts on the following main topics:
海外伕理ip
Finding, using and creating vocabularies
Designing URI patterns
Transforming data into RDF/XML and other formats (e.g. using XSLT)
Thoughts on architecture and workflows for exposing data as Linked Data.
Creating Linked Data views (e.g. using the Paget Framework)
Querying Linked Data using Sparql
Opportunities and 海外伕理ip arising from producing and using Linked Data
Project tag: locah
Full project name: Linked Open Copac Archives Hub
Short description: A JISC-funded project working to make data from Copac and the Archives Hub available as Linked Data.
免费伕理地址 The Archives Hub and Copac national services provide a wealth of rich inter- disciplinary information that we will expose as Linked Data. We will be working with partners who are leaders in their fields: OCLC, Talis and Eduserv. We will be investigating the creation of links between the Hub, Copac and other data sources including DBPedia, data.gov.uk and the BBC, as well as links with OCLC for name authorities and with the Library of Congress for subject headings.This project will put archival and bibliographic data at the heart of the Linked Data Web, making new links between diverse content sources, enabling the free and flexible exploration of data and enabling researchers to make new connections between subjects, people, organisations and places to reveal more about our history and society.
Key deliverables: Output of structured Linked Data for the Archives Hub and Copac services. A prototype visualisation for browsing archives by subject, time and location. Opportunities and barriers reporting via the project blog.
Lead Institution: UKOLN, University of Bath
Person responsible for documentation: Adrian Stevenson
Project Team: Adrian Stevenson, Project Manager (UKOLN); Jane Stevenson, Archives Hub Manager (Mimas); Pete Johnston, Technical Researcher (Eduserv); Bethan Ruddock, Project Officer (Mimas); Yogesh Patel, Software Developer (Mimas); Julian Cheal, Software Developer (UKOLN). Read more about the LOCAH Project team.
Project partners and roles: Talis are our technology partner on the project, providing us with access to store our data in the Talis Store. Leigh Dodds and Tim Hodson are our main contacts at the company. 手机免费ip伕理 also partnered, mainly to help with VIAF. Our contacts at OCLC are 国外免费伕理ip地址, Ralph LeVan and Thom Hickey. Ed Summers is also helping us out as a voluntary consultant.
The address of the LOCAH Project blog is 免费伕理ip - 齐云伕理 - 专业http伕理ip供应平台每天更新 ...:2021-6-14 · 齐云伕理是一个专业的http伕理ip供应网站，拥有大量的高品质ip资源其中包括免费伕理、私密伕理、开放伕理、长效伕理等多种类型的http和https伕理ip；并且我伔一直在探索更好的ip为用户提供旗舰级的伕理服务，努力为客户提供更好的大数据基础 ... . The main atom feed is http://archiveshub.ac.uk/locah/feed/atom
All reusable program code produced by the Locah project will be available as free software under the Apache License 2. You will be able to get the code from our project sourceforge repository.
The LOCAH dataset content is licensed under a Creative Commons CC0 1.0 licence.
The contents of this blog are available under a Creative Commons Attribution-ShareAlike 3.0 Unported license.
LOCAH Datasets
LOCAH Blog Content
Locah Code
免费伕理地址 1st Aug 2010 Project end date: 31st July 2011 免费高匿伕理ip地址 £100,000
LOCAH was funded by JISC as part of the #jiscexpo programme. See our JISC PIMS project management record.
96LineAcceleravp-火箭vp加速器官网
Posted on by petej
This is a (brief!) second post revisiting my “process” diagram from an early post. Here I’ll focus on the “transform” process on the left of the diagram:
The “transform” process is currently performed using XSLT to read an EAD XML document and output RDF/XML, and the current version of the stylesheet is now available:
Latest version (content may change): http://data.archiveshub.ac.uk/xslt/ead2rdf.xsl
(The data currently available via http://data.archiveshub.ac.uk/ was actually generated using the previous version http://data.archiveshub.ac.uk/xslt/20110502/ead2rdf.xsl. The 20110630 version includes a few tweaks and bug fixes which will be reflected when we reload the data, hopefully within the next week.)
As I’ve noted previously, we initially focused our efforts on processing the set of EAD documents held by the Archives Hub, and on the particular set of markup conventions recommended by the Hub for data contributors – what I sometimes referred to as the Archives Hub EAD “profile” – though in practice, the actual dataset we’ve worked with encompasses a good degree of variation. But it remains the case that the transform is really designed to handle the set of EAD XML documents within that particular dataset rather than EAD in general. (I admit that it also remains somewhat “untidy” – the date handling is particularly messy! And parts of it were developed in a rather 国外免费伕理ip地址 fashion as I amended things as I encountered new variations in new batches of data. I should try to spend some time cleaning it up before the end of the project.)
Over the last few months, I’ve also been working on another JISC-funded project, SALDA, with Karen Watson and Chris Keene of the University of Sussex Library, focusing on making available their catalogue data for the Mass Observation Archive as Linked Data.
I wrote a post over on the SALDA blog on how I’d gone about applying and adapting the transform we developed in LOCAH for use with the SALDA data. That work has prompted me to think a bit more about the different facets of the data and how they are reflected in aspects of the transform process:
aspects which are generic/common to all EAD documents
aspects which are common to some quite large subset of EAD documents (like the Archives Hub dataset, with its (more or less) common set of conventions)
aspects which are “generic” in some way, but require some sort of “local” parameterisation – here, I’m thinking of the sort of “name/keyword lookup” techniques I describe in the SALDA post: the technique is broadly usable but the “lookup tables” used would vary from one dataset to another
aspects which reflect very specific, “local” characteristics of the data – e.g., some of the SALDA processing is based on testing for text patterns/structures which are very particular to the Mass Observation catalogue data
What I’d like to do (but haven’t done yet) is to reorganise the transform to try to make it a little more “modular” and to separate the “general”/”generic” from the “local”/”specific”, so that it might be easier for other users to “plug in” components more suitable for their own data.
96LineAcceleravp-火箭vp加速器官网
Posted on by petej
Back near the start of the project, I published API获取-芝麻HTTP伕理:2021-5-24 · 芝麻HTTP伕理是企业级大数据爬取HTTP动态IP服务提供商,为上百家企业用户提供海量优质高匿HTTP伕理IP,全国自建160多所机房,低延迟高可用率稳定专业！ 首页 套餐购买 获取API 免费提取IP 企业服务 芝麻软件 一键换IP 芝麻VPS IP拨号服务器 游戏助手 单窗口单IP; it’s perhaps best summarised in the following diagram from that post:
In an earlier post, I discussed the URI patterns we are using for the URIs of “things” described in our data (archival resources, concepts, people, places, and so on). One of the core requirements for exposing our RDF data as Linked Data is that, given one of these URIs, a user/consumer of that URI can use the HTTP protocol to “look up” that URI and obtain a description of the thing identified by that URI. So as providers of the data, our challenge is to enable our HTTP server to respond to such requests and provide such descriptions.
The W3C Note 免费伕理地址 lists a number of possible “recipes” for achieving this while also paying attention to the principle of avoiding URI ambiguity i.e. of avoiding using a single URI to refer to more than one resource – and in particularly to maintaining a distinction between the URI of a “thing” and the URIs of documents describing that thing.
Document URI Patterns
Within the JISCExpo programme which funds LOCAH, projects generating Linked Data were encouraged to make use of the guidelines provided by the UK Cabinet Office in Designing URI Sets for the UK Public Sector.
Thse guidelines refer to the URIs used to identify “things” (somewhat tautologically, it seems to me!) as “Identifier URIs”, where they have the general pattern:
These documents are, I think, what Berners-Lee calls Generic Resources. For each such document, multiple representations may be available, each in different formats, and each of those multiple “more specific” documents in a single concrete format may be available as a separate resource in its own right. So a third set of URIs, “Representation URIs,” name documents in a specific format, using the suggested pattern:
芝麻伕理破解版下载|芝麻伕理宝动态IP真正破解版无限免费 ...:2021-8-28 · 芝麻伕理破解版是一款电脑IP伕理工具，该工具是真正破解的提供免费账号使用的版本，用户能光速切换IP，全国海量IP库任你选择，快下载使用吧！ 软件介绍 芝麻伕理宝官方版是动态IP行业领导者，高质流量出口，秒连秒换，连接切换速度≤100，全国线路任选，独享带宽。, which identifies an HTML document;
提取API-流冠伕理 - hailiangip.com:流冠伕理（www.hailiangip.com）是http动态ip服务供应商，拥有千万级独立ip池，覆盖300多城市，低延迟高可用率稳定专业！流冠伕理，爬虫伕理，高匿伕理ip，刷单伕理ip，https伕理，http伕理，ip伕理，socks伕理，伕理ip，私密伕理ip，免费伕理ip，高速伕理 ..., which identifies an RDF/XML document;
http://data.archiveshub.ac.uk/doc/person/ncarules/skinnerbeverley1938-1999artist.turtle, which identifies a Turtle document;
http://data.archiveshub.ac.uk/doc/person/ncarules/skinnerbeverley1938-1999artist.json, which identifies a JSON document (more specifically one using Talis’ RDF/JSON conventions for serializing RDF)
(We’ve deviated slightly from the recommended pattern here in that we just add “.{extension}” to the “reference” string, rather than adding “/doc.{extension}”, but we’ve retained the basic approach of distinguishing generic document and documents in specific formats, which I think is the significant aspect of the recommendations.)
This set of URI patterns corresponds to those used in the “recipe” described in section 4.2 of the W3C 伕理ip软件免费 note, “303 URIs forwarding to One Generic Document”.
The Talis Platform
It is perhaps worth emphasising here that in the LOCAH case a “description” of any one of the things in our model may contain data which originated in multiple EAD documents e.g. a description of a concept may contain links to multiple archival resources with which it is associated, or a description of a repository may contain links to multiple finding aids they have published, and so on. A description may also contain data which originated from a source other than the EAD documents: for example, we add some postcode data provided by the National Archives, and most of the links to external resources, such as people described by VIAF records, are generated by post-transformation processes.
This aggregated RDF data – the output of the EAD-to-RDF transformation process and this additional data – is stored in an instance of the Talis Platform store. Simplifying things slightly, the Platform store is a “database” specialised for the storage and retieval of RDF data. It is hosted by Talis, and made avalable as what in cloud computing terms is referred to as “Software as a Service” (SaaS). (Actually, a Platform store allows the storage of content other than RDF data too – see the discussion of the ContentBox and MetaBox features in the Talis documentation – but we are, currently at least, making use only of the MetaBox facilities).
Access to the store is provided through a Web API. Using the MetaBox API, data can be added/uploaded to the MetaBox using HTTP POST, updates can be applied through what Talis call “Changesets” (essentially “remove that set of triples” and “add this set of triples”) again using HTTP POST, and “bounded descriptions” of individual resources can be retrieved using HTTP GET. There are also “admin” functions like “give me a dump of the contents” and “clear the database”. In addition, the Platform provides a simple full-text search over literals (which returns result sets in RSS), a configurable faceted search, an “augment” function and a SPARQL endpoint.
A number of client software libraries for working with the Platform are available, developed either by Talis staff or by developers who have worked with the Platform.
I’m going to focus here on retrieving data from the MetaBox, and more specifically retrieving the “bounded descriptions” of individual resources which which provide the basis for the “Linked Data” documents.
This process involves a small Web application which responds to HTTP GET requests for these URIs:
For an “Identifier URI”, the server responds with a 303 status code and a Location header redirecting the client to the “Document URI”
For a “Document URI”, the server derives the corresponding “Identifier URI”, queries the Platform store to obtain a description of the thing identified by that URI, and responds with a 200 status code, a document in a format selected according to the preferences specified by the client (i.e. following the principles of HTTP content negotiation), and a Content-Location header providing a “Representation URI” for a document in that format.
For a “Representation URI”, the server derives the corresponding “Identifier URI”, queries the Platform store to obtain a description of the thing identified by that URI, and responds with a 200 status code and a document in the format associated with that URI.
The first step above is handled using a simple Apache rewrite rule. For the latter two steps, we’ve made use of the Paget PHP library created by Ian Davis of Talis for working with the Platform (Paget itself makes use of another library, Moriarty, also created by Ian). I’m sure there are many other ways of achieving this; I chose Paget in part because my software development abilities are fairly limited, but having had a quick look at the documentation and 免费高匿伕理ip地址, I felt there was enough there to enable me to take an example and apply my basic and rather rusty PHP skills to tweak it to make it work – at least as a short-term path to getting something functional we could “put out there”, and then polish in the future if necessary.
The main challenge was that the default Paget behaviour seemed to be to use the approach described in section 4.3 of the Cool URIs document, “303 URIs forwarding to Different Documents”, where the server performs content negotiation on the request for the “Identifier URI” and redirects directly to a “Representation URI”, i.e. a GET for an “Identifier URI” like http://data.archiveshub.ac.uk/id/person/ncarules/skinnerbeverley1938-1999artist resulted in redirects to “Representation URIs” like http://data.archiveshub.ac.uk/id/person/ncarules/skinnerbeverley1938-1999artist.html or http://data.archiveshub.ac.uk/id/person/ncarules/skinnerbeverley1938-1999artist.rdf
If possible we wanted to use the alternative “recipe” described in the previous section, and after some tweaking we managed to get something that did the job. We also made some minor changes to provide a small amount of additional “document metadata”, e.g. the publisher of and license for the document. (I do recognise that the presentation of the HTML pages is currently pretty basic, and there is room for improvement!)
I’d started to write more here about extending what we’ve done to provide other ways of accessing the data, but having written quite a lot here already, I think that is probably best saved for a future post.
96LineAcceleravp-火箭vp加速器官网
Posted on by Jane Stevenson
A post on the Archives Hub blog addresses this question in terms of the control of data, the traditional Web interface and the role of Linked Data.
Myself and Jane have just given our ‘Lifting the Lid on Linked Data‘ presentation at the ELAG European Library Automation Group Conference 2011 in Prague today. It seemed to go pretty well. There were a few comments about the licensing situation for the Copac data on the #elag2011 twitter stream, which is something we’re still working on.
