Merge epub for education section 8 (publication metadata) into epub3.1 about publ-cg HOT 13 OPEN

Not sure I agree with any of that section going into 3.1. The technical requirements for expressing it are already defined by the meta element. Why not make it into a guide, or add it to the guide we have:
https://idpf.github.io/epub-guides/package-metadata/

We'll bloat the specification (moreso) if we start describing all kinds of metadata you could express.

from publ-cg.

Did this guide ever get transferred to w3c? I'm wondering if it's better as an element of best practices? @dauwhe you had some thoughts here, right?

from publ-cg.

@mattgarrish I'm wondering now if we should merge that document with the structural semantics document in #4 and make this a best practices element?

from publ-cg.

All of the structural semantics in the document Dave mentions are formally defined in the SSV document. It's really nothing more than a best practice guide for educational semantics with no real standing on its own. I'd dump the document entirely and maybe just move the examples over to the SSV.

We still need some kind of best practices guide to bind all these pieces, though. That was kind of the idea behind edupub. This is stuff that epub already allows, but here's how to use it for education. The metadata is useful to understand, for example, but it's not particularly relevant to the core specification. The semantics are useful to identify, but they're not unique to edupub.

That's why I've been confused in the past about the idea that parts of edupub need to be in 3.1. Edupub was never a divergence from epub so much as a way of structuring content.

from publ-cg.

We're really only exploring whether elements from 2 sections on epub for education should be integrated. That's navigation and publication metadata. The rest of epub for education is going to move to a more extensive, integrated best practice document.

The question that you ask is at the core of what elements of that profile need to go where - basically, is there anything from this profile that is more appropriately identified as a spec element than a best practice. You're point is well made and I don't disagree but I am curious about where others stand on this before we make any decisions about where to put these two elements.

from publ-cg.

I agree with Matt that the intention with EPUB for Education was really just about how to use EPUB in educational contexts. Because of the nature of IDPF specs, we did in fact deal with some MUSTs and SHOULDs--the intention being that if a publication was asserted to be EPUB for Education compliant, then you could count on it having this specific metadata (among other metadata) and this degree of accessibility, etc. But now in the W3C I think the best practices approach is what makes the most sense.

And wrt the structural semantics from EPUB for Education, I suspect what will happen is that a certain subset of those terms will be generally useful and will make it into DPUB-ARIA, and others would wind up in that same best practices guide. Because if every domain across the publishing ecosystem tries to get the terms that matter to it into ARIA that would simply explode. So the standard needs to be the basic framework that applies across all publications, and domain- or sector-specific things should be left to profiles and best practices. The work done by the POE WG and then IPTC using it as a base on which to build RightsML for the news industry is a good example.

from publ-cg.

I would think one of the MUST for EPUB for Education would be the change from a Should to a Must to comply with the EPUB 1.0 Accessibility Conformance and Discovery Specification.
Currently in the EPUB 3.1 specification we only have a Should comply and I would think we would need to make this a Must for the Educational spec.

from publ-cg.

The only thing new edupub offers for navigation is a description of the brief toc, but the brief toc is stated to be something that typically is not included in the navigation document. It doesn't have a place in the core spec, in other words, if it's just a content semantic.

The sections on table of contents and page list aren't adding anything new. If you want to consider adding loi, loa and lov to the spec, that could be considered but there's no real imperative for these in the same way as page-list, landmarks and table of contents. That's why they've never been listed in the spec, but relegated to the "other semantics" you can define in the nav doc.

The same is true for metadata. It's schema.org metadata that we're only giving some guidance on how to use. The properties and values are maintained by external agencies, so it would be better (imo) not to get into the business of hard-coding this stuff in a specification. It was troublesome enough in edupub as we had to put the appendixes in to cover the lack of stable values. Some of the metadata isn't even technically compatible with 3.1 since we dropped the refines attribute.

One of the goals of 3.1 was to limit metadata to only what is essential for reading system presentation, too, and we've always tried to avoid industry-specific metadata. If there's a case to be made that the lrmi properties meet the RS requirement, adding would make sense.

And, certainly, you don't have to listen to just me on this, but I wanted to give my perspective on why the requirements in edupub aren't in the core. Edupub was an opportunity to delve into stronger requirements and context-specific rules that weren't seen as necessary for all publishers.

from publ-cg.

@mattgarrish I'm not sure what you mean by a content semantic? Your comments on metadata make a lot of sense to me - the relevance of some items over others is going to vary depending on the market, which goes back to the basis of the Best Practices that we were exploring.. for example, LOI is crucial for education, but irrelevant for say, mass market. I'm in favor of transferring/translating this whole section into best practices

@clapierre I agree - I would like to see a greater push for accessibility in the primary 3/1 spec but I think that is a task better suited for @avneeshsingh's task force than epub for education, since this profile will largely become best practices and in doing so will lose some of force behind "must" and "should."

from publ-cg.

All I mean is that the brief-toc has no special processing value within the navigation document; it's intended for use in content documents.

The specification only lists semantics that have a designed purpose in the nav doc section (toc, page-list and landmarks), and that are intended to be expressed in that document. We don't describe the regular stuff.

We can always include better descriptions in the SSV. It's a long story, but the reason it predominantly has only one-line descriptions is because it was all generated from a terse Notation3 document. Now that the build process is dead, we can be much more inventive in terms of descriptions and examples.

from publ-cg.

Thank you! That makes sense to me.

Sorry, I must be making you nuts... I don't know what the SSV is...

from publ-cg.

SSV = Structural Semantics Vocabulary. Is that correct?

Would this descriptive vocabulary in the not too distant future ideally be expressed via ARIA @ROLE and if not, how would it be preserved?

from publ-cg.

@RachelComerford No, you're just reminding me how inured I've become to spec jargon. :)

And, yes, it's the structure vocabulary.

@WSchindler The DPUB-ARIA module already contains a number of the semantics. Whether the remaining ones belong in ARIA has no simple answer, and is not entirely the publishing group's decision to make. Until WPUB and EPUB 4 become realities, I can't predict if the future solution is ARIA, something else, or a combination of ARIA and something else.

from publ-cg.