dcterms:extent is insufficient about ac HOT 41 CLOSED

Is everyone happy that there is no way to get the size of an
image safely aforehand? The defined width and height properties were removed 
from earlier version of ac and now only free-form text, which has to be parsed 
out with a lot of guessing, is available. It might contain:

10 x 10 px
10 × 10 px
10 × 10 pxl
10X10 PX
10×10Pixel
10x10 Bildpunkte
4.1 Megapixel
4,1 Megapixel
4.1 Mpxl

As well as other, time-based information for moving images. I find this in 
practice a severe shortcoming.

I agree

Comment from Andréa Matsunaga <[email protected]> during public review:

"It is suggested that the dcterms:extent term be used for multiple purposes 
(e.g., image size in pixels as well as file size). However, the term is not 
repeatable. Wouldn't it be more appropriate to have a specific term for the 
object size in bytes? Having this information readily available in the metadata 
can help estimate the needed storage before getting the actual object."

Comment from Andréa Matsunaga <[email protected]> during public review:

"In iDigBio (http://tinyurl.com/MISC-Media), some people have expressed the 
desire to have information about the magnification being used (to have a rough 
idea of the size of the object, potentially from data that is automatically 
retrieved from the capturing device) as well as the real world size depicted by 
a pixel (for the purposes of allowing one to make measurements on the image; 
this would require one to have a scale on an image and perform some 
arithmetic). Would it be possible to add such terms?"  Comment from Steve: in 
an earlier version of Audubon Core I believe that there were terms from the 
mix: namespace (http://www.loc.gov/mix/v20 ) which addressed such things as 
pixel dimensions but they were dropped in favor of the more generic 
dcterms:extent term.  The MIX vocabulary (http://www.loc.gov/standards/mix/ ) 
has terms in its SpatialMetrics terms (section 9.1) that address this issue.  
Whether they are within the scope of Audubon Core may depend on how many users 
need such terms. 

Comment from Alexey Zinovjev <[email protected]> during public review: 

dcterms:extent
  -- This is not AC term, but I personally have a feeling that using the
  same term for essentially different things like size of the file (on a
  disk) and pixel size is hardly acceptable.

Comment from "Dröge, Gabriele" <[email protected]> during public review:

Why are detailed technical facts about a multimedia item are not part of the 
standard, e.g. color space, chromaticities, width, height, resolution, lens 
aperture, exposure time, compression scheme, saturation, modified date, 
manipulated etc. ?

One more comment from Margaret Cawsey <[email protected]> which came in 
after the official close of the public review, but which is relevant to sound 
recordings:

For sound recordings we also have a duration of the recording and I do also 
have an indication of the weather conditions, which are important for calls. 
The Audubon Core should certainly have a duration field.

For reference purposes, I want to note the existence of the Media Fragments URI 
1.0 Recommendation http://www.w3.org/TR/media-frags/ which can be used to 
specify segments of time-based media (sound recordings and video).  I'm not 
sure how relevant it is to this issue, but it might be.

Answer to Gabriele Dröge, who asked: "Why are detailed technical facts about a 
multimedia item are not part of the standard, e.g. color space, chromaticities, 
width, height, resolution, lens aperture, exposure time, compression scheme, 
saturation, modified date, manipulated etc.?"

We did exclude the technical details covered by EXIF and the corresponding 
XMP-Exif (non dereferencable namespace http://ns.adobe.com/exif/1.0/, see 
http://www.exiv2.org/tags-xmp-exif.html) as being universally covered already. 
Perhaps we should make a blanked statement to this extent, that where a 
representation of the binary EXIF data is desired, the XMPExif vocabularly is 
considered appropriate.

modified date and manipulated are covered by Audubon core.

For the pixel extent I propose to add
exif:PixelXDimension    Valid image width, in pixels.
exif:PixelYDimension    Valid image height, in pixels.
xmpDM:duration The duration of the asset in the timeline in seconds
XXX:size, a file size specific field

On XXX:size: earlier notes point me to ORE:extent to refine dcterms:extent, but 
I cannot re-find this in http://www.openarchives.org/ore/1.0/vocabulary.html 
now.

Any suggestion which vocab currently in widespread use defines a term for a 
file:size in byte?

[deleted comment]

[deleted comment]

[deleted comment]

[deleted comment]

I propose to remove the now added dcterms:extent because I have added 
mix:imageHeight, imageWidth and fileSize.  There are two drawbacks to that 
addition: (a)it is silent on temporal extent and (b)mix requires a value in 
bytes and does not permit punctuation or other units.

I happen to approve of (b) because it simplifies computations, leaving not need 
for parsing, e.g. to make size comparisons.

We never got much participation of the movie community, so leaving out temporal 
extent could be left to a Task Group to do in a serious way.

See also Issue #81.
I propose to declare both issues as addressed for AC 1.0 but open a code site 
named something like actemporal and convene a task group to propose additions 
for audio and video after AC acceptance.

1. I have checked the proposed MIX terms and I vehemently oppose using them. 
They are not only not resolvable to a machine, but you also have to buy it for 
49USD to view the PDF as a human ( http://www.techstreet.com/products/1612226 
). I propose to use the proposed EXIF terms instead.

2. I agree on leaving movie details to a later stage, but presently we have 
almost as many sound files (animal sounds) than images published at the MfN. I 
would like to ask to include the proposed

xmpDM:duration The duration of the asset in the timeline in seconds

or anything equivalent. This was originally covered by extent, so we should 
support this.

PS: Here is the link: http://www.w3.org/2003/12/exif/ Therein for example:

exif:pixelXDimension
Label: PixelXDimension 
Comment: Information specific to compressed data. When a compressed file is 
recorded, the valid width of the meaningful image shall be recorded in this 
tag, whether or not there is padding data or a restart marker. This tag should 
not exist in an uncompressed file.

etc.

This also addresses some of the missing properties mentioned by G.Dröge.

No fileSize there, however. Strange that we should have to resort to a 
closedContent standard for such a trivial term.

I think the situation is more complex than you write.

MIX:

1. MIX does have an electronic form
http://www.loc.gov/standards/mix/mix20/mix20.xsd.  Arguably, it is
that document that is the MIX spec, not the Data Dictionary. However,
the Data Dictionary is an important document, and it's likely that
most people call it the standard.  

2.a. You looked at a commercial reseller. Look instead at
http://www.niso.org/apps/group_public/project/details.php?project_id=69
NISO is a not-for-profit standards organization that holds the
copyright on the Data Dictionary. But:

2.b. In 
http://www.niso.org/apps/group_public/project/details.php?project_id=69
you will find these things:

2.b.1 At the bottom, a link to PDF for the Data Dictionary. It
presently is not behind a paywall. More to the point, when you examine
that, you will find that it has carries ISBN-13 978-1-880124-67-3, the
same as NISO provides for ANSI/NISO Z39.87-2006 (R2011), which is the
document offered for sale.  My impression is that the R2011
designation signifies nothing other than an the same edition,
corresponding to the approval in 2011 by ANSI.  ANSI is also a
non-profit organization, which coordinates the U.S. participation in
ISO. It corresponds to the German DIN. Why there are two non-profits
in the U.S. is beyond me, but ANSI is the ISO coordinator. The
(presently) free Data Dictionary is at
http://www.niso.org/apps/group_public/download.php/6502/Data%20Dictionary%20-%20
Technical%20Metadata%20for%20Digital%20Still%20Images.pdf

So far, I have nothing authoritative that would confirm my impression
that the $45 PDF document and the free one are the same, aside from
the ISBN-13.  One hopes that is a GUID, but ....

2.b.2 When you look at the Data Dictionary, you will see NISO holds
the copyright and it carries permission that is essentially the same
as CC-BY-ND-NC.  Of course you and I agree that NC is not open, and
"NC" \might/ make it inappropriate for, e.g. TDWG to serve the DATA
Dictionary rather than simply cite it.  This may be moot if it is
mix20.xsd that is the spec, not the Data Dictionary. Note that
mix20.xsd cites the Data Dictionary, but only as documentation
citation.

3. My conclusion from all this is that the paywall issue is illusary, and
the main issues about deciding between MIX and EXIF are, 

A. Technical merits
B. Wideness of use in practice
C. Adoption by a recognized standards body
D. Ability to be used without media prefetch

Technical merits vary between the two depending on the term.  For
example, you don't like mix:fileSize because it is always in bytes,
but that is the same reason I prefer it to minting our own supporting
various units. (EXIF has no such thing I think).

An example of D. is exif:pixelXDimension.  You mention a Comment that
contains "This tag should not exist in an uncompressed file."  My
reading of that is that if someone holds a TIFF file they will be
unable to produce exif:pixelXDimension using an exif compliant
application. In turn, the only way to find the pixel dimensions might
then be to fetch the file.

As to B, exif is certainly in wider use, but, my guess is that is true
only for jpeg images, and only for embedded exif.

C. is unambiguous: EXIF is not adopted by any standards body as far as
I can tell.  At W3 it is just a (long since) moribund discussion
site. Also, it cites as the specification the document
http://www.exif.org/Exif2-2.PDF
That is a document with no copyright notice on it, so may in fact be
under copyright and require permission to reproduce in any
circumstance. Those issues alone shouldn't disqualify it from being
part of a TDWG standard, but it should give pause. 


I will try to write an unbiased set of pros and cons of each somewhere
on the wiki. I think the differences are too subtle and perhaps too
numerous to decide without more discussion which "cons" should be

http://www.loc.gov/standards/mix/mix20/mix20.xsd as a w3c schema cannot define 
any URIs for the term. If this is the source for the term URIs, then "we have 
made them up".

Otherwise the situation about the availabity of the PDF is rather confusing, 
but better than I originally thought. I am not a fan of the situation.

About: exif:pixelXDimension -- this is somewhat confusing as well, since exif 
has two sets of properties for compressed and uncompressed files (see 
ImageWidth/ImageLength). Since we are not using the binary embedded form of 
exif, I feel one is free to use exif:pixelXDimension in a general sense, the 
comment applies to the embedded use only. But I can see that one would like to 
differ.

What I really like about EXIF is that it is hugely widely used, well known, and 
that quite a number of other EXIF-based properties may be desirable in RDF, 
like ExposureTime, FNumber, FocalLength or ISOSpeedRatings! We decided during 
the discussions that AC will summarily recommend EXIF for this kind of 
information, but this seems to have been lost in the introduction.

See also comment #7 by Dröge, Gabriele.

[deleted comment]

I have a vague recollection that we talked about delegating technical metadata 
to EXIF, but if we ever made it into anything that was reviewed, I cannot find 
such. The earliest I can find so far is 
http://www.keytonature.eu/wiki/Submission_v095 which is the response to the 
first external review, at least as to terms. If such a proposal never made it 
into internal or public reviews, changing it now would be a very big deal and 
need negotiating with the Review Manager and then the TDWG EC.

I think such a thing could be put on the table as another Task Group, but I 
must say that I find it hard to see why most technical metadata (by which I 
mean fstop, lens details, etc.) would help with the main goals of AC, 
especially the ability to determine in advance of fetch the utility, for 
biodiversity science, of a resource.)

There's a bigger problem I see since writing comment 21: current EXIF seems to 
have similar IPR issues to MIX.  Apparently, the "spec" for exif 2.3 is 
http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-008-2010_E.pdf
whose scope section avows: "This standard specifies the formats to be used for 
images, sound, and tags in digital still cameras and in other systems handling 
image and sound files recorded by digital still cameras." The problem with this 
document is that like the NISO publication for MIX, this document has a 
copyright on it.  Worse, it has no permissions to reproduce it at all. Still 
worse vis-a-vis your original point, this document has some of its definitions 
determined by ISO standards, perhaps quite a few of them, and perhaps with 
documents that \are/ behind a paywall.  See p. 51 as an example.

The W3 discussion site and the RDF http://www.w3.org/2003/12/exif/ns seem to 
specify EXIF 2.2 and be based on the document http://www.exif.org/Exif2-2.PDF 
which seems to have approximately the same issues as 
http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-008-2010_E.pdf Although the 
Exif2.2.pdf contains no copyright notice, whereas the DC-0008-2010_E.pdf does.

I think the community would welcome wide inclusion of EXIF terms but doing it 
wholesale has quite a few issues, and I favor doing so with a post-adoption 
Task Group.  But doing so still leaves us with the original problems of some 
pixel dimensions and file sizes.  We could punt and make ac terms doing what we 
imagine EXIF should mean and worry about the mappings after the Task Group 
proposal is complete and adopted under your leadership (hah, hah, just 
serious.)  That's what I favor.

Thanks Bob for the insights, some are new to me as well.

However, I have to correct my own EXIF notes to something I knew earlier, but 
had forgotten: the better RDF terms for EXIF are in the 
http://ns.adobe.com/exif/1.0/ namespace, see the xml documentation 
http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf

I find http://www.exiv2.org/tags-xmp-exif.html a very useful overview.

With respect to EXIF: I largely agree with what you write. I do not mean to add 
them all to AC (as you imply above). What I mean is: we should add a brief 
paragraph pointing people that have a need for ExposureTime, FNumber, 
FocalLength, ISOSpeedRatings etc. to the right EXIF terms and right namespace 
(good point, since I got it wrong above, or?). So there is no big issue with AC 
ratification, it is just a best practice recommendation for additional needs. 
BUT: since we expect quite some users to have a need for RDF-EXIF (e.g. you 
need it if you want to expose jpg or tiff images in PNG...), to me it makes 
sense to also use the vocabulary for AC terms.

About filesize, see http://www.exiv2.org/tags-xmp-plus.html
plus = http://ns.useplus.org/ldf/xmp/1.0/
plus:ImageFileSizeAsDelivered
seems to be a good option that fits in the xmp framework.

Also: Can we agree to accept:
xmpDM:duration The duration of the asset in the timeline in seconds
?

[deleted comment]

Because MIX is a formal, ratified standard, I propose that we adopt the 
unambiguous MIX terms imageWidth, imageHeight, and fileSize. (I have 
implemented this but could be talked out of it with powerful reasons.) 

I have added this issue to the Issue #84 "Proposals for Task Groups" as falling 
under a Task Group on applicability of EXIF. (Comment 3)

Barring objection I will mark this as WontFix.

Issue 81 has been merged into this issue.

p.s. to Comment 28: If we wish, at a later date we could deprecate the MIX 
terms and declare equivalents to, e.g. EXIF terms.

I don't see any MIX standard that is ratified as an RDF vocabulary. Both Mix 
and XMP are ISO standard, but XMP is actually ratified to be used in as RDF, 
whereas in Mix we invent this ourself. Furthermore, it is also a hugely widely 
adopted industry standard implemented in numerous products (not just Adobe). 
See http://en.wikipedia.org/wiki/Extensible_Metadata_Platform . I don't see any 
comparable use for MIX -  I was even unable to find the corresponding Wikipedia 
entry at all.

I think that:

http://ns.adobe.com/exif/1.0/PixelXDimension
http://ns.adobe.com/exif/1.0/PixelYDimension
http://ns.useplus.org/ldf/xmp/1.0/ImageFileSizeAsDelivered

do the job, and as per the other discussion, many users will have to add more 
xmp /xmp-exif properties for technical details anyways.

I can live with the first two.

Where is an open access definition of the useplus.org term 
ImageFileSizeAsDelivered?  I could only find a hint of the term at 
http://ns.useplus.org/LDF/ldf-FieldSummary which is just a label, not RDF.

Worse is this on http://ns.useplus.org/go.ashx 

The use of any PLUS standard or application is subject to the terms of the End 
User License Agreement ("EULA"), the PLUS Anti-Trust Policy, and the PLUS 
Intellectual Property Policy ("IP Policy"). In the event of a conflict between 
the EULA and the IP Policy, the IP Policy will prevail."

Issue 72 has been merged into this issue.

I agree. Big confusion is a subterm in xmp has different license assumptions 
than the entire xmp

I suggest to take a look at the terms used in our community in the context of 
DataONE (which is ecological markup language EML metadata repository for 
ecological biodiversity data). Here:

https://github.com/hlapp/LOD4DataONE/blob/master/repository_rdf/DAACTypes.rdf

the term daacdt:filesize in the ns
xmlns:daacdt="http://rio.cs.utep.edu/ciserver/ciprojects/sdata/DAACTypes.rdf#"
is used.

We've seen many people make their own  filesize property and so far find them 
to be unsatisfactory on some grounds or another.  I couldn't find any 
documentation for daacdt:filesize, so I've asked Hilmar for some advice.  In my 
opinion, if daacdt:filesize is undocumented, or without a DataONE commitment to 
its longevity and service, we should give in and define a data property of our 
own, maybe specifying a syntax for values that signifies units.

Hilmar Lapp reports in separate email that Dryad uses dcterms:extent for 
filesize, but this has its own issues, e.g. the dual usage of dcterms:extent as 
both an object and literal-valued property.  I propose to addopt the two 
exif:PixelXDimension exif:PixelYDimension documented in the Adobe namespace as 
in Gregor's Comment 31. I will leave the Status as "Started" and in the request 
for adoption, will specify  it as an open issue. As well, I will add a Task to 
address the filesize representation.

If there is no objection by 1600Z Monday August 24, 2013 I will implement this 
solution. In any case, I will implement the exif: part today.

implemented exif:PixelXDimension  and exif:PixelYDimension 

In comment 36 I meant Monday Aug 26

Instead of leaving this open, I am resolving it as WontFix (before 1.0).  If 
nobody reopens it before 2013-08-26T:22 I will be declaring AC ready for the 
Review Manger's approval for submission to the EC.

I have added it to the proposed list of post 1.0 Tasks, Issue #84.  The 
comments here show that practice is varied, and there may presently stable, 
unambiguous, well-documented term in other vocabularies that would help. We may 
have to either mint our own, or declare an AC specific usage constraint on some 
borrowed term.

Issue 72 has been merged into this issue.