Generates a JSON-LD Context for Schema.org.

schemaorg_to_jsonldcontext.py

from rdflib import *


SDO = Namespace("http://schema.org/")

datatype_coerce_map = {
    #SDO.Number: XSD.double,
    SDO.Date: 'xsd:date',
    SDO.DateTime: "xsd:dateTime",
}

def make_context(graph, use_vocab=False, dt_coercion=False, object_coercion=False):
    ctx = {'xsd': unicode(XSD)}
    if use_vocab:
        ctx['@vocab'] = SDO
    else:
        for cls in graph[:RDF.type:RDFS.Class]:
            term_key = graph.value(cls, RDFS.label)
            ctx[term_key] = unicode(cls)

    for prop in graph[:RDF.type:RDF.Property]:
        term_key = graph.value(prop, RDFS.label)
        ranges = list(graph.objects(prop, SDO.rangeIncludes))
        coercion = None
        if len(ranges) == 1:
            if ranges[0] == SDO.URL:
                coercion = "@id"
            elif dt_coercion:
                coercion = datatype_coerce_map.get(ranges[0])
        elif object_coercion and not any(SDO.DataType in
                graph.objects(rng, RDFS.subClassOf*'*') for rng in ranges):
            coercion = "@id"
        if coercion:
            dfn = ctx[term_key] = {"@type": coercion}
            if not use_vocab:
                dfn["@id"] = unicode(prop)
        elif not use_vocab:
            ctx[term_key] = unicode(prop)

    return {"@context": ctx}


if __name__ == '__main__':
    from sys import argv
    import json
    from rdflib.util import guess_format

    args = argv[1:]
    source = args.pop(0)
    use_vocab = '-V' not in args
    dt_coercion = '-d' in args
    object_coercion = '-o' in args

    graph = Graph().parse(source, format=guess_format(source))
    context = make_context(graph, use_vocab, dt_coercion, object_coercion)

    s = json.dumps(context, sort_keys=True, indent=2, separators=(',', ': '),
            ensure_ascii=False).encode('utf-8')

    import re
    print re.sub(r'{\s+(\S+: "[^"]+")\s+}', r'{\1}', s)

Thanks, that seems to generate something. Now there's the problem of working out if it's an accurate description.

We still have the problem of what to do with properties whose values are sometimes strings, sometimes things. Any recommendations?

This script basically mimics the behavior of the JS version. It could certainly be improved take multiple ranges into account, and not automatically coerce anything if so.

Personally, I believe that simply using {"@vocab": "http://schema.org/"} is quite good in itself; and to expect people to describe things with objects (e.g. name plus ideally an URI: {"name": "Me", "@id": "/me#self"}). That is simpler and more uniform.

Of course, it depends on whether a property taking either a thing or a string should cater for one or the other by default. If a property is coerced to @id, a user can still force the value to be a string by using {"@value": "string..."}.

For datatyped values though, I'd recommend coercion to e.g. dates and numbers where that is unambiguously expected. (Though for dates, perhaps sdo:Date would be softer/safer than xsd:date or xsd:dateTime). Also, for properties taking URL, coercing to @id is reasonably good.

@danbri: I updated the script to use @vocab by default (turn off with -V) and not type-coerce to @id by default (turn on with -i). It also compacts the JSON a bit more.

Possible improvements:

• figure out which properties expect ordered lists, and use @container: @list for those
• use the softer date/dateTime datatypes of schema.org?

We still have the problem of what to do with properties whose values are sometimes strings, sometimes things. Any recommendations?

@danbri, not type-coercing them in the context would be the right thing to do IMO. That way, people can either set its value to just strings or objects which are then interpreted as things.

Is there anything else we can do to help? I think we are all comitted to help as much as possible to get the context up on schema.org as soon as possible.

Test build: http://sdo-context-test.appspot.com/

Did an update to the coercion controls. The script now outputs a small, limited context by default (where only exclusive URL properties are coerced to @id). Use flag -d to turn on datatype coercion (defined for Date and DateTime), and flag -o to add @id coercion for all other properties which don't have any DataType class as a possible range.

This generates an JSON-LD @context from elasticearch mappings with rudimentary xsd: type mappings: https://github.com/westurner/elasticsearchjsonld/blob/master/elasticsearchjsonld/elasticsearchjsonld.py

The TopBraid RDF versions of the schema.org ontology can be transformed to JSON-LD (e.g. with rdfpipe or a short pyld script w/ framing and compaction, etc.), but do lag just a bit (due to lack of build automation integration)): http://topbraid.org/schema/

• http://topbraid.org/schema/schema.ttl