I'm trying to work out how to replicate the schema.org site's EducationalAudience example:

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "CreativeWork",
  "name": "Designing a treasure map",
  "learningResourceType": [
    "lesson plan",
    "learning activity"
    ],
  "audience": {
    "@type": "EducationalAudience",
    "educationalRole": "teacher"
  },
  "educationalAlignment": {
    "@type": "AlignmentObject",
    "alignmentType": "educationalLevel",
    "educationalFramework": "US Grade Levels",
    "targetName": "2",
    "targetUrl": {
      "@id": "http://purl.org/ASN/scheme/ASNEducationLevel/2"
     }
  },
  "url": "http://example.org/lessonplan"
}
</script>

I've created issues for creating the Audience and EducationalAudience objects. Do I also need to do similar issues for AlignmentObject and then the parent CreativeWork? If I create base/trait classes for each object type, should the CreativeWork get a submodule? Do you have any recommendations on how I should structure all of this? I have time this weekend and next week to work it all out, I'm just unsure on how it all fits together. Thanks.

Comments

DamienMcKenna created an issue. See original summary.

christophweber’s picture

Looking over schema.org hierarchy for those types, I am thinking you could treat it similar to Organization, and possibly split the whole endeavor into two issues:

  1. Support for Audience and subtypes
  2. Support for CreativeWork and subtypes

Splitting out submodules under CreativeWork makes a ton of sense, given fairly unrelated use cases and performance impoacts.

I am pondering how this module will absorb all the growing needs for schema support without becoming unwieldy to maintain and use. But that's for another day.

damienmckenna’s picture

Thanks ChristophWeber. And yeah, I wonder how far the module can go before it really has to be reengineered to be completely AJAX-driven.

damienmckenna’s picture

This is where Schema.org Metatag's API breaks down - there's already a SchemaCreativeWorkBase class built for the schema_book submodule, complete with a bunch of fields, but there's no way I can see if exposing that class as its own tag structure, so we end up duplicating fields, specifications and logic across multiple submodules and classes.

karens’s picture

I'm actually surprised we've been able to push this module this far already. The original use case for this module was a few article properties to support AMP pages, and look where it's gone! All the objects and properties are re-usable via traits, except at the very top level, because that's the way Metatag works. So we have the extra duplication of creating each individual property on the group, even if the whole collection was already defined in a trait. If a group could just pick up all its individual tag values from a trait, we wouldn't have to do that and a lot of duplication would be eliminated. But that would be a major change to Metatag, and I'm not suggesting that.

I totally agree that knowing where this has gone it might make sense to separate completely from Metatag and rewrite from the ground up. I don't have time to do that, but if anyone has a whole bunch of time on their hands it would be an interesting project.

damienmckenna’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev

While we won't add more data structures to v1, we're considering it as part of v2.