Representation of boolean values

[simleo]

trafficstars

Schema.org has this example for https://schema.org/isAccessibleForFree:

{
        "@context": "https://schema.org",
        "@type": "TouristAttraction",
        "name": "Hyde Park",
        "description": "It's one of nine royal parks of London.",
        "url": "http://www.royalparks.org.uk/parks/hyde-park",
        "isAccessibleForFree": true
}

I.e., it uses the JSON boolean directly. The RO-Crate spec also does that in the workflow example:

  "valueRequired": true

However, there's also https://schema.org/True and https://schema.org/False. Is any / all of these (see #268) also ok?

  "valueRequired": {"@id": "https://schema.org/True"}

  "valueRequired": "https://schema.org/True"

  "valueRequired": "True"

[stain]

This is tricky one.. the JSON true maps to "true"^^<http://www.w3.org/2001/XMLSchema#boolean> as an xsd-typed string e.g. in https://json-ld.org/playground/

See https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-Datatypes -- basically in RDF 1.1 any literal value has a defined datatype, if unspecified, then it is an xsd:string (RDF 1.0 even distinguished between untyped "foo" and "foo"^^xsd:string).

Mostly literal values of different types are different even if they have the same string value, however some of them can be coerced in SPARQL, e.g. you can compare an xsd:integer with an xsd:double using <. (This is much less liberal than say PHP which has notorious broken type cohersion)

This mapping to XSD types breaks down in schema.org's definitions -- http://schema.org/Boolean is a kind of conceptual data type class that is not directly connected to http://www.w3.org/2001/XMLSchema#boolean

http://schema.org/True is also defined as a data type so a class of values.. so if anything then ``"true"^^http://www.w3.org/2001/XMLSchema#boolean` is an instance of http://schema.org/True -- so I would not recommend using them as a controlled vocabulary.

You find the same with http://schema.org/Integer and use of plain numbers like 1337 in JSON, and http://schema.org/DateTime which have a series of odd xsd equivalents.

It's a different issue on what to do with enums like http://schema.org/ActionStatusType -- their values should be used in @id form:

"actionStatus": { "@id": "http://schema.org/FailedActionStatus" }

For consistency with the JSON-LD context use of http mapping (see #349) enums references should also use http variants.