Update to use schema.link.fish instead.

[richardhundt]

The semantics of instances on http://schema.json.org doesn't imply an enum in the target JSON schema, so I've removed it and the generated schemas look reasonably sane now.

[sebilasse]

@richardhundt @geraintluff
I could collaborate here - just found some minor issues:

I did some tests to tv4 validate the schemas and some validation was wrong,
so let's try e.g. schema Event.json with the official google example:

var data = {
  "@context": "http://schema.org",
  "@type": "Event",
  "name": "Example Band goes to San Francisco",
  "startDate" : "2013-09-14T21:30",
  "url" : "http://example.com/tourdates.html",
  "location" : {
    "@type" : "Place",
    "sameAs" : "http://www.hi-dive.com",
    "name" : "The Hi-Dive",
    "address" : "7 S. Broadway, Denver, CO 80209"
  }
}

You can reproduce it with node.js and this snippet : https://gist.github.com/sebilasse/6691e0ee170ac2c45b5e5319c645634d

From the error stack: Most errors come from Thing.json.
E.g. here (example above):
"sameAs" in Thing must be an array...

The "Expected Type" from schema.org is "URL" and in link.fish it has ranges: ['URL'] which should be the hardcoded URL schema...

The above data is an official snippet from google and it seems in
generate.js

if (propertyMultiplicity[key] === true)

...

schema.properties[key] = {
  type: 'array',
  items: subSchema
};

SHOULD also allow subSchema itself !

In general I think the property-multiplicity is not very helpful because I don't think that the schema.org documentation thinks of the|an as multiplicity.
It is more that 'an' is used when the schema is referenced while 'the' is used when it is a property which is not further referenced. Correct me if I am wrong.

From schema.org:

Expected types vs text. When browsing the schema.org types, you will notice that many properties have "expected types". This means that the value of the property can itself be an embedded item (see section 1d: embedded items). But this is not a requirement—it's fine to include just regular text or a URL. In addition, whenever an expected type is specified, it is also fine to embed an item that is a child type of the expected type. For example, if the expected type is Place, it's also OK to embed a LocalBusiness.

Any thoughts?

[sebilasse]

cc. @geraintluff
I figured out the reason !!!

@richardhundt : Are you sure you regenerated the property-multiplicity.json ?
It is important that you delete the old file before doing that (see the code) !

I get in a blank property-multiplicity.json :
"sameAs": "URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Freebase page, or official website.",

but in https://github.com/silicon-ai/schema-org-gen property-multiplicity.json itself it is
"sameAs": true

and not being a boolean is correct because the description is neither "An" nor "The" although I stand by my last comment ;)

[richardhundt]

Hey, sorry for the late response, just woke up to this thread now.

Honestly, I haven't spent much time trying to get the generated schemas right. I was playing with it, and got as far as generating some schema fragments, but haven't tried any validation.

In the end, JSON-LD + schema.org doesn't specify whether something is an array or not. It's flexible, so it's up to the application developer to figure it out. Makes this whole thing a bit tricky from a validation point of view.

[sebilasse]

whether something is an array or not. It's flexible, so it's up to the application developer to figure it out

But this means it could be an array - currently only an array is allowed ...
fyi - @richardhundt seeAlso:
"fixed" this already in #5 based on your PR so it is according to the lax schema.org logic...

Probably ideal would be another option forceMultiplicity with the old behaviour and you would use http://github.com/geraintluff/tv4-coerce then with a fix to coerce data to an Array. Then the user could choose if he needs arrays or will accept both.

and just btw: also from germany, building a decentralized OpenSource/PayAsMuchYouWant node CMS. Having a router based on JSON-Schema nearly ready!