[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