Using custom trait context

[Amerehei]

As Bluescape traits are JSON-LD object and for input we should pass context and content. When I send my custom domain as context (e.g https://schema.company.com), Bluescape refuses to accept it and returns Unsupported @context URL "https://schema.company.com/" . It accepts https://schema.org/ as context

How can I define a valid JSON-LD schema? I wanted to use https://schema.company.com to reserve it for the future to define custom schema.

Do you have any recommendation for using traits?

[kkoechley]

Hi @Amerehei,

Another great question! I’ll have to confirm using custom JSON-LD schema and will get back to you.

Are you looking to do something in particular where https://schema.org context isn’t sufficient?

[Amerehei]

@kkoechley At the moment I can easily ignore JSON-LD validation and use invalid objects like the following, if you open https://validator.schema.org/ and validate this object you would have (The property isTemplate is not recognized by the schema (e.g. schema.org) for an object of type CreativeWork.) error

{
  "@context": "http://schema.org",
  "@type": "CreativeWork", 
  "isTemplate": true
}

I afraid, If I ignore validation at this time and use invalid objects with http://schema.org context, in the future when I need to model my metadata objects and validate them, I will have to immigrate all old data and it’s a complex process.

If I simply use "https://schema.company.com/custom.jsonld" as context, in the future I can host my own custom schemas (Like Person object) to be 100% compatible with JSON-LD standard

[Amerehei]

I incidentally found that if I send https://schema.org as context input and fetch element traits in the response it will become http://schema.org (https becomes http)

[kkoechley]

Hi @Amerehei,

Thanks for the clarification of the use case you are trying to solve.

While we don’t currently support passing arbitrary JSON-LD contexts by URL, and don’t have the ability to validate against the schema published by schema.org, we do support using vocab or inline context to create namespaces to help avoid collisions.

For example:
When creating the following trait:
mutation ($workspace: String!, $id:String!) { traits: updateTraits(workspaceId:$workspace, id:$id, input: { context: "http://schema.org/", content: {isTemplate: 1} })}

When using create or update a trait using schema.org context, you would create a trait at http://schema.org/isTemplate which actually has no definition on schema.org and would not validate. The context doesn’t define the schema, it only maps short property names to entities in a schema, it only helps with avoiding collisions.

Options to manage JSON-LD traits

1. Use vocab to create your own namespace:
   mutation ($workspace: String!, $id:String!) { traits: updateTraits(workspaceId:$workspace, id:$id, input: {vocab: "http://schema.company.org/", content: {isTemplate: 1}}) }

This will put your traits in your own namespace: http://schema.company.org/isTemplate where it would not collide with anything in schema.org

You can then query to look for isTemplate in http://schema.company.org namespace:

#query to return elements with matching vocab namespace:
query filterTraits($workspaceId: String!, $queryTraits:TraitInput!){
	elements(workspaceId: $workspaceId, traits:$queryTraits) {        
		__typename
	    id
	    traits

	    transform {
	        x
	        y
	        scaleX
	        scaleY
	    }
	}
}

with variables using the previous vocab: http://schema.company.org/

{
    "workspaceId": "{{workspaceID}}",
    "queryTraits":{ "context":{
        "@vocab": "http://schema.company.org/"
            },"content":{"isTemplate":1} }
}

2. Use an inline context:

#update element JSON-LD traits metadata with inline
mutation ($workspace: String!, $id:String!) {
traits: updateTraits(workspaceId:$workspace, id:$id, input: {context: { isTemplate: "http://schema.company.org/isTemplate"}, content: {isTemplate: 1}})
}

You can then query to look for elements with TraitInput:

#query to return elements with matching trait data:
query filterTraits($workspaceId: String!, $queryTraits:TraitInput!){
    elements(workspaceId: $workspaceId, traits:$queryTraits) {        
        __typename
        id
        traits

        transform {
            x
            y
            scaleX
            scaleY
        }
    }
}

with variables with inline context:

{
    "workspaceId": "{{workspaceID}}",
    "queryTraits":{"context":{"isTemplate":"http://schema.company.org/isTemplate"}, "content":{"isTemplate":1} }
}

note the response that there are multiple namespaces to avoid collisions:

{
    "data": {
        "elements": [
            {
                "__typename": "Shape",
                "id": "6516afa810aa3624fc2df6c8",
                "traits": {
                    "http://schema.company.org/testTraits": 1,
                    "http://schema.org/testTraits": 1,
                    "http://schema.foo.org/testTraits": 1,
                    "http://foo.org/testTraits": 1,
                    "http://schema.bar.org/testTraits": 1,
                    "http://schema.bar.org/isTemplate": 1,
                    "http://schema.company.org/foo": 1,
                    "http://schema.company.org/isTemplate": 1
                },
                "transform": {
                    "x": -261,
                    "y": 53.03025667734585,
                    "scaleX": 1,
                    "scaleY": 1
                }
            }
        ]
    }
}

I hope this clarifies what we currently support and how you can use context and vocab to avoid collisions with namespaces.

[Amerehei]

Great! Thanks a lot
Your response was awesome

[kkoechley]

Thanks! And your question was great as well!