Difference between revisions of "AC Flat Examples"
m (fix obsolete links) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Audubon_Core]] | ||
This page contains examples of usage of Audubon Core in tabular form. It is not normative and at this writing contains only proposals. | This page contains examples of usage of Audubon Core in tabular form. It is not normative and at this writing contains only proposals. | ||
| Line 15: | Line 16: | ||
Example 2: | Example 2: | ||
| − | This unfolds Example 1 and shows the approach illustrated near the bottom of the section [[ | + | This unfolds Example 1 and shows the approach illustrated near the bottom of the section [[Audubon_Core#Multiplicity.2FCardinality | Multiplicty/Cardinality]] in the [[Audubon_Core| AC normative page]]. As there, this is simply an unfolding of the table of Example 1 comes only at the cost of two additional cells per variant, namely the repeated required terms. It also requires a second, single row table that is a proper subtable of the Example 1. It needs no new terminolgy, and if it did, so would all the other cases mentioned in [[Audubon_Core#Multiplicity.2FCardinality | Multiplicty/Cardinality]]. There is no requirement stated in AC that a tabular representation have only one row, but a question arises as to how best to serve AC users who require such a representation. |
<table class="wikitable"> | <table class="wikitable"> | ||
Latest revision as of 03:41, 14 November 2013
This page contains examples of usage of Audubon Core in tabular form. It is not normative and at this writing contains only proposals.
When using a simple spreadsheet or single tables for data management, it may be necessary to flatten the ac accesspoint structure, i.e. the values of the ac:variant: "Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good Quality", "Best Quality", "Offline" are used as prefixes for additional properties in a special acf (Audubon Core Flattened) namespace.
Example 1:
| dcterms:identifier | dcterms:title | acf:thumbnailAccessURI | acf:thumbnailFormat | acf:thumbnailImageWidth | acf:thumbnailImageHeight | acf:goodQualityAccessURI | acf:goodQualityFormat | acf:goodQualityImageWidth | acf:goodQualityImageHeight | acf:bestQualityAccessURI | acf:bestQualityFormat | acf:bestQualityImageWidth | acf:bestQualityImageHeight |
| http//:ex.com/pictures/thePicture.jpg | A red beech leaf | http://example.com/thumb/thePic.jpg | image/jpeg | 100 | 100 | http://ex.com/img/thePic.jpg | image/jpeg | 1000 | 1000 | http://ex.com/hr/thePic.png | image/png | 10000 | 10000 |
Example 2:
This unfolds Example 1 and shows the approach illustrated near the bottom of the section Multiplicty/Cardinality in the AC normative page. As there, this is simply an unfolding of the table of Example 1 comes only at the cost of two additional cells per variant, namely the repeated required terms. It also requires a second, single row table that is a proper subtable of the Example 1. It needs no new terminolgy, and if it did, so would all the other cases mentioned in Multiplicty/Cardinality. There is no requirement stated in AC that a tabular representation have only one row, but a question arises as to how best to serve AC users who require such a representation.
| dcterms:identifier | dcterms:title | VariantIndependentTerm1 | VariantIndependentTerm2 | ... |
| http//:ex.com/pictures/thePicture.jpg | A red beech leaf | value1 | value2 | ... |
| dcterms:identifier | dcterms:title | ac:variant | ac:AccessURI | dc:format | exif:pixelWidth | exif:pixelHeight |
| http//:ex.com/pictures/thePicture.jpg | A red beech leaf | Thumbnail | http://example.com/thumb/thePic.jpg | image/jpeg | 100 | 100 |
| http//:ex.com/pictures/thePicture.jpg | Good Quality | http://ex.com/img/thePic.jpg | image/jpeg | 1000 | 1000 | |
| http//:ex.com/pictures/thePicture.jpg | Best Quality | http://ex.com/hr/thePic.png | image/png | 1000 | 1000 |
