Re: Defining property labels in external context document

Hi Adrian,

I very much sympathize with what you're after here, as I've also pondered
this. I hope can explain some thinking regarding the various options, and
the underlying design principles.

Not all RDF schemas declare specific ranges for their values. Others allow
a union of various datatypes. JSON-LD allows you to pair up a property and
one specific datatype under one named term (along with some other things,
like "@container" settings). But notice that the term is not equal to the
property (in spite of the use of "@id" – the context is a rather special
beast). So there is a subtle but important difference here. JSON-LD
contexts are *only* about the syntactic mechanism for this, and defers to
RDFS/OWL to describe the referenced property.

However, I agree that it may be quite usable to combine syntactic context
with some semantic data. So if you want to serve relevant RDF/OWL schema
data along with the context, let's investigate the options at hand:


## Option A

It might be tempting to mix it into the context, and it is actually allowed
to add other data in the term definition objects as well. However, I do not
recommend that. Context data used like that would be deceptively similar to
regular JSON-LD data, but the keywords mean very different things. For
example, in the context, "@type" is more akin to (but not identical to) an
rdfs:range for an owl:DatatypeProperty (as opposed to a shorthand for
"rdf:type"). And, as mentioned, "@id" has a different meaning in the
context (and even an extended lexical space, the same as coercing to
"@vocab"). So I'd avoid this.

In fact, the only things I recommend to extend term definitions with are
application-specific syntactic stuff, such as some kind of "orderedBy",
"useAsIndex", "boost" or other processing mechanisms.

(Another problem with this option is that the context document is intended
to be a fairly minimal, reusable piece of information. In certain cases
you'd even want to embed it in each and every document which uses it, to
preserve all data.)


## Option B

Add data in the body representing the interesting RDFS/OWL data about each
term of interest. To do this, declare one special property, let's call it
"termIndex", which is to be used in the body. It will be an indexed
property, which is a syntactic convenience where any key can be used
without affecting the semantics (i.e. the RDF expressed). Here, we will use
the context terms as keys. An example:

    {
      "@context": {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "dc": "http://purl.org/dc/terms/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "creator": {"@id": "dc:creator", "@type": "@id"},
        "createdDate": {"@id": "dc:created", "@type": "xsd:date"},
        "createdTime": {"@id": "dc:created", "@type": "xsd:dateTime"},
        "termIndex": {"@id": "@graph", "@container": "@index"},
        "commentByLang": {"@id": "rdfs:comment", "@container": "@language"}
      },
      "termIndex": {
        "creator": {
          "@type": "rdf:Property",
          "@id": "dc:creator",
          "commentByLang": {"en": "The creator", "de": "Der Schöpfer",
"sv": "Skaparen"}
        },
        "createdDate": "created",
        "createdTime": "created",
        "created": {
          "@id": "dc:created",
          "@type": "rdf:Property"
        }
      }
    }

Here I also illustrate multiple terms for the same property ("dc:created"),
and had to make up some kind of cross-reference (which should be discarded
by an JSON-LD processor interpreting this as RDF). In practise, it may be
better to repeat the data instead. Or to use an index of the full property
(and class) IRIs instead.

In general, this B option is also easy to split apart into two documents:
the context and the documentation. The documentation document, with your
term definitions, can thus be served as separate, structured documentation.
In fact, you'd probably want a specific schema context for that, instead of
having e.g. "termIndex" and "commentByLang" being part of the main context.

Furthermore, you will have schema data being proper JSON-LD (and thus RDF),
and can process it using the regular conventions and tools. (For instance,
in combination with "@reverse", you can represent an entire tree of
subproperties and subclasses.)


## Option C

The two options above both assume that you actually want to use RDFS/OWL
data for the properties (and classes) to document your terms. Both ran into
some trouble because of that – since terms and properties are distinct
notions. You may instead actually want to have labels for the *terms*. To
be used for something very application specific, and not intended to be
used as RDF. You could just throw some label keys into the term
definitions, and treat that merely as raw data for your web application
and/or API documentation. (Or perhaps you'd like to investigate the
potential of merging JSON-LD contexts with JSON Schemas. Though I'd rather
see that as auxiliary information as well, and probably also problematic to
combine.)

(It might feel tempting to generalize this into RDF anyway of course, and
e.g. use rdfa:TermMapping [1] definitions and so on. We're not there yet
though – that is with looking at JSON-LD contexts themselves as RDF. I'm
not sure about the value of that at this time though.)


.. I do admit that I have sometimes mentioned, and considered pushing for,
using other keywords (like the original "@coerce") in the context to
facilitate the merging outlined in option A (or the final remark in option
C). That is, in order to make context data processable as regular JSON-LD
as well. But I convinced myself otherwise using the above reasoning. I felt
that it would be trying too hard. Who knows, we might device something
better in the future, if need be. Though I think that JSON is very limited
by design, and this mixing does not fit well within it. Using full-fledged
RDF toolkits, where you can traverse across graphs and between instance and
metadata freely, and have much more mixed use of object types, is another
situation entirely. Trying to generalize the contextual applicability of
JSON to these scenarios is likely to become very complex, and veer away
from where JSON is usable. As a bridge, we have JSON-LD. It allows for the
publication and use of rich, integrable RDF as regular JSON, directly
accessible to all common web developer stacks.

But it's just one or two rungs on a ladder – we shouldn't reach too far. To
see where we are though, questions like yours are very important, in order
to discover usable patterns, as well as their limits.

Cheers,
Niklas

[1]: http://www.w3.org/ns/rdfa.html

--
Niklas Lindström
National Library of Sweden (KB)



On Thu, Jul 18, 2013 at 1:40 PM, Adrian Pohl <pohl@hbz-nrw.de> wrote:

> >>> On 18.7.2013 at 12:14, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>
> > It looks like you're trying to mix different levels.
> > Labels are usually defined on RDF-Schema level, where you define classes,
> > properties, their relationships and their metadata (including
> human-readable
> > labels).
>
> Markus said something similar. But there are at least two problems with
> defining labels on RDF-Schema level:
>
> 1. Often, German labels (which I also need) for a property don't exist. If
> you offer to add these to the vocabulary you might not even get an answer
> (I offered my help for label translation to DC once and never got an
> answer) or it might take a lot of time until you have these labels.
> 2. Even if a property label exists on RDF-Schema level, this might not be
> the one you would like to use, e.g. for the purpose of presentation. And
> sometimes it may well be necessary to define different labels for a
> property in different contexts. E. g. the property label for a cataloger
> might be more technical than the one I provide to an end user for the same
> property. I can use Fresnel [1] (which we have done until now) or something
> else for specifying defining custom property labels but would be quite
> happy if this could be done in a JSON-LD context document.
>
> > @context is an instruction to processor, which tells that "name" is
> actually
> > a http://schema.org/name but it doesn't tell what it means.
> > Meaning is encoded in RDF-schema
>
> Hmm. This argument doesn't convince me as I think you can already do
> "meaningful" things in a JSON-LD context doc that are usually done on
> vocabulary level. See the Example 21 of the spec:
>
> {
>   "@context":
>   {
>     "modified":
>     {
>       "@id": "http://purl.org/dc/terms/modified",
>       "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
>     }
>   },
> ...
> }
>
> Typing a literal also tells what something means and it can be done in a
> JSON-LD context document. With the reasoning that meaning is provided on
> the RDF-Schema level one could also say that @type definition in @context
> isn't valid and should rather be done in the vocabulary. One could easily
> look up the property referenced in a @context and then take the value that
> is defined as rdfs:range.
>
> - Adrian
>
> [1] http://www.w3.org/2005/04/fresnel-info/
>
> > JSON-LD @context is not an alternative to this. It just helps to convert
> > shorter json-document into valid RDF.
> >
> > @context is an instruction to processor, which tells that "name" is
> actually
> > a http://schema.org/name but it doesn't tell what it means.
> > Meaning is encoded in RDF-schema
>
> >>> On 18.7.2013 at 12:14, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>
> > On 18.07.2013, at 14:00, "Adrian Pohl" <pohl@hbz-nrw.de> wrote:
> >
> >> Besides listing the different properties and defining their short names
> and
> > values, I also thought it would make sense to define the English and
> German
> > property labels. This would be quite useful as different uses of one
> context
> > document would present the same labels to end users.
> >
> > It looks like you're trying to mix different levels.
> > Labels are usually defined on RDF-Schema level, where you define classes,
> > properties, their relationships and their metadata (including
> human-readable
> > labels).
> >
> > JSON-LD @context is not an alternative to this. It just helps to convert
> > shorter json-document into valid RDF.
> >
> > @context is an instruction to processor, which tells that "name" is
> actually
> > a http://schema.org/name but it doesn't tell what it means.
> > Meaning is encoded in RDF-schema
>
>
>