w3c / epub-specs

Shared workspace for EPUB 3 specifications.
Other
307 stars 60 forks source link

dc:source and print source #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The dc:source definition in Publications is for use identifying the print 
source, but does not explicitly forbid other uses.

If used for identifying any source, there becomes no reliable way of knowing 
when it actually indicates a print source or not.

If not for print pagination identification, the restriction to one instance is 
onerous to producers.

Guidance to use dcterms:source for general purpose source identification is one 
option.

Adding a new source-type property might be a way to also solve this problem:

<dc:source id="src">urn:isbn:9781234567890</dc:source>
<meta property="source-type" refines="#src">print</meta>

Original issue reported on code.google.com by mgarrish on 14 Aug 2012 at 7:00

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I prefer keeping <dc:source> (<dcterms:source> expects interoperability for 
linked data, which is not workable for most publishers) and providing a new 
source-type property as Matt has suggested. Does this imply that the content of 
that <meta property="source-type"> can be anything, or do we need to specify a 
vocabulary for that? IMO publishers would like the flexibility to identify the 
source type in any way that's meaningful to them, though I can see an argument 
for requiring the term print for accessibility reasons.

Original comment by bkasd...@apexcovantage.com on 12 Apr 2013 at 4:41

GoogleCodeExporter commented 9 years ago
The two requirements for accessibility appear to be:

1) indicate that the book has page numbers
2) indicate which source was the source of pagination

I'm less in favour of a source-type attribute to solve this, as it only 
indicates the nature of the source, not whether pagination has been included.

One approach would be to make a publication-level property like page-source 
which points to the ID of the source element, but I think this would be 
terribly broken metadata. An attribute that points to the element would work, 
however.

The other approach is to find a refinement property that expresses that the 
source is the source of the pagination:

<meta property="sourceOf">pagination</meta>

At least this doesn't require us to resort to booleans like isPageSource. At 
the same time, pagination appears like it might be the only value we ever 
declare, but that probably shouldn't influence the decision too heavily, as at 
least this approach is extensible.

It would be nice if the page-list nav could identify its source, but I don't 
think this is realistic now that it is broken out as XHTML, and it seems to 
break the package document as the source of publication metadata.

Original comment by mgarrish on 15 Apr 2013 at 8:02

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Proposal to fix this issue involves:

1) removing the restriction in the schema of only one dc:source
2) updating the DCMES source section in 3.4.6 to harmonize the description with 
Dublin Core usage, remove the 0 or 1 restriction, and provide an example of 
identifying the page source using the property in #3
3) adding a new source-of property with a single defined value 'pagination' to 
4.3.2.1 General meta properties, noting that it only extends source AND 
defining it to indicate that the presence of the pagination value means that 
this epub contains page breaks that originate from a print source with the id 
identified in the refined dc:source element

Original comment by mgarrish on 22 Apr 2013 at 9:22

GoogleCodeExporter commented 9 years ago
Specification and schema have been updated:

https://code.google.com/p/epub-revision/source/detail?r=4587

Please review and close if correct.

Original comment by mgarrish on 27 Apr 2013 at 12:39

GoogleCodeExporter commented 9 years ago

Original comment by mgarrish on 27 Apr 2013 at 12:39

GoogleCodeExporter commented 9 years ago
Update: modified use of source-of from must to should

https://code.google.com/p/epub-revision/source/detail?r=4591

Original comment by mgarrish on 29 Apr 2013 at 12:35

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Aren't there other sources -- such as legal works -- that use locator values 
(or source values) other than pagination (for example, § numbers)?  This 
something that the IDPF Index WG touched on.  I don't know if any of the work 
there is relevant, but recollection of it makes me wonder whether this part of 
the specification is generic enough.

Original comment by Robert.B...@gmail.com on 29 Apr 2013 at 8:06

GoogleCodeExporter commented 9 years ago
If there's a need to uniquely identify some other aspect of a source that has 
been translated to the digital version, there's no reason source-of couldn't be 
expanded in the future, and no reason other values couldn't be used at this 
time (they'd just potentially be non-standard). This proposal only seeks to 
codify the one term, as the solution for this issue in 3.0 conflicted with 
general metadata use in the end, and no other use cases have been put forward.

The reason that the pagination source needs to be identified specially is that 
it varies depending on whether the translation was from a hardcover or 
softcover, and, particularly with out-of-copyright works, what edition.

For a student or educator looking for a digital-equivalent work with 
pagination, for accessibility purposes, this information is important to have 
available.

Original comment by mgarrish on 29 Apr 2013 at 10:45

GoogleCodeExporter commented 9 years ago

Original comment by bkasd...@apexcovantage.com on 30 Apr 2013 at 4:31