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
Comment #2
christophweber commentedLooking 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:
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.
Comment #3
damienmckennaThanks ChristophWeber. And yeah, I wonder how far the module can go before it really has to be reengineered to be completely AJAX-driven.
Comment #4
damienmckennaThis 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.
Comment #5
karens commentedI'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.
Comment #6
damienmckennaWhile we won't add more data structures to v1, we're considering it as part of v2.