Google RefineThe schema documents herein are in development state. They are published for demonstration and for the ongoing schema development within the Joshua Kitlas Metadata Element Set.
The goal of this user guide is to give an overview of the function and structure of the Joshua Kitlas Metadata Element Set (JKMES) and guide users and organizations that are looking to use this schema.
The function of the JKMES is to present a schema to aid users and organizations in defining resources for manipulating data and developing information visualizations. Far beyond just websites and software, the collection of information visualization tools may include open source software packages, white papers, RSS feeds, websites, Twitter feeds, and blogs. There are no distinct areas from which to gather elements for such a collection, but rather an increasingly wide range of them.
Users of the JKMES schema can range from the casual observer to a corporation looking to catalog their assortment of data manipulation and information visualization resources.
The function of the JKMES is primarily to import the Dublin Core schema (http://dublincore.org/documents/dcmi-terms/) and define JKMES-specific terms and classes. The JKMES can be viewed as an extension of the Dublin Core schema. JKMES also calls upon the Metadata Object Description Schema (http://www.loc.gov/standards/mods/mods-outline.html) for terms, but to a much lesser degree.
The structure of the JKMES contains the following 13 elements:
subject, type, description, creator, version, publisher, placeOfPublication, resource, standardizedIdentifier, date, notes, language, rights
| Term Name | title |
| Label | Title |
| URI | http://purl.org/dc/terms/title |
| Definition | Title of resource. |
| Requirement | Mandatory |
| Comment | Value not controlled and should appear in title case. EXAMPLE: Adobe Photoshop |
| Term Name | subject |
| Label | Subject |
| URI | http://purl.org/dc/terms/description |
| Definition | The space the element occupies in the physical or virtual world. |
| Requirement | Mandatory |
| Comment | Value is controlled. Refer to LC Authority (http://authorities.loc.gov/) Value style should correspond with LOC authority record. |
| Term Name | type |
| Label | Type |
| URI | http://purl.org/dc/terms/type |
| Definition | A more specific descriptor of the type of the resource. |
| Requirement | Mandatory, Repeatable |
| Comment | When available, use another layer of description to further clarify the resource, such as, ‘Informational publication’ Value is controlled. |
| Term Name | description |
| Label | Description |
| URI | http://purl.org/dc/terms/description |
| Definition | Brief overview or summary of the resource. |
| Requirement | Mandatory |
| Comment | Value is not controlled. Can include URL pointing to resource. |
| Term Name | creator |
| Label | Creator |
| URI | http://purl.org/dc/terms/creator |
| Definition | The entity or entities associated with the creation of the resource. |
| Requirement | Mandatory, Repeatable |
| Comment | Value is controlled. EXAMPLE: |
| Term Name | version |
| Label | Version |
| URI | http://purl.org/dc/terms/hasVersion |
| Definition | The version, edition, or iteration of the resource. |
| Requirement | Optional |
| Comment | Value is not controlled. Value will vary depending on resource being cataloged. A piece of software or a computer program might appear as ‘v1.2.1’ or ‘version 1.2.1’ depending on manufacturer. Manufacturer style should be represented. Documentation may be listed as ‘123v1.pdf’ or ‘123.v.1.pdf’. Similar to the previous example, manufacturer or creator style should be adopted. |
| Term Name | publisher |
| Label | Publisher |
| URI | http://purl.org/dc/terms/publisher |
| Definition | The entity responsible for making the resource available. |
| Requirement | Optional |
| Comment | Value is controlled. EXAMPLE: |
| Term Name | placeOfPublication |
| Label | Place of publication |
| URI | http://purl.org/dc/terms/coverage |
| Definition | Location of where the resource was published. |
| Requirement | Optional |
| Comment | Value is controlled. Refer to AACR2 (10.3.3. Recording the place of publication) Value style should correspond with AACR2 record. |
| Term Name | resource |
| Label | Resource |
| URI | http://www.loc.gov/mods/v3/resource |
| Definition | The nature or genre of the resource. |
| Requirement | Mandatory |
| Comment | A descriptive categorization of the resource, such as, ‘Social media’ Value is controlled. |
| Term Name | standardizedIdentifier |
| Label | Standardized Identifier |
| URI | http://purl.org/dc/terms/identifier |
| Definition | A numeric or alphanumeric identifier |
| Requirement | Optional, Repeatable |
| Comment | Value is not controlled. Use abbreviated definition (ISBN, DOI, etc.) followed by (:) and then followed by the identifier. E.g. - |
| Term Name | date |
| Label | Date |
| URI | http://purl.org/dc/terms/date |
| Definition | A point or time associated with the resource. |
| Requirement | Optional |
| Comment | Value is controlled. Refer to ISO 8601 (http://www.iso.org/iso/date_and_time_format#how-it-works). Highest level of specificity using the below format: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) |
| Term Name | notes |
| Label | Notes |
| URI | http://www.loc.gov/mods/v3/notes |
| Definition | Comments, other than the description, used to identify the object. |
| Requirement | Optional, Repeatable |
| Comment | Value is not controlled. The control is defined by the author. Free text following good grammar and style. |
| Term Name | language |
| Label | Language |
| URI | http://purl.org/dc/terms/language |
| Definition | The language of the resource. |
| Requirement | Optional |
| Comment | Value is controlled. Refer to ISO 639-3 (http://www.sil.org/iso639%2D3/codes.asp). Example: lang=”eng” |
| Term Name | rights |
| Label | Rights |
| URI | http://purl.org/dc/terms/rights |
| Definition | Information about rights held in and over the resource. |
| Requirement | Optional |
| Comment | Value is controlled. Refer to Dublin Core (http://dublincore.org/documents/dces/). Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights. |
The schema file can be viewed by downloading it HERE.
The file path is http://kitlas.com/assets/metadata/jkmes.xsd
Google RefineThe schema file can be viewed by downloading it HERE. (Google CHROME is NOT ideal for in-browser viewing.)
The file path is http://kitlas.com/assets/metadata/records/google-refine.xml
ScraperWikiThe schema file can be viewed by downloading it HERE. (Google CHROME is NOT ideal for in-browser viewing.)
The file path is http://kitlas.com/assets/metadata/records/scraper-wiki.xml
CS229
Machine Learning
Autumn 2010The schema file can be viewed by downloading it HERE. (Google CHROME is NOT ideal for in-browser viewing.)
The file path is http://kitlas.com/assets/metadata/records/machine-learning.xml
Tableau PublicThe schema file can be viewed by downloading it HERE. (Google CHROME is NOT ideal for in-browser viewing.)
The file path is http://kitlas.com/assets/metadata/records/tableau-public.xml
I made a number of tweaks to my schema over the past months and with more time, I would probably make even more edits. It is now clear to me why schemas (as well as software and other resources) are constantly having updates – it is a lot of work and things change quickly!
The thing that frustrated me the most was the 'rights' element. As evidenced by my records, some of the segments were extremely long. Though technically correct, the thoroughness of this section came to dominate some of the records.
Two of the most unexpected and surprising insights I gained doing this project were that:
In building the schema, I found that the Dublin Core and MODs developers were a lot more deliberate and detailed than I thought after taking an original casual look. I have great respect for the systematic and exhaustive nature with which they developed the schemas. After 'getting under the hood', it was clear that the Dublin Core metadata schema could be used by a variety of developers cataloging a variety of resources. The schema is practically unlimited in its use and function.
In terms of design, I had quite an 'a-ha' moment. I like design and making things look nice. One thing that always bothered me was the plain, vanilla nature of the Dublin Core and LOC Authority sites. After putting together my schema and web page, I opted to follow the same style as Dublin Core – limited images, no fancy text or CSS, and everything presented in a rather unflattering way. The thing is, this way WORKS. Pages do not hang, text does not render incorrectly, and so on. This is why the blog of computer programmers and others at the top of the technological food chain are so plain – it is the best option for getting your message across on the web with the least amount of noise.
I am not sure how much I would change things if I were to start over from scratch. Building a schema is an iterative process that requires changes and assessments at each stage. I am sure that, even with the new knowledge I have, building a different schema would have different challenges, questions, and answers.