Difference between revisions of "ISM's Specialized Vocabulary"
Kat Lemieux (talk | contribs) |
Kat Lemieux (talk | contribs) (commented out reference to Omeka app) |
||
Line 31: | Line 31: | ||
* dc:type | * dc:type | ||
− | === Omeka Predefined Terms === | + | <!-- === Omeka Predefined Terms === |
The Web app we plan to use to make our metadata widely available has guidelines for using the Dublin Core terms within the app. | The Web app we plan to use to make our metadata widely available has guidelines for using the Dublin Core terms within the app. | ||
:See [http://omeka.org/codex/Working_with_Dublin_Core this page] for the definitions of all the terms and their usage in Omeka. | :See [http://omeka.org/codex/Working_with_Dublin_Core this page] for the definitions of all the terms and their usage in Omeka. | ||
− | :The default Omeka terms have been deleted from our installed version, but a copy of those terms and their descriptions is available at [[Omeka Default Terms]]. | + | :The default Omeka terms have been deleted from our installed version, but a copy of those terms and their descriptions is available at [[Omeka Default Terms]]. --> |
=== Other Taxonomies=== | === Other Taxonomies=== |
Revision as of 09:24, 22 September 2018
These are the specialized terms that are required for ISM's metadata schema that cannot be found in other standard schemas.
Contents
Background
General Information about Terms (or Elements)
See this page to read about the rationale for reusing existing terms, and following sections about creating new terms.
- "If suitable terms can be found in existing vocabularies, these should be reused to describe data wherever possible, rather than reinvented. Reuse of existing terms is highly desirable as it maximises the probability that data can be consumed by applications that may be tuned to well-known vocabularies, without requiring further pre-processing of the data or modification of the application."
DCMI 15 Elements
See this page for detailed definitions and usage suggestions for Dublin Core terms.
- For the purpose of our project, the "dc:" prefix is used to make it very clear that these are DCMI terms, which is the standard procedure.
- dc:contributor
- dc:coverage
- dc:creator
- dc:date
- dc:description
- dc:format
- dc:identifier
- dc:language
- dc:publisher
- dc:relation
- dc:rights
- dc:source
- dc:subject
- dc:title
- dc:type
Other Taxonomies
These lists contain terms that may be useful for ISM's purposes, so we do not have to reinvent them.
For more information see http://taxonomywarehouse.com and http://schema.org/ImageObject
- NASA Thesaurus
- This thesaurus contains the authorized subject terms by which the documents in the NASA STI Databases are indexed and retrieved.
- Gale Aeronautics & Astronautics Thesaurus
- design, construction, and operation of aircraft and spacecraft, and the technologies and processes that apply directly to the science of flight
- Aerospace & High Technology Thesaurus
- aeronautics, astronautics, and space sciences, as well as technology development and applications in complementary and supporting fields such as chemistry, geosciences, physics, communications, and electronics
- Creative Commons Namespace
- Used for CC license information
ISM's Proposed Terms
At least until our schema is registered with some standards organization, we will use the prefix "ism:[term]" for our vocabulary terms.
We decided to use all 15 DCMI terms, the Creative Commons terms, and added some 3D VW specific ones:
- ism:grid
- This would indicate which VW grid an object is used or optimized for, e.g. Second Life or Kitely
- ism:objectType
- Inventory type, i.e., clothing, gesture, animation, prim/prim set, sound, script, texture, etc. would be found in this element using a controlled vocabulary, while the dc:type element would be used to indicate things like "virtual" or "physical", or "mesh" or "sculpt" or "prim". Perhaps any dc:type object that is not described as physical should be assumed to be virtual? It may be necessary to define the vocabularies for each of these two elements to determine exactly which is which.
- ism:objectFunction
- This element would indicate how an object is used, e.g. "landscape" or "building" or "rocket" or "space probe" rather than what kind of object it is.
- ism:vwPermissions
- For now, it would show SL or OS controlled permissions, i.e., Copy/Modify/Transfer/Export
- ism:objectFormat
- Virtual object type, e.g. mesh, prim, sculpt.
Other terms or taxonomies may be added later.