It is important to make sure that a repository is accessible to machines as well as humans as this allows it to be indexed more efficiently and thus more discoverable on the web. \u00a0RedFeather currently supports 3 alternative data formats: JSON, RSS and RDF. \u00a0Additional representations, including schema.org markup, were considered during development but taken out of scope for this initial version of RedFeather. \u00a0They do, however, make ideal candidates for further work.<\/p>\n
Out of the formats mentioned, JSON is both the simplest and most versatile since it is easily understood by both humans and machines. \u00a0Unfortunately, JSON support was only introduced in PHP v5 so it cannot be including in the core and so is only available as a plugin.<\/p>\n
RSS is intended more for digesting the repository as a whole, and as a result is only accessible as a feed from the index page. \u00a0Since there tends to be a lot of variance in terms of what different stream readers expect from RSS we decided to stick with a minimal entry format to try and maximise compatibility. \u00a0However, the only truly critical important API is Nottingham Xpert, since that is one of the only feasible ways to make a small source of OER, such as an independent RedFeather installation, visible to the wider community.<\/p>\n
Due to the inherent complexity of the format, the creation of an RDF export for RedFeather presented a few interesting challenges, most of which involved the ‘creators’ field. \u00a0The first problem was that of URIs. \u00a0Since RedFeather is implemented as a single php file, it’s not exactly overflowing with accessible URLs that can be used to resolve a URI. \u00a0This is compounded by the fact that RedFeather doesn’t really have any concept of “people” as an entity – there are no profile pages for individuals and the user account system is ONLY used for authentication. \u00a0In effect, a creator is just a single name field with an optional email address associated with it. \u00a0Further problems occur if a certain name appears on multiple items in the repository – how do you tell if they are the same person or multiple entities? \u00a0What if they are the same person but have changed their name or email? \u00a0What happens if you delete all the resources by a certain author and re-add them? \u00a0Will they still have the same URI?<\/p>\n
Trying to solve all these issues and implement a complicated system which can deal with all the fringe cases above is\u00a0ludicrous\u00a0when you consider the elegant simplicity of the rest of RedFeather. \u00a0A better solution would be to just assume that two creators with the same name and email are the same person. \u00a0This will work in the vast majority of cases except in unusual instances where no email is known and their name is something incredibly common, like Bob. \u00a0We can therefore pretty much just\u00a0concatenate\u00a0the name and email together to form the URI – however, the URI still needs to resolve to a page that makes\u00a0contextual sense for a person. \u00a0To solve this we just included a special page which contains a list of all the creators who have contributed to the repository. \u00a0The names on this list are then linked to using an anchor tag to give a final URI that looks something like www.example.com\/index.php?page=creators#matt<\/p>\n
<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
It is important to make sure that a repository is accessible to machines as well as humans as this allows it to be indexed more efficiently and thus more discoverable on the web. \u00a0RedFeather currently supports 3 alternative data formats: …<\/p>\n