This “like” business that facebook is producing is a bit overrated. Now they are letting people like the liking… How far will they let this recursion propagate?
So, the common concern is:
If I put my email address "out there" on the web that spammers will get it and start sending me spam messages.
Well, that is a valid concern. There are scripts and crawlers which go around and look for email addresses. (And lets suppose that they also do not check for a robots.txt file.) These generally work by focusing on the syntax of the email addresses using Regular Expressions or finding the
mailto: term in the HTML code. There are some things which can be done to prevent this from happening.
- The best way is to use contact forms.
- The third best way is to use HTML characters for your email addresses.
- One way that I severely dislike is to spell out the email address or phone number like (you see a lot of this on sites like craigslist and after a few spam text messages one understands why it is done):
I was exploring the internet and I found a really cool plug-in in for WordPress. This plugin lets one define specific sets of plug-ins they want to repeatedly download for deploying websites. This is awesome! WordPress Install Profiles. Work smarter.
It took me a while but I eventually found out how to add some custom images to the WP 2011 theme.
Here are the links which helped me:
I have been reviewing applications for library, research and citation metadata. Things like RDF, METS, Dublin Core, .ris and BibTeX. In some ways these things are related – they are metadata. But in other ways they are different animals.
In my search I have found two very different classes of metadata schemes based on two different kinds of end users.
- End users who are machines (Metadata for interoperability or resource discovery).
- End users who are human.
End Users who are machines are usually concerned with the interoperability of metadata for search, storage, and advertisement. These kinds of systems usually are engineered to use metadata schemes like Dublin Core, MODS and METS. Often these systems are able to communicate high level metadata in generic categories.
However, End Users who are human are usually concerned with purposing the metadata in creative processes. And in general, desire to use and appropriate more specific elements of metadata. This is especially true with citation metadata. Students and researchers want to be able to build bibliographies with the data. Additionally, Many of the more detaied metadata elements, that is, overly detailed from a Dublin Core perspective (i.e.
Of those users looking to use metadata to construct bibliographies and citations, they are often looking for that metadata in the interchange formats of either BibTeX, Endnote XML or .ris. Of those users interested in finding things based on technical metadata, such as audio technicians, linguists, ethnographers, and ethnomusicologists, they are looking to use the metadata and the object it describes in a workflow. And in order to purpose that media object as they need to, those users need to make sure that the digital object fits their workflow criteria.
This discrepancy between Metadata for System to System transmission and Metadata for End Users creates a bit of a complext situation, in that delivery systems need to consider both sets of users.
Which information to record?
Structured metadata is divided into four main categories that contain information which is defined by the schemas or extension schemas being used:
- Structural metadata. This is information about the structural relationship with other parent or family files and how the metadata relates to the file.
- Descriptive metadata. This is information about the content of the digital file. The information recorded here is more curatorial than technical, and is the primary portal for users to access your resource. Data including File name, creator, associated dates, description, summary, locations etc should be standardised using a interoperable schema such as Simple DC or MODS.
- Administrative metadata. This contains information about the analogue source material, the rights of the content and any preservation information. Information here provides support to the managerial team of the collection and researchers in organising and providing access to the resource. Information about rights, ownership and usage restrictions is also kept within the administrative metadata.
- Technical metadata. To make good use of the digital object data is required which describes the technical qualities of the physical and/or digital object. This includes information such as channel number, bit-depth, sampling rate, and the unique file identifier. AudioMD, is an XML based schema that has been designed primarily for this purpose. It is soon to be superseded by AES-X098, developed by the Audio Engineering Society, upon its formal release.
Though it is possible to separate out some finer grained metadata categories. Consider the differences from above and those below which were part of my post about Metadata for Socio-linguistic Corpora:
- Descriptive meta-data: supports discovery, attribution and identification of resources created.
- Administrative meta-data: supports management, preservation, and appropriate usage of resources created.
- Technical: About the machinery used to create the resource and the technical aspects of the resource.
- Use (meaning how one may use the objects) and Rights: Copyright, license and moral ownership of the items.
- Structural meta-data: maintains relationships between the parts of complex, multi-part resources (Spanne 2008).
- Situational: this is metadata which describes the events around the creation of the work. Asking questions about the social setting, or the precursory events. It follows ideas put forward by Bergqvist (2007).
- Use metadata: metadata collected from or about the users themselves (e.g. user annotations, number of people accessing a particular resource)
In that post I also said:
I think it is only fair to point out to archivist and to librarians that linguists and language documenters do not see a difference between descriptive and non-descriptive metadata in their workflows. That is sometimes we want to search all the corpora by licenses or by a technical attribute. This elevates the these attributes to the function of discovery metadata. It does not remove the function of descriptive metadata from its role in finding things but it does functionally mean that the other metadata is also viable as discovery metadata.
Compare and match three
My goal here is to compare Doublin Core [http://www.feedforall.com/dublin-core.htm] with BibTeXThere is a nice cross-walk technology for bibTex resources in source-forge: http://bibtexml.sourceforge.net/details.html and with .ris.
“RIS” Format Documentation Adding a “Direct Export” Button to Your Web Page or Web Application
List of Mappings not .ris or Bibtex to DC but many other cross walks.
Over the last few weeks I have been contemplating how multi-lingual content could work on sil.org. (I have had several helpful conversations to direct my thinking.)
As I understand the situation there is basically three ways which multi-lingual content could work.
First let me say that there is a difference between, multi-lingual content, multi-lingual taxonomies, and multi-lingual menu structures. We are talking about content here, not menu and navigation structures or taxonimies. Facebook has probably presented the best framework to date for utilizing on the power crowds to translate navigation structures. In just under two years they added over 70 languages to Facebook. However, Facebook has had some bumps along the way as DropBox points out in their post talking about their experience in translating their products and services.
- Use a mechanism which shows all the available languages for content and highlights which ones are available to the user. Zotero has an implementation of this on their support forums.
- Basically create a subsite for each language and then only show which pages have content in that language. Wikipedia does this. Wikipedia has a menu on the left side with links to articles with this same title in other languages. Only languages which have an article started in them on that title are shown in the menu.
- Finally, create a cascading structure for each page or content area. So there is a primary language and a secondary language or a tertiary, or a quaternary language etc. based on the browser language of choice with country IP playing a secondary role. If there is no page for the primary language then the next in preference will show. This last option has been preferred by some because if an organization wants to present content to a user, then obviously, it would be in the users’ primary language. But if the content is not available in the primary language then the organization would want to still let the user know that the content exists in another language.
It would also be good to understand the concepts used in Drupal 7 (and Drupal 8) for multi-lingual content. There are several resources which I have found helpful:
- Localized and Multi-Lingual Content in Drupal 7
- Drupal 7’s new multilingual systems (part 4) – Node translation
- Drupal 7’s new multilingual systems compilation
- Drupal 8 Multilingual Initiative
It would appear that from this list of resources that Drupal’s default behavior is more in line with part two of the three examples given above.
I wonder if I could use this Plugin, HTML import 2.0 to grab my old shtml website and bring it into WordPress.