Encoding Dublin Core Metadata into XHTML

[rogue_ronin]

Sigil has started to recognize Dublin Core metadata that's encoded into (X)HTML. See brief discussion here.

There are two or three versions of the recommendations from DC on how to do it. I find that the latest one is pretty damn dry, repetitive, has errors and seems more focused on discussing terminology than on how to actually do it.

So I'm going to start a discussion here, and hope that I can get some help on how to do it properly.

The basic DC metadata is only 15 items: Contributor, Coverage, Creator, Date, Description, Format, Identifier, Language, Publisher, Relation, Rights, Source, Subject, Title, and Type.

You assign a value to each one, and you're good to go.

But of course it's slightly more complicated than that.

EBooks make some specific demands on this, and Section 2.2 of the ePub spec makes some minor changes to the DC metadata spec. ePubs:

• must have at least the Identifier, Language and Title elements, and
• the Identifier element must have an id attribute, and
• the Identifier element may have a scheme attribute, while
• Creator and Contributor elements may have a role attribute, and
• Creator and Contributor elements may have a file-as attribute, and
• the Date attribute may have an event attribute.

Which are very useful, and make a lot of sense.

But how to add it to the XHTML? Because the DC specs don't care, really, and don't deal with defining multiple elements well. You can have 4 Dates, 3 Contributors and 11 Creators -- and no way to distinguish between them. (Unless I'm misreading it -- let me know!)

Skipping over profiles and namespaces for the moment (I'm sure we'll get back to them), the basic XHTML 1.1 tag is pretty simple:

<meta name="DC.contributor" content="NAME" />
<meta name="DC.coverage" content="TOPIC" />
<meta name="DC.creator" content="NAME" />
<meta name="DC.date" content="YYYY(-MM(-DD))" />
<meta name="DC.description" content="DESCRIPTION/ACCOUNT" />
<meta name="DC.format" content="MEDIUM/FORMAT" />
<meta name="DC.identifier" content="UNIQUE-ID" />
<meta name="DC.language" content="LANGUAGE-CODE" />
<meta name="DC.publisher" content="NAME" />
<meta name="DC.relation" content="RELATED RESOURCE" />
<meta name="DC.rights" content="COPYRIGHT STATEMENT" />
<meta name="DC.source" content="DERIVED FROM" />
<meta name="DC.subject" content="KEYWORDS" />
<meta name="DC.title" content="TITLE" />
<meta name="DC.type" content="GENRE" />

The capitalized words are just surrogates for the actual entries in any given book. The name value might use DCTERMS instead of DC depending on namespaces (later for that.)

Overall, it's pretty good. But how to deal with the necessary extensions that ePub added? Let's keep in mind that XHTML eBooks ought to be thought of as an archival source (although they could be displayed on a physical reader) that is converted to whatever format is necessary. The idea is to be able to automate that conversion, such that typing in metadata is unnecessary. (And, as ePub is just wrapped XHTML, that conversion ought to be the simplest.)

The ePub metadata is an XML format -- we're trying to fit the flexibility of multiple tags into a single XHTML tag. It's doable, I think, but requires some thinking. Maybe that thinking has been done already?

There is an older DC-HTML spec, from 2003 that has the concept of "refinements". Those refinements were simply to extend the name attribute with additional dots -- those after the first were the "refinements". So you might have:

<meta name="DC.date.publication" content="YYYY(-MM(-DD))" />

that allowed you to define the publication date.

Any thoughts or help?

m a r

[DaleDe]

YOu might want to look at XMP. Here is a wiki on the topic.
http://www.w3.org/2008/WebVideo/Annotations/wiki/XMP

Dale

[KevinH]

Hi,

I contributed the first version of the dc code to Sigil (with a lot of help from Valloric!) and I agree with your assessment of the 2008 spec. It is completely useless.

It seems to assumes that the metadata in an xhtml/html document will always be embedded in a device that has live network access and as such uses links to abstract classes to implement many of their standards.

This is a huge assumption! It means that no off-line reading will ever be done and that xhtml/html files are always and only served up by webservers.

I, of course, threw-out the 2008 document as completely worthless and went with the 2003 document since in all cases ebooks may be read off line and are certainly not being served up by a webserver (as in the case of epub). The funny thing is that the DC website points out no one seems to want to implement 2008 specs and are instead using the 2003 specs and then complains about it. They really are clueless.

So I tried to implment their regular "dc" namespace and the "dcterms" namespace BUT ONLY where it overlaps with the epub standard.

I also assumed that case was not important in the "name" field but that it was relevant in the "content" and "scheme" fields. The problem is that many refinements are used and stored in the name field, so I had to work around that.

I also wanted to support free-form html metadata as generated from pml (eReader er.pdb" books (Title, Author, Publisher, Copyright, and EISBN) as well as simplistic attempts by others where it overlapped with the epub metadata spec.

To give you some idea of the range of things supported, here is one of my test cases:

<meta name="Title" content="Test Case" />
<meta name="Author" content="Kevin Hendricks" />
<meta name="Copyright" content="Copyright &copy; 2005, 2006" />
<meta name="Publisher" content="My Super PublishingHouse" />
<meta name="EISBN" content="0-06-124666-2" />
<meta name="DC.contributor" content="Another me" />
<meta name="DC.contributor.aut" content="Another me1" />
<meta name="DC.contributor.arc" content="Another me2" />
<meta name="dc.date" content="2009-12-15" />
<meta name="dc.date.modified" content="2009-12-16" />
<meta name="DCTERMS.issued" content="2008-10-22" />
<meta name="dcterms.creator.aut" content="Another me3" />
<meta name="dc.identifier" scheme="ISSN" content="123456789" />
<meta name="dcterms.identifier.doi" content="987654321" />
<meta name="dc.identifier.lccs" content="123-123-123-123" />

Please note, the last line is a valid metadata identifier under DC but it will be ignored by Sigil since it is not one of their supported internal formats for identifiers.

Also note, that like you, I ignored ALL <link> fields since the book may be read off-line.

All of the rest do something.

Another thing I have not supported yet (again because there was no place for it in the internal Sigil structure) is "refinements" on the "Relation" field such as" "IsPartOf", "IsVersionOf", "IsFormatOf", "IsReferencedBy", "IsBasis For", "IsBasedOn", and "Requires".

The **internal** structure of Sigil supports the following data items - Please note that everything from the metadata must be mapped to one of these to be supported. If not, it will be ignored since there was no place to store it internally inside Sigil (which focused specifically on the official epub standard for metadata)


Title
Author (or *any* of the Marc relator codes)
Subject
Descriptions
Publisher
Date of publication
Date of creation
Date of modification
Type
Format
Relation
Coverage
Rights
ID (must be one of DOI, ISBN, ISSN, or CustomID)

It sounds like Sigil has decided to add "published" as a dcterm to augment "issued" which makes a lot of sense but not one of the official dcterms.

Please ask me and I can tell you what is supported and I would be happy to offer a patch to Sigil to support something that is very important to you as long as it fits with the epub metadata spec - and of course it is acceptable by the author of Sigil!!!

Hope this helps,

KevinH

[rogue_ronin]

Kevin --

It's great to be able to comm with you. You've answered a bunch of questions, and of course I have more.

The 2008 document is an unreadable mess, full of jargon and ridiculous assumptions. Glad to hear about your use of the 2003 document, and your somewhat "hybridized" approach to solving the problem.

Beyond the DC, you seem to be supporting basic tags that you can assume folks might have: Publisher, Author, Editor, etc. Is that right? What tags are you supporting? I use my own set, that work specifically with my macro library and are automatically updated, but may not be universal enough -- example:

	<!-- BEGIN: EBOOK META INFORMATION -->

	<meta name="FileName" content="BookTitle.html" />
	<meta name="FileID" content="xBook_00000099" />
	<meta name="FileCreationDate" content="2009-12-09" />
	<meta name="FileVersion" content="0.10" />
	<meta name="FileRevisionDate" content="2009-12-09" />
	<meta name="FileSource" content="Found Web Text" />
	<meta name="FileScanner" content="Unknown" />
	<meta name="FileProofer" content="FoundText" />
	<meta name="FileComment" content="Created with xBook NoteTab Clip Library" />

	<meta name="Title" content="Book Title" />
	<meta name="SubTitle" content="Subtitle" />
	<meta name="Series" content="Examples" />
	<meta name="SeriesNumber" content="16" />

	<meta name="Author" content="First·Middle·LastName·" />
	<meta name="Illustrator" content="First·Middle·LastName·" />
	<meta name="Editor" content="First·Middle·LastName·" />
	<meta name="CoverDesigner" content="Name" />

	<meta name="Genre" content="Howto" />
	<meta name="ISBN" content="123456789X" />
	<meta name="Language" content="en" />
	<meta name="Description" content="An example document for discussing metadata." />
	<meta name="Keywords" content="metadata,example" />

	<meta name="Publisher" content="FoundText" />
	<meta name="PublicationDate" content="2009-12" />
	<meta name="PublicationCity" content="Honolulu" />

	<meta name="CopyrightHolder" content="none" />
	<meta name="CopyrightDate" content="none" />
	<meta name="CopyrightLicense" content="Public Domain" />

	<!-- END: EBOOK META INFORMATION -->

Which of these would you catch with Sigil?

Now, even if you catch some of it, I don't expect to be able to use it as is. I've already explored some changes:

	<!-- BEGIN: EBOOK META INFORMATION -->

	<meta name="FileName" content="BookTitle.html" />
	<meta name="DC.identifier" scheme="xBook" content="xBook_00000099" />
	<meta name="DC.date.created" content="2009-12-09" />
	<meta name="FileVersion" content="0.10" />
	<meta name="DC.date.modified" content="2009-12-09" />
	<meta name="DC.source" content="Found Web Text" />
	<meta name="FileScanner" content="Unknown" />
	<meta name="DC.contributor.pfr" content="FoundText" />
	<meta name="FileComment" content="Created with xBook NoteTab Clip Library" />

	<meta name="DC.title" content="Book Title" />
	<meta name="SubTitle" content="Subtitle" />
	<meta name="Series" content="Examples" />
	<meta name="SeriesNumber" content="16" />

	<meta name="DC.creator.aut" content="First·Middle·LastName·" />
	<meta name="DC.contributor.ill" content="First·Middle·LastName·" />
	<meta name="DC.contributor.edt" content="First·Middle·LastName·" />
	<meta name="DC.contributor.cov" content="Name" />

	<meta name="DC.type" content="Howto" />
	<meta name="DC.identifier" scheme="ISBN" content="123456789X" />
	<meta name="DC.language" content="en" />
	<meta name="DC.description" content="An example document for discussing metadata." />
	<meta name="DC.subject" content="metadata,example" />

	<meta name="DC.publisher" content="FoundText" />
	<meta name="DC.date.published" content="2009-12" />
	<meta name="PublicationCity" content="Honolulu" />

	<meta name="CopyrightHolder" content="none" />
	<meta name="DC.date.copyrighted" content="none" />
	<meta name="DC.rights" content="Public Domain" />

	<!-- END: EBOOK META INFORMATION -->

Which should mostly work with Sigil, right? The only meta-conflict I can see is DC.date.copyrighted which is not mentioned in the DC-HTML docs, but seems useful to me.

The name layout also might not be good -- I use an explicit marker for separating out first-middle-last. I do this so that I can generate names in the format LastName, First Middle or (as my macro library does file management) to create folders named LastName_First_Middle. How do you support the "file-as" attribute of the ePub spec?

I'm also of a mind that versioning info might be good. You'll note that I keep info about the file itself, and info about the document contents, somewhat distinguished. May not suit Sigil though...

What do you think about something like:

<meta name="DC.relation.series" content="Examples" />
<meta name="DC.relation.series.number" content="16" />

or

<meta name="DC.title.sub" content="Subtitle" />

?

The two DC terms that you don't say you support are: Language, and Source. Would you consider them? Or are they unnecessary?

Also, you wrote:

ID (must be one of DOI, ISBN, ISSN, or CustomID)

What is CustomID? Would my scheme="xBook" be okay?

And finally, the namespace can be either DC or DCTERMS, correct?

Hope that's not too much, thanks!

m a r

[Valloric]

Originally Posted by KevinH

Another thing I have not supported yet (again because there was no place for it in the internal Sigil structure) is "refinements" on the "Relation" field such as" "IsPartOf", "IsVersionOf", "IsFormatOf", "IsReferencedBy", "IsBasis For", "IsBasedOn", and "Requires".

All of these will not be implemented in Sigil since there's no way to export them to epub [see EDIT]. The spec doesn't support them.

And no, I don't like the idea of custom meta elements. EDIT: I still don't like this idea... but on further reflection I believe it may be wise to allow pass-through of unsupported <meta> elements and their attributes.

So if there's a meta element in an OPF or HTML that Sigil can't map to something epub-specific, it should be stored as such and then exported in the final epub's OPF without harm.

Originally Posted by KevinH

The **internal** structure of Sigil supports the following data items - Please note that everything from the metadata must be mapped to one of these to be supported. If not, it will be ignored since there was no place to store it internally inside Sigil (which focused specifically on the official epub standard for metadata)

Again, only the metadata that can be represented in an epub document is supported by Sigil. Anything else is unsupported. [see above]

Originally Posted by KevinH

It sounds like Sigil has decided to add "published" as a dcterm to augment "issued" which makes a lot of sense but not one of the official dcterms.

Yes, I know, but someone's going to type it in eventually and expect it to be recognized. And you can't blame them: "created" for creation, "modified" for modification but "issued" for publication?

Someone's going to use it, it will fail and the I'll get an issue report. May as well just preempt them.

[KevinH]

Originally Posted by rogue_ronin

Kevin --

> Beyond the DC, you seem to be supporting basic tags that you can assume folks might have: Publisher, Author, Editor, etc. Is that right?

Actually, I only support a few of the most basic, and these must map to the epub standard that Sigil uses internally.

The free-form ones I handle are:

"Title"
"Author"
"Subject"
"Description"
"Publisher"
"Date of publication"
"Date of creation"
"Date of modification"
"Type"
"Format"
"Relation"
"Coverage"
"Rights"
"Copyright"
"EISBN"
"ISSN"
"ISBN"
"CustomID"
"DOI"


The only reason these are supported and not others is that they map to the epub standard directly.

Your example has a much larger set, most of which would be ignored as things currently stands.



> Now, even if you catch some of it, I don't expect to be able to use it as is. > I've already explored some changes:

<meta name="DC.date.created" content="2009-12-09" />
<meta name="DC.date.modified" content="2009-12-09" />
<meta name="DC.contributor.pfr" content="FoundText" />
<meta name="DC.title" content="Book Title" />
<meta name="DC.creator.aut" content="First·Middle·LastName·" />
<meta name="DC.contributor.ill" content="First·Middle·LastName·" />
<meta name="DC.contributor.edt" content="First·Middle·LastName·" />
<meta name="DC.contributor.cov" content="Name" />

<meta name="DC.type" content="Howto" />
<meta name="DC.identifier" scheme="ISBN" content="123456789X" />
<meta name="DC.language" content="en" />
<meta name="DC.description" content="An example document for discussing metadata." />
<meta name="DC.subject" content="metadata,example" />

<meta name="DC.publisher" content="FoundText" />
<meta name="DC.rights" content="Public Domain" />

Are the ones in your second example that work now (actually the "published" one would work too given Valloric's change.

> How do you support the "file-as" attribute of the ePub spec?

It is simply used to replace the person's name in the epub spec if it is present. It is not supported in the html dc set since it is not part of the dc spec.

> What do you think about this

<meta name="DC.relation.series" content="Examples" />
<meta name="DC.relation.series.number" content="16" />

or

<meta name="DC.title.sub" content="Subtitle" />

?


I only handle single level refinements right now. Multiple layers of refinements are not part of the spec as far as I could determine.

> The two DC terms that you don't say you support are: Language, and Source. Would you consider them? Or are they unnecessary?

dc.language is supported, it is basic and handled in a pull down in Sigil.

> What is CustomID? Would my scheme="xBook" be okay?

I think those are actually ignored in the final run but Valloric would be the best one to ask that.

> And finally, the namespace can be either DC or DCTERMS, correct?

Yes where they overlap, but if it is something specific to the DCTERMS namespace it is better to prefix it with DCTERMS (for example - dcterms.modified for the date of modification.


m a r

You have a long list and many of the items you have would be interesting extensions. Right now, I have only focused on handling the epub spec.

The epub spec does allow for non dc to be passed through but handling that would be completely up to Valloric to decide if and how he wants it.

If he says "yes" I would be happy to take a shot at working with you to come up with a reasonable list of non-dc and extended dc terms to handle.

Take care,

KevinH

[rogue_ronin]

Originally Posted by Valloric

All of these will not be implemented in Sigil since there's no way to export them to epub [see EDIT]. The spec doesn't support them.

And no, I don't like the idea of custom meta elements. EDIT: I still don't like this idea... but on further reflection I believe it may be wise to allow pass-through of unsupported <meta> elements and their attributes.

So if there's a meta element in an OPF or HTML that Sigil can't map to something epub-specific, it should be stored as such and then exported in the final epub's OPF without harm.

I think that I've been thinking about how does an ePub file fit into a collection of such files, and how might other software use the metadata in ways that are unnecessary to the simple (!) production of an individual ebook.

Sigil doesn't need to support that metadata; it's irrelevant. But is there a way to encode that extra metadata in a way that is consistent with the DC terms? The ePub spec uses both <dc:term> and <opf:term> is there another set of terms that could be used to code these other metadata?

What Kevin wrote also seems to suggest that there are many "common" non-spec meta elements that can be mapped to the spec. It seems to me that something like using the relation tag for series is within the spec (at least as given in 2003).

I'm both thinking "out loud" here about how to encode the other metadata, and trying to nail down what code/terms exactly Sigil is currently supporting because it seems to be the first application that is taking such metadata in XHTML into account.

An explicit list of such terms would be useful to those of us who encode primarily in XHTML first and then convert. At some point, converters like Calibre may be able to find it too.

m a r

ps: Yesterday, for example, I imported 181 Doc Savage HTML files into Calibre as an experiment. It didn't even search the <title> tag to find the title. Just took the title from the file name. Now there may be a setting for that, I'll have to look again, but it seems obvious to me to look for metadata when importing HTML.

[rogue_ronin]

Originally Posted by KevinH

>The free-form ones I handle are:

"Title"
"Author"
"Subject"
"Description"
"Publisher"
"Date of publication"
"Date of creation"
"Date of modification"
"Type"
"Format"
"Relation"
"Coverage"
"Rights"
"Copyright"
"EISBN"
"ISSN"
"ISBN"
"CustomID"
"DOI"

The only reason these are supported and not others is that they map to the epub standard directly.

Sure thing. And they at least somewhat match what any lay-person might put into their metadata.

I assume that they're in the standard <meta> format.

Originally Posted by KevinH

Your example has a much larger set, most of which would be ignored as things currently stand.

Yeah, I'm not surprised. I tend to overdo it. Some of the metadata that I store is for use in a local flat-file database, and a library structure. Storing it in the document itself seems the most logical -- it lets me keep the master list much smaller and more manageable (holding only the ebook location, the UniqueID, the title and the author.) Whenever I open a book to edit, I just parse out the information from the head.

Originally Posted by KevinH

<meta name="DC.date.created" content="2009-12-09" />
<meta name="DC.date.modified" content="2009-12-09" />
<meta name="DC.contributor.pfr" content="FoundText" />
<meta name="DC.title" content="Book Title" />
<meta name="DC.creator.aut" content="First·Middle·LastName·" />
<meta name="DC.contributor.ill" content="First·Middle·LastName·" />
<meta name="DC.contributor.edt" content="First·Middle·LastName·" />
<meta name="DC.contributor.cov" content="Name" />
<meta name="DC.type" content="Howto" />
<meta name="DC.identifier" scheme="ISBN" content="123456789X" />
<meta name="DC.language" content="en" />
<meta name="DC.description" content="An example document for discussing metadata." />
<meta name="DC.subject" content="metadata,example" />
<meta name="DC.publisher" content="FoundText" />
<meta name="DC.rights" content="Public Domain" />

Are the ones in your second example that work now (actually the "published" one would work too given Valloric's change.

So,

<meta name="DC.date.published" content="2009-12" />

is okay now too. Good.

As for,

<meta name="DC.date.copyrighted" content="none" />

I get it -- it is valid by the 2003 DC-HTML spec, but doesn't map to the ePub spec.

But,

<meta name="DC.source" content="Found Web Text" />

should be okay, shouldn't it? It's both DC and ePub spec, right?

And

<meta name="DC.identifier" scheme="xBook" content="xBook_00000099" />

is a CustomID isn't it? Or are you hardcoding for the text CustomID?

Originally Posted by KevinH

> How do you support the "file-as" attribute of the ePub spec?

It is simply used to replace the person's name in the epub spec if it is present. It is not supported in the html dc set since it is not part of the dc spec.

I think it's there to pre-process complicated names, so that machines can sort properly. It doesn't fully replace the name, I think. But I see that there seems to be no obvious way to encode it in DC terms. Should you support the OPF terms of the ePub spec? Maybe something like:

<meta name="DC.creator" opf:role="aut" opf:file-as="LastName, First Middle" content="First Middle LastName" />

It'd simplify the "refinements" thing, maybe? Does it break XHTML?

Originally Posted by KevinH

I only handle single level refinements right now. Multiple layers of refinements are not part of the spec as far as I could determine.

It's mentioned somewhere, in the 2008 spec I think, that any further refinements simply become part of the first refinement -- but who knows for sure, as the liquid was sucked from my body while reading it.

As I think about this, it seems that the limitations on both the DC and ePub specs keep coming into play. It'd be nice if someone had a more thorough and more specifically ebook spec.

Originally Posted by KevinH

> What is CustomID? Would my scheme="xBook" be okay?

I think those are actually ignored in the final run but Valloric would be the best one to ask that.

I haven't yet managed to successfully build an ePub by hand (well, by macro), but I think that the Unique ID can be anything.

Originally Posted by KevinH

> And finally, the namespace can be either DC or DCTERMS, correct?

Yes where they overlap, but if it is something specific to the DCTERMS namespace it is better to prefix it with DCTERMS (for example - dcterms.modified for the date of modification.

Hmmm, what are the extra terms? (I ask you so that I can retain my liquid essence by avoiding the 2008 spec. I'm selfish like that.)

Originally Posted by KevinH

You have a long list and many of the items you have would be interesting extensions. Right now, I have only focused on handling the epub spec.

The epub spec does allow for non dc to be passed through but handling that would be completely up to Valloric to decide if and how he wants it.

If he says "yes" I would be happy to take a shot at working with you to come up with a reasonable list of non-dc and extended dc terms to handle.

Be glad to help if it ends up being a good idea. You've certainly helped me to think out my stuff.

Next post, I'll try to assemble a simple list of valid DC meta terms that can be used when hand-coding prior to importing to Sigil.

Thanks!

m a r

[rogue_ronin]

Title
<meta name="Title" content="TITLE" />
<meta name="DC.title" content="TITLE" />
<meta name="DCTERMS.title" content="TITLE" />

Author
<meta name="Author" content="NAME" />
<meta name="DC.creator.aut" content="NAME" />
<meta name="DCTERMS.creator.aut" content="NAME" />

Subject
<meta name="Subject" content="KEYWORD(S)" />
<meta name="DC.subject" content="KEYWORD(S)" />
<meta name = "DCTERMS.subject" content="KEYWORD(S)" />

Description
<meta name="Description" content="DESCRIPTION OF CONTENT" />
<meta name="DC.description" content="DESCRIPTION OF CONTENT" />
<meta name="DCTERMS.description" content="DESCRIPTION OF CONTENT" />

Publisher
<meta name="Publisher" content="PUBLISHER DATA" />
<meta name="DC.publisher" content="PUBLISHER DATA" />
<meta name="DCTERMS.publisher" content="PUBLISHER DATA" />

Publication Date
<meta name="Date of publication" content="YYYY(-MM(-DD))" />
<meta name="DC.date.published" content="YYYY(-MM(-DD))" />
<meta name="DC.date.publication" content="YYYY(-MM(-DD))" />
<meta name="DC.date.issued" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.issued" content="YYYY(-MM(-DD))" />

Creation Date
<meta name="Date of creation" content="YYYY(-MM(-DD))" />
<meta name="DC.date.created" content="YYYY(-MM(-DD))" />
<meta name="DC.date.creation" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.created" content="YYYY(-MM(-DD))" />

Modification Date
<meta name="Date of modification" content="YYYY(-MM(-DD))" />
<meta name="DC.date.modified" content="YYYY(-MM(-DD))" />
<meta name="DC.date.modification" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.modified" content="YYYY(-MM(-DD))" />

Type
<meta name="Type" content="GENRE or CLASSIFICATION" />
<meta name="DC.type" content="GENRE or CLASSIFICATION" />
<meta name="DCTERMS.type" content="GENRE or CLASSIFICATION" />

Format
<meta name="Format" content="MEDIA/FILE TYPE" />
<meta name="DC.format" content="MEDIA/FILE TYPE" />
<meta name="DCTERMS.format" content="MEDIA/FILE TYPE" />

Relation
<meta name="Relation" content="RELATED RESOURCE" />
<meta name="DC.relation" content="RELATED RESOURCE" />
<meta name="DCTERMS.relation" content="RELATED RESOURCE" />

Coverage
<meta name="Coverage" content="TIME, SPACE or OTHER SPAN" />
<meta name="DC.coverage" content="TIME, SPACE or OTHER SPAN" />
<meta name="DCTERMS.coverage" content="TIME, SPACE, or OTHER SPAN" />

Rights
<meta name="Rights" content="COPYRIGHT STATUS" />
<meta name="Copyright" content="COPYRIGHT STATUS" />
<meta name="DC.rights" content="COPYRIGHT STATUS" />
<meta name="DCTERMS.rights" contents="COPYRIGHT STATUS" />

Language
<meta name="DC.language" content="TWO-LETTER LANGUAGE CODE" />
<meta name="DCTERMS.language" content="TWO-LETTER LANGUAGE CODE" />

Source
<meta name="Source" content="SOURCE DERIVED FROM" />
<meta name="DC.source" content="SOURCE DERIVED FROM" />
<meta name="DCTERMS.source" content="SOURCE DERIVED FROM" />

EISBN
<meta name="EISBN" content="EISBN CODE" />
<meta name="DC.identifier" scheme="EISBN" content="EISBN CODE" />
<meta name="DC.identifier.EISBN" content="EISBN CODE" />
<meta name="DCTERMS.identifier.EISBN" content="EISBN CODE" />
<meta name="DCTERMS.identifier" scheme="EISBN" content="EISBN CODE" />

ISSN
<meta name="ISSN" content="ISSN CODE" />
<meta name="DC.identifier" scheme="ISSN" content="ISSN CODE" />
<meta name="DC.identifier.ISSN" content="ISSN CODE" />
<meta name="DCTERMS.identifier.ISSN" content="ISSN CODE" />
<meta name="DCTERMS.identifier" scheme="ISSN" content="ISSN CODE" />

ISBN
<meta name="ISBN" content="ISBN CODE" />
<meta name="DC.identifier" scheme="ISBN" content="ISBN CODE" />
<meta name="DC.identifier.ISBN" content="ISBN CODE" />
<meta name="DCTERMS.identifier.ISBN" content="ISBN CODE" />
<meta name="DCTERMS.identifier" scheme="ISBN" content="ISBN CODE" />

CustomID
<meta name="CustomID" content="CustomID CODE" />
<meta name="DC.identifier" scheme="CustomID" content="CustomID CODE" />
<meta name="DC.identifier.CustomID" content="CustomID />
<meta name="DCTERMS.identifier.CustomID" content="CustomID" />
<meta name="DCTERMS.identifier" scheme="CustomID" content="CustomID" />

DOI
<meta name="DOI" content="DOI CODE" />
<meta name="DC.identifier" scheme="ISBN" content="ISBN CODE" />
<meta name="DC.identifier.DOI" content="DOI CODE" />
<meta name="DCTERMS.identifier.DOI" content="DOI CODE" />
<meta name="DCTERMS.identifier" scheme="DOI" content="DOI CODE" />

==================

Any additional creator or contributor may be added using the over 200 MARC Relator Codes:

Illustrator
<meta name="DC.creator.ill" content="NAME" />

Proofreader
<meta name="DC.contributor.pfr" content="NAME" />

Editor
<meta name="DC.contributor.edt" content="NAME" />

Cover Designer
<meta name="DC.contributor.cov" content="NAME" />

==================

Please comment and correct: I will update this entry.

Thanks,

m a r

[KevinH]

Hi,

Some quick answers to your questions before I head to slepp ...

Yes, I forgot about "Source" and yes it is supported both as a free-form tag and as DC.source.

Language is only supported as a DC.language and not as free-form right now.

Under xhtml the meta tag only has the following allowed fields as far as I know: "name", "content", "scheme", and "http-equiv" along with the following attributes: "dir", "lang", and "xml:lang" so I do not think it is proper xhtml to use opf:role or any of the other field values inside a meta tag and that is why DC came up with refinements.

The full set of DCTERMs. is given by:
http://dublincore.org/documents/dcmi-terms/

So when you design you approach, we should probably try to map as many things to official dc. and dcterms. as possible since those could be passed through using the same dublin core schema and link.

"CustomID" is the exact string that must be used in the scheme of the Identifier. Using refinements in xhtml it might look like the following:

name="DC.identifier.CustomID" content="123456789101234"

inside the meta tag for example.

Hope something here helps.

Kevin

[rogue_ronin]

Cool. I've updated the post, hopefully someone will find it useful.

Note that I've used both the verb and the noun form of create, modify and publish. In the Sigil forum, Valloric indicated he would support both. If that's no longer correct, let me know.

I checked the <meta> tag at w3schools right after posting; you're correct. No way to sneak that in as an attribute.

But how about this?

<meta name="OPF.file-as" content="LastName, First Middle" />

You'd only need one, presumably, matching the primary creator. It's not perfectly to spec, though, as each creator and contributor is allowed to have that attribute.

Or could OPF become a scheme? ie:

<meta name="DC.creator.aut" content="First Middle LastName" />
<meta name="DC.creator.aut" scheme="OPF:file-as" content="LastName First Middle" />

Since file-as and name display are unlikely to get mixed up, you could have a double-entry for each creator or contributor.

At this point, we've drifted beyond Sigil. I'm getting a little loopy, too.

m a r

[Valloric]

Originally Posted by rogue_ronin

Cool. I've updated the post, hopefully someone will find it useful.

I find it very useful. Do you mind if I use this one day when I find the time to write a manual for Sigil?

Originally Posted by rogue_ronin

Note that I've used both the verb and the noun form of create, modify and publish. In the Sigil forum, Valloric indicated he would support both. If that's no longer correct, let me know.

This is already in the trunk.

Originally Posted by rogue_ronin

I checked the <meta> tag at w3schools right after posting; you're correct. No way to sneak that in as an attribute.

But how about this?

<meta name="OPF.file-as" content="LastName, First Middle" />

You'd only need one, presumably, matching the primary creator. It's not perfectly to spec, though, as each creator and contributor is allowed to have that attribute.

Yeah, this can't work. We need to have creator or contributor specified. No guessing.

Originally Posted by rogue_ronin

Or could OPF become a scheme? ie:

<meta name="DC.creator.aut" content="First Middle LastName" />
<meta name="DC.creator.aut" scheme="OPF:file-as" content="LastName First Middle" />

Since file-as and name display are unlikely to get mixed up, you could have a double-entry for each creator or contributor.

This too is a bad idea. I could make Sigil recognize that these two tags actually specify one author, but every Reading System on the planet is going to read it as two. Using just the second meta tag could work though.

In any event, as I've said, Sigil should store any meta tags it can't recognize and convert to DC. These should then be exported to the OPF as they were, that is, bare meta tags (the spec supports this).

[KevinH]

Originally Posted by rogue_ronin

Title
<meta name="Title" content="TITLE" />
<meta name="DC.title" content="TITLE" />
<meta name="DCTERMS.title" content="TITLE" />


Author
<meta name="Author" content="NAME" />
<meta name="DC.creator.aut" content="NAME" />
<meta name="DCTERMS.creator.aut" content="NAME" />

Subject
<meta name="Subject" content="KEYWORD(S)" />
<meta name="DC.subject" content="KEYWORD(S)" />
<meta name = "DCTERMS.subject" content="KEYWORD(S)" />

Description
<meta name="Description" content="DESCRIPTION OF CONTENT" />
<meta name="DC.description" content="DESCRIPTION OF CONTENT" />
<meta name="DCTERMS.description" content="DESCRIPTION OF CONTENT" />

Publisher
<meta name="Publisher" content="PUBLISHER DATA" />
<meta name="DC.publisher" content="PUBLISHER DATA" />
<meta name="DCTERMS.publisher" content="PUBLISHER DATA" />

Publication Date
<meta name="Date of publication" content="YYYY(-MM(-DD))" />
<meta name="DC.date.published" content="YYYY(-MM(-DD))" />
<meta name="DC.date.publication" content="YYYY(-MM(-DD))" />
<meta name="DC.date.issued" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.issued" content="YYYY(-MM(-DD))" />

Creation Date
<meta name="Date of creation" content="YYYY(-MM(-DD))" />
<meta name="DC.date.created" content="YYYY(-MM(-DD))" />
<meta name="DC.date.creation" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.created" content="YYYY(-MM(-DD))" />

Modification Date
<meta name="Date of modification" content="YYYY(-MM(-DD))" />
<meta name="DC.date.modified" content="YYYY(-MM(-DD))" />
<meta name="DC.date.modification" content="YYYY(-MM(-DD))" />
<meta name="DCTERMS.modified" content="YYYY(-MM(-DD))" />

Type
<meta name="Type" content="GENRE or CLASSIFICATION" />
<meta name="DC.type" content="GENRE or CLASSIFICATION" />
<meta name="DCTERMS.type" content="GENRE or CLASSIFICATION" />

Format
<meta name="Format" content="MEDIA/FILE TYPE" />
<meta name="DC.format" content="MEDIA/FILE TYPE" />
<meta name="DCTERMS.format" content="MEDIA/FILE TYPE" />

Relation
<meta name="Relation" content="RELATED RESOURCE" />
<meta name="DC.relation" content="RELATED RESOURCE" />
<meta name="DCTERMS.relation" content="RELATED RESOURCE" />

Coverage
<meta name="Coverage" content="TIME, SPACE or OTHER SPAN" />
<meta name="DC.coverage" content="TIME, SPACE or OTHER SPAN" />
<meta name="DCTERMS.coverage" content="TIME, SPACE, or OTHER SPAN" />

Rights
<meta name="Rights" content="COPYRIGHT STATUS" />
<meta name="Copyright" content="COPYRIGHT STATUS" />
<meta name="DC.rights" content="COPYRIGHT STATUS" />
<meta name="DCTERMS.rights" contents="COPYRIGHT STATUS" />

Language
<meta name="DC.language" content="TWO-LETTER LANGUAGE CODE" />
<meta name="DCTERMS.language" content="TWO-LETTER LANGUAGE CODE" />

Source
<meta name="Source" content="SOURCE DERIVED FROM" />
<meta name="DC.source" content="SOURCE DERIVED FROM" />
<meta name="DCTERMS.source" content="SOURCE DERIVED FROM" />

EISBN
<meta name="EISBN" content="EISBN CODE" />
<meta name="DC.identifier" scheme="EISBN" content="EISBN CODE" />
<meta name="DC.identifier.EISBN" content="EISBN CODE" />
<meta name="DCTERMS.identifier.EISBN" content="EISBN CODE" />
<meta name="DCTERMS.identifier" scheme="EISBN" content="EISBN CODE" />

ISSN
<meta name="ISSN" content="ISSN CODE" />
<meta name="DC.identifier" scheme="ISSN" content="ISSN CODE" />
<meta name="DC.identifier.ISSN" content="ISSN CODE" />
<meta name="DCTERMS.identifier.ISSN" content="ISSN CODE" />
<meta name="DCTERMS.identifier" scheme="ISSN" content="ISSN CODE" />

ISBN
<meta name="ISBN" content="ISBN CODE" />
<meta name="DC.identifier" scheme="ISBN" content="ISBN CODE" />
<meta name="DC.identifier.ISBN" content="ISBN CODE" />
<meta name="DCTERMS.identifier.ISBN" content="ISBN CODE" />
<meta name="DCTERMS.identifier" scheme="ISBN" content="ISBN CODE" />

CustomID
<meta name="CustomID" content="CustomID CODE" />
<meta name="DC.identifier" scheme="CustomID" content="CustomID />
<meta name="DC.identifier.CustomID" content="CustomID />
<meta name="DCTERMS.identifier.CustomID" content="CustomID" />
<meta name="DCTERMS.identifier" scheme="CustomID" content="CustomID" />

DOI
<meta name="DOI" content="DOI CODE" />
<meta name="DC.identifier" scheme="DOI" content="DOI CODE" />
<meta name="DC.identifier.DOI" content="DOI CODE" />
<meta name="DCTERMS.identifier.DOI" content="DOI CODE" />
<meta name="DCTERMS.identifier" scheme="DOI" content="DOI CODE" />

==================

Any additional creator or contributor may be added using the over 200 MARC Relator Codes:

Illustrator
<meta name="DC.creator.ill" content="NAME" />

Proofreader
<meta name="DC.contributor.pfr" content="NAME" />

Editor
<meta name="DC.contributor.edt" content="NAME" />

Cover Designer
<meta name="DC.contributor.cov" content="NAME" />

==================

Please comment and correct: I will update this entry.

Thanks,

m a r

Hi,

I edited the list above to include the DCTERMS. namespace where it overlaps with the epub spec as well as use of refinements to hold schemes for identifiers.

As it stands now, EISBN is mapped to ISBN internally so using both at the same time would probably not be a good idea.

Hope this helps,

Kevin

[rogue_ronin]

Originally Posted by Valloric

I find it very useful. Do you mind if I use this one day when I find the time to write a manual for Sigil?

Of course not, use it at will! You might want to break it into "free-form", DC and DCTERMS (see the additions that Kevin made.)

>

<meta name="OPF.file-as" content="LastName, First Middle" />

Yeah, this can't work. We need to have creator or contributor specified. No guessing.

I was thinking that it would be in addition to the DC tag -- you'd still have the definite creators/contributors. Just a way to mark the sort.

>

<meta name="DC.creator.aut" content="First Middle LastName" />
<meta name="DC.creator.aut" scheme="OPF:file-as" content="LastName First Middle" />

This too is a bad idea. I could make Sigil recognize that these two tags actually specify one author, but every Reading System on the planet is going to read it as two. Using just the second meta tag could work though.

Yeah. I get it. It's going to have to be something beyond the DC or DCTERMS spec. Which is why I suggested the OPF above.

In any event, as I've said, Sigil should store any meta tags it can't recognize and convert to DC. These should then be exported to the OPF as they were, that is, bare meta tags (the spec supports this).

Right. So coming up with a good, referenced set of tags for XHTML should give a good set of tags within any ePub created by Sigil. I can see where file-as really means nothing within the editor. It's only beyond the editor that it begins to have meaning.

I'm using what Sigil does as a jumping-off point to come up with a set of "best practices" with XHTML for myself and anyone interested.

m a r

[rogue_ronin]

Originally Posted by KevinH

Hi,

I edited the list above to include the DCTERMS. namespace where it overlaps with the epub spec as well as use of refinements to hold schemes for identifiers.

As it stands now, EISBN is mapped to ISBN internally so using both at the same time would probably not be a good idea.

Hope this helps,

Kevin

Cool, that's great. Is there anything else that's currently possible, but not listed?

From your comment, I went and looked again at the DCTERMS list.

In my original list of custom metadata terms there were the following that didn't map to the DC list:

<meta name="FileName" content="FILENAME.EXT" />
<meta name="FileVersion" content="VERSION NUMBER/NAME" />
<meta name="FileScanner" content="NAME" />
<meta name="FileComment" content="COMMENT" />
<meta name="SubTitle" content="SUBTITLE" />
<meta name="Series" content="SERIES NAME" />
<meta name="SeriesNumber" content="SERIES SEQUENCE NUMBER" />
<meta name="PublicationCity" content="CITY NAME" />
<meta name="CopyrightHolder" content="NAME" />

And this one didn't map to the ePub spec:

<meta name="DC.date.copyrighted" content="YYYY(-MM(-DD))" />

What do you think of the following?

<meta name="DCTERMS.alternative" content="SUBTITLE" />
<meta name="DCTERMS.isPartOf" content="SERIES NAME" />
<meta name="DCTERMS.rightsHolder" content="NAME" />
<meta name="DCTERMS.dateCopyrighted" content="YYYY(-MM(-DD))" />

And maybe changing

<meta name="DC.rights" content="LICENSE" />

to

<meta name="DCTERMS.license" content="LICENSE" />

?

Still leaves me out in the cold with the following though:

<meta name="FileName" content="FILENAME.EXT" />
<meta name="FileVersion" content="VERSION NUMBER/NAME" />
<meta name="FileScanner" content="NAME" />
<meta name="FileComment" content="COMMENT" />
<meta name="SeriesNumber" content="SERIES SEQUENCE NUMBER" />
<meta name="PublicationCity" content="CITY NAME" />

m a r