dcterms:extent refines dc:format and dcterms:format. There is no dc:extent

[GoogleCodeExporter]

dcterms:extent has no corresponding dc: term.  Instead it refines both 
dcterms:format and dc:format.  But it has a Range that is a Class, so it should 
(must?) be a URI.

What should recommendation be for string usage.  Does this need a new string 
datatype term in the ac namespace????

Original issue reported on code.google.com by morris.bob on 22 Jun 2013 at 2:39

• Blocked on: dcterms:extent is insufficient #29
• Merged into: dcterms:extent is insufficient #29

[GoogleCodeExporter]

I naively assumed so far that dcterms:extent is of type (range) string, not 
URI. I understand that its range is 
http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#SizeOrDuration 
which seems to indicate it should be resources, but how would it work with URI? 
Has anyone seen examples? One URI in increments of microseconds? One URI for 
every possible combination of pixel numbers? I don't get this at the moment

Original comment by g.m.hage...@gmail.com on 22 Jun 2013 at 7:47

[GoogleCodeExporter]

Neither do I. Briefly I thought that a temporal fragment identifier might do, 
but that would describe a fragment of a resource, not something about the 
content.

Original comment by morris.bob on 22 Jun 2013 at 11:07

[GoogleCodeExporter]

Oh, wait.  We're talking about format here, not content. So I think this:

https://groups.google.com/forum/#!topic/bibliographic-ontology-specification-gro
up/VeAWeJWsjr0 is a little relevant 

is relevant when trying to specify the mime-type

Also, it seems like temporal or spatial frag ids should  would work. See
http://en.wikipedia.org/wiki/Fragment_identifier and 
http://www.w3.org/TR/media-frags/#valid-uri-temporal

Original comment by morris.bob on 22 Jun 2013 at 11:28

[GoogleCodeExporter]

I anticipated this and other problems you are talking over a year ago.  If you 
have not read http://code.google.com/p/tdwg-rdf/wiki/DublinCore you should do 
so or at least the sections under 1.3.4 (particularly 1.3.4.6 and 1.3.4.8) if 
you can't bring yourself to read the whole thing.  You will find that you have 
a similar (or possibly worse) problem with dcterms:temporal.  The solution 
suggested by DCMI in RDF is using a blank node and the rdf:value string, a 
practice followed by practically no one.  I don't know what you are supposed to 
do in a non-RDF solution.  When I Googled to find examples of how people used 
these terms, I found that basically nobody uses them.  This is a problem.

Original comment by steve.ba...@vanderbilt.edu on 22 Jun 2013 at 11:31

[GoogleCodeExporter]

Hmmm; dcterms:temporal refines dc:coverage and dcterms:coverage.  (Say what?? 
Isn't "refines" transitive? Sure it is.  
http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#H1 says 
"refines" means subPropertyOf.  Why make both assertions since dcterms:coverage 
refines dc:coverage? 

I almost think we should deprecate or even drop dcterms:temporal and maybe 
dcterms:coverage, at least until somebody comes up with rational URIs.  

The good news about dc:coverage is that if you take care to use typed literals, 
you can go a long way with SPARQL comparisons, including for xsd:dateTime. But 
you need care, because otherwise they are compared as strings.

Original comment by morris.bob on 23 Jun 2013 at 12:17

[GoogleCodeExporter]

"I almost think we should deprecate or even drop dcterms:temporal and maybe 
dcterms:coverage, at least until somebody comes up with rational URIs."

... and probably dcterms:extent!

So we 
1. use dc:coverage
2. introduce ac:temporal and 
3. introduce extent-like terms, e.g. 
ac:duration
ac:filesize
ac:xpixel
ac:ypixel

?

Original comment by g.m.hage...@gmail.com on 23 Jun 2013 at 1:49

[GoogleCodeExporter]

If you are going to atomize things like the pixel dimensions, then rather than 
minting AC terms, you can use mix:imageWidth, mix:imageHeight, and maybe some 
other mix: namespace terms.  If I'm remembering correctly, using mix: terms was 
under consideration by MRTG several years ago, but was rejected in favor of 
dcterms:extent for reasons that I no longer remember and am too lazy to look up.

Original comment by steve.ba...@vanderbilt.edu on 23 Jun 2013 at 8:13

[GoogleCodeExporter]

This is now overlapping with Issue 29 
http://code.google.com/p/auduboncore/issues/detail?id=29

Original comment by steve.ba...@vanderbilt.edu on 23 Jun 2013 at 9:03

[GoogleCodeExporter]

I certainly favor using the mix: terms where available.

Original comment by g.m.hage...@gmail.com on 24 Jun 2013 at 6:35

[GoogleCodeExporter]

I have added mix:imageHeight and mix:imageWidth, and mix:fileSize.  Still 
thinking about the others.

Original comment by morris.bob on 2 Jul 2013 at 3:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What remains now is to deal with temporal extension.  In Issue #29 I propose to 
defer that for a major post release Task Group on temporal terms. This should 
thus be merged with Issue #29, but I forget how to merge, so I am simply 
marking it as blocked on that issue

Original comment by morris.bob on 5 Jul 2013 at 4:05

[GoogleCodeExporter]

See also Issue #29.
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.

Original comment by morris.bob on 13 Jul 2013 at 4:06

[GoogleCodeExporter]

Merging into Issue #29 and resolving as Duplicate

Original comment by morris.bob on 19 Aug 2013 at 7:34

• Changed state: Duplicate