#+TITLE: OpenDocument MetaData Usecases and Requirements
#+AUTHOR:    Jambunathan K
#+EMAIL:     kjambunathan@gmail.com
#+DATE:      2010-10-26 Sat
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:t  \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
  
* Character Styles
  
** Bold
   *This is bold text*
   
** Italic
   /This is an italicized text/
   
** Underline
   
   _This is an underlined text_
   
** Code
   
   =This is a code text=
   
** Verbatim
   
   ~This is a verbatim text~
   
** Strikethrough
   
   +This is a strikethorugh text+

* Paragraph Styles

** Quotation
   
   There is a quote below.
#+BEGIN_QUOTE
  Everything should be made as simple as possible,
  but not any simpler -- Albert Einstein
#+END_QUOTE
  

** Verse
  There is a verse below.
#+BEGIN_VERSE
  Great clouds overhead
  Tiny black birds rise and fall
  Snow covers Emacs
 
      -- AlexSchroeder
#+END_VERSE
      
** Centered
   
  Here is a centered paragraph.
#+BEGIN_CENTER
  Everything should be made as simple as possible, \\
  but not any simpler
#+END_CENTER
  
** Example
  
   There is an example below
#+srcname:
#+begin_example
  First line of the example.
  Second line of the example.
#+end_example  
  
** Source Block
   
   There is a source block below.
   
#+srcname:
#+begin_src emacs-lisp
  (defun helloworld () 
    ""
    (message "hello world"))
#+end_src  

* Lists

** Simple Lists

*** Numbered List
    
    This is a numbered list.
    
    1. L1N1
    2. L1N2
    3. L1N3
       
    
       


    
*** Bulleted List
    
    This is a bulleted list.
    
    - L1B1
    - L1B2
    - L1B3
    
*** A Complex List
    
    1. L1N1
       1. L2N2
       2. L2N3
    2. L1N4
       * L2B1
       * L2B2
	 - L3B3
	   
	   First paragraph.
	   
	   Second paragraph.
	   
	 - L3B4
    3. L1N5
       1. L2N6
          1. L3N7

** A Very Complex List
   
*** Lord of the Rings
    My favorite scenes are (in this order)
    1. The attack of the Rohirrim
    2. Eowyn's fight with the witch king
       + this was already my favorite scene in the book
       + I really like Miranda Otto.
         - Definition-1 :: Description-1
         - Definition-2 :: Description-2
# * 
			   
			   
    3. Peter Jackson being shot by Legolas
	- on DVD only
       He makes a really funny face when it happens.
    But in the end, no individual scenes matter but the film as a whole.
    Important actors in this film are:
    - Elijah Wood :: He plays Frodo
    - Sean Austin :: He plays Sam, Frodo's friend.  I still remember
		     him very well from his role as Mikey Walsh in
		     The Goonies
		     
      - Embedded Definition 1 :: Embedded Description 1
      - Embedded Definition 2 :: Embedded Description 2
	      

    

* Links
** Targets
   
*** Fuzzy Target
    
*** Target with CUSTOMID
    :PROPERTIES:
    :CUSTOM_ID: aabbccddeeff
    :END:
    
*** Dedicated Target
#   <<Dedicated Target>>    
    
*** <<<Radioed Target>>>
    
** References

*** References to Fuzzy Target
    This is a link to [[Fuzzy Target]].
    
*** References to CUSTOMID links
    
    This is a link to [[#aabbccddeeff][Target with CUSTOMID]]. This is nodesc link to [[#aabbccddeeff]].
    
*** References to Dedicated Target
    There is a link to nodesc [[Dedicated Target]] here. There is a link
    to [[Dedicated%20Target][Jump to Dedicated Target]] here.
    
*** References to Radioed Links
    This section has references to Radioed Target. One more reference
    to Radioed Target.
* Images
  
#+CAPTION: figure-caption
#+LABEL: fig:figure-label
#+ATTR_LaTeX: width=12cm, height=8cm placement=[H]
  [[./001.png]]
  
* Tables
  
#+CAPTION: An Example Table
#+LABEL:   table:10

  | Labels | Column1 | Column2 | Column3 |
  |--------+---------+---------+---------|
  | /      | <       | >       | <>      |
  | Row1   | R1C1    | R1C2    | R1C3    |
  | Row2   | R2C1    | R2C2    | R2C3    |
  |--------+---------+---------+---------|

* Table Referenced
  Please refer to \ref{table:10} for further information.

* Footnote Definitions
  
[1] One
[fn:XYZ] XYZ

* Footnote Usage
  
# Also see org-footnote-autolabel, org-footnote-define-inline,
# org-footnote-section, org-footnote-auto-adjust. [C-u] C-c C-x f.
  

** Plain Footnotes
   
   Footnote [1]. One more reference to footnote [1].
   
** Named Footnotes
   
   Footnote named XYZ [fn:XYZ].

** Inlined Footnote
   Inlined footnote [fn:: inline definition]
   
** Named and Inlined Footnote
   
   Named and Inlined footnote [fn:name: named definition]
  

   
* Pending Items
  
#+ODT
  
#+BEGIN_ODT

#+END_ODT
  
#+ATTR_ODT  
  
  http://www.w3.org/2003/entities/2007/xhtml1-symbol.ent
   
* Introduction

  While existing OpenDocument metadata offers support for the
  widely-used Dublin Core vocabulary, it is limited in the following
  ways:
  
  1. It provides no rules for extension. 
  2. It only allows descriptions of the document as a whole.

  This document was prepared by the OpenDocument Metadata
  Subcommittee, and includes representative use cases and requirements
  for enhancing this metadata support.
  
** What is Metadata?

  The SVG metadata specification defines metadata as structured data
  about data. This structured data describes, explains, locates, or
  otherwise makes it easier to retrieve, use, or manage an information
  resource [NISO-META]. It is the sort of content one typically uses
  to describe documents, images, contacts, events, and so forth.
  
# - Item11
# - Item12
#   - Item121
#   - Item122

** Why is Metadata Important?  
   
   Metadata allows the document author to encode more of his/her human
   intelligence into the document. Document metadata in electronic
   documents is the natural evolution of the marginal comment or the
   footnote in paper documents. Moreover, this enhanced metadata can
   also enable powerful automated solutions. When customers and
   developers ask for support for custom content functionality, then,
   it is often in order to provide domain-specific metadata support.
  
* Use Cases 
  
  The following use cases have been consolidated from a more
  comprehensive list collected by the OpenDocument Metadata
  Subcommittee.

** Accessibility

   Enhanced metadata about document content can be particularly useful
   for accessibility purposes. This use case imagines a blind user who
   is having software read back an ODF document to them. Upon getting
   to an image, the software could optionally present descriptive
   information about the image, such as its creator, title, and so
   forth. The same would apply to any included metadata descriptions
   (see below).  
   
   
** Bibliographies and Citations 
   
   Citations can be thought of as dynamic fields whose formatting is
   generated from separate metadata, based on the requirements of a
   given citation style. A common use case is collaborative editing,
   where each author may use a different editing application and/or
   bibliographic database. ODF metadata should make it possible for
   this sort of collaborative roundtrip editing scenario to work, and
   for the citation fields to remain "live" across applications. This
   might involve also the ability for database applications to store
   their own application-specific metadata along with the more generic
   bibliographic metadata.  
   
** Content Tagging 
   
   User wants to add richerCon metadata to in-document content. In the
   simple case, they highlight text and tag it with some term. In a
   more complex case, they associate more structured metadata with
   content; for example a contact record for a participant in a
   meeting. A similar example might involve a doctor who wishes to
   record diagnostic information about a patient in a structured
   way. In this case, they might invoke a contextual menu item that
   brings up a custom inline field that allows them to choose the
   patient and the diagnosis. The displayed text is then human
   readable, but behind it lies more structured metadata that allows a
   user to access additional information about the patient, or for
   tools to later extract the information for other purposes.

** Enhanced Search 
   
   Effective document search requires richer description than simply
   plain-text content. While basic default metadata such as title or
   creator can be helpful, there is need for the possibility of
   richer, custom, metadata. A legal office may want to include case
   information about a document, information about the plaintiffs, and
   so forth, all of which can facilitate enhanced search. They may
   also want to track relations among documents; for example, that
   between a final version and its draft original.  
   
** Workflow 
   
   Workflow and collaboration solutions depend on portable metadata
   embedded in files. This may include information about who edited a
   document, its status, the rights associated with its use, its
   relationships to other documents or to a collection of documents,
   and so forth.  
   
* Design Goals and Principles 
  
  The following design goals and principles have been extracted from
  the use cases, and are used to frame the requirements.  
  
** Balance Expressiveness and Ease-of-Implementation 
   
   Enhanced metadata support should allow for complex metadata
   description where necessary, but should be designed with
   ease-of-implementation in mind for both third-party and primary
   application developers.  
   
** Enable Extensibility 
   
   Enhanced metadata should provide a strategic innovation opportunity
   for OpenDocument by allowing developers to build compelling
   solutions independent of the OpenDocument standardization process.

** Ensure Interoperability 
   
   Enhanced metadata should provide an infrastructure that assures
   round-tripping interoperability among compliant OpenDocument
   applications.  
   
* Requirements 
  
  The OpenDocument enhanced metadata proposal shall address the
  following requirements:
  
** Standard Model

   Beyond standard core support, there should be clear rules for
   custom extension metadata. These rules must be based on a clearly
   specified formal model, such that metadata extensions: 
   
   1. may be at least displayed without any particular programming
      logic
   2. may reference other resource descriptions1, including across
      partitions of user functionality (a document description or
      bibliographic citation, say, to reference a contact record)
     
   This model may involve adopting all or part of RDF for a general
   extensible description framework, and may include compatibility or
   interoperability with similar RDF-based metadata formats such as
   RSS 1.0, XHTML 2.0 metainformation or XMP.  
   
   This requirement facilitates the following goals: Enable
   Extensibility and Ensure Interoperability.
   
** Default Vocabularies 
   
   OpenDocument should provide a rich set of default properties and
   classes for describing resources that go beyond the current
   support. The proposal should seek to reuse or define mappings to
   existing vocabularies, which may include deepening support for
   Dublin Core and/or adding support for vCard and/or Creative Commons
   to describe specific content of general applicability to office
   documents.  
   
   This requirement facilitates the following goals: Balance
   Expressiveness and Ease-of-Implementation and Ensure
   Interoperability.
   
** Mechanism to Associate Content with Metadata 
   
   Proposal should define valid document objects that can be described
   using enhanced metadata (for example, words, sentences, paragraphs,
   tables, pictures, etc.), as well as a mechanism to associate those
   objects with their descriptions.  
   
   This requirement facilitates the following goals: Enable
   Extensibility and Ensure Interoperability.

** Consistent Identification Scheme 
   
   IRIs provide a well-developed infrastructure for globally unique
   identification which also facilitates integration with
   network-based solutions, and so should be used to identify
   resources. These identifiers can then be used to link document
   content with descriptions, or resource descriptions with other
   resource descriptions.
   
   This requirement facilitates the following goals: Enable
   Extensibility and Ensure Interoperability.
   
** Separate Processing 
   
   Metadata must be able to be processed, extracted, removed and so
   forth independently of the document content.  
   
   This requirement facilitates the following goals: Balance
   Expressiveness and Ease-of-Implementation, Enable Extensibility and
   Ensure Interoperability.
   
** Levels of Conformance 
   
   The enhanced metadata proposal should define levels of conformance
   so that users and developers have expectations about the level of
   support to expect in a given application. At minimum, all
   OpenDocument applications must preserve foreign content, but other
   levels of conformance might relate to display and/or editing of
   such foreign content.  
   
   This requirement facilitates the following goals: Ensure
   Interoperability.
   
** Ability to Add Multiple Annotations to the Same Content 
   
   This requirement falls out of the need to support collaborative
   editing, where the same document can be edited by multiple users,
   either synchronously or asynchronously. Since these users may also
   be applying metadata, the same words, paragraphs, etc., may see the
   same class of metadata applied multiple times. A practical
   consideration is that XML does not allow the same attribute name to
   be applied multiple times to the same element. So a metadata scheme
   which relied exclusively on metadata via attributes would have
   difficulty meeting this requirement.  
   
   This requirement facilitates the following goals: Enable
   Extensibility.

* Bibliography

  [NISO-META] NISO (2004) Understanding Metadata, NISO Press:Bethesda, MD, http://www.niso.org/standards/resources/UnderstandingMetadata.pdf