Re: usage question for custom vocabulary terms

Sorry for the delay in response …

> On Dec 8, 2017, at 5:04 PM, Marisa DeMeglio <marisa.demeglio@gmail.com> wrote:
> 
> Hi Gregg, Thanks for your reply! I have a few questions inline below.
> 
> 
>> On Dec 8, 2017, at 4:02 PM, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>> 
>>> On Dec 8, 2017, at 2:28 PM, Marisa DeMeglio <marisa.demeglio@gmail.com <mailto:marisa.demeglio@gmail.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> I hope this is the right list for this question! I’m a developer working on a tool that outputs JSON-LD and I have a question about using custom vocabulary terms. Our output currently contains a mix of preexisting vocabularies (e.g. earl, dublin core, doap) and custom terms, some of which reference external schema, and some of which are entirely ours. One such custom term is “hasManifestCallbacks”, which is super specific to our project. How do I use a custom term in a JSON-LD file? I’m not sure how to declare it in the context:
>>> 
>>> 
>>> {
>>>  "@context":
>>>  {
>>>    "earl": "http://www.w3.org/ns/earl# <http://www.w3.org/ns/earl#>",
>>>    "doap": "http://usefulinc.com/ns/doap# <http://usefulinc.com/ns/doap#>",
>>>    "dct": "http://purl.org/dc/terms/ <http://purl.org/dc/terms/>",
>>>  },
>>> 
>>>  "url": "http://schema.org/url <http://schema.org/url>",
>>> 
>>>  "css": "http://pending.schema.org/cssSelector <http://pending.schema.org/cssSelector>",
>>> 
>>>  “hasManifestCallbacks”: ??
>>> 
>>> }
>>> 
>>> Could someone point me to some examples of this? I haven’t come across any thus far.
>> 
>> Hi Marisa, fine place to ask such a question; many questions are asked on Stack Overflow as well.
>> 
>> JSON-LD has the concept of terms, which are typically defined per-vocabulary term in the context, but you can also use terms are vocabulary prefixes, as you have done above. The basic purpose of defining terms in the context is to associate them with an IRI, but you can also define things like expected type range, and container properties. This all described in some detail in the spec [1]. In particular, 5.1 The Context, 6.5 Type Coercion, and 6.7 Advanced Context Usage. You can also find examples, and play with your own on the playground [2].
>> 
>> Your case above defines a context containing prefixes, but then seems to define terms outside of the context; the last three terms should be included along with the prefix definition.
> 
> Ah right, not sure what example I followed to end up with that, but I see what you mean. Thanks for pointing that out! 
> 
>> 
>> As for hasManifestCallbacks, you just need to associate an IRI with it to be able to use it in the document; it’s not uncommon for organizations to create their own vocabularies for this purpose, but the vocabulary should have a published IRI, and the terms should be relative to that (either using a fragment notation such as http://example.org/vocab#hasManifestCallbacks <http://example.org/vocab#hasManifestCallbacks>, or as s sub-resource such as http://example.org/vocab/hasManifestCallbacks <http://example.org/vocab/hasManifestCallbacks>. You can then use these IRIs when defining the term in your JSON-LD document.
> 
> Ok so two questions here:
> 
> - does our custom vocabulary have to follow any kind of format?

No, the context doesn’t really care about the content of your vocabulary, just that the classes and properties are defined using URIs. JSON-LD is really all about turning terms into URIs along with properly interpreting values; that’s as defined in the context itself, not your vocabulary.

> - is it possible in a JSON-LD file to use a term that’s not defined in any vocabulary? For example, in our report, some data is part of an internal interchange format, and it lives alongside the better-documented, more stable report data.

Certainly, you just need to define that the term expand to a URI, it doesn’t need to be actually defined in a vocabulary document.

The principle of Linked Data is that URIs can be followed to get their definition, including vocabulary terms. but this is usually not done in practice, and there’s nothing in the JSON-LD processing rules that in any way depends on this.

Gregg

> Thanks again
> Marisa
> 
>> 
>> Hope that helps.
>> 
>> Gregg
>> 
>> [1] https://www.w3.org/TR/2014/REC-json-ld-20140116/ <https://www.w3.org/TR/2014/REC-json-ld-20140116/>
>> [2] https://json-ld.org/playground/ <https://json-ld.org/playground/>
>> 
>>> Thanks
>>> 
>>> Marisa