Reducing the number of keywords (ISSUE-15, ISSUE-26, ISSUE-31)

To get a feeling for the issues regarding the different keywords (@subject,
@iri, @vocab, @base, @type, @datatype, ..) I went through the specification
again. Currently we use the following ten keywords:

 - @context
 - @base
 - @vocab
 - @literal
 - @subject
 - @iri
 - @language
 - @datatype
 - @type 
 - @list

plus some more for framing which are just explained as part of the framing
algorithm (@embed, @explicit, ...).

So let me shortly summarize my thoughts about all of them:

@context is crucial and it's definition is clear. So no need to discuss
this.

@subject and @iri are basically doing the same and thus they are considered
to be redundant (ISSUE-15). @iri is a bit special as it's also a data type
at the same time.

@literal is used to set the value of a property when it is typed or it's
language is specified. The name @literal is based on RDF. Something like
@value might be easier for JSON developers to understand, but that's just
nit-picking

@datatype and @type are more or less doing the same, the distinctions from a
JSON-LD point of view are minor. The differences just arise when converting
to RDF. They could be merged without losing any functionality (ISSUE-31).

@language is self explaining, it's used to set the language of a property.
So no need to discuss this.

@list is similar to @iri in that it's used both as a data type and a way to
set the value of a property and define it as a list at the same time. The
use cases and the functionality it provides are clear.

@base and @vocab are used to set the base IRI for objects/properties. The
use cases are not so clear and they don't enable any new functionality. So
there's a discussion to remove them (ISSUE-26).

So, if we would like to simplify JSON-LD as much as possible and eliminate
as much keywords as possible without losing functionality we could end up
with the following minimum set of keywords:

 - @context
 - @iri
 - @literal
 - @language
 - @datatype
 - @list

Which would leave us with a mere of six keywords instead of ten. I really
think we should try as hard as possible to create the simplest possible
solution. We should begin with the Lite version and not follow the bad
example of other approaches starting with an overly complex solution and
creating a Lite version afterwards.

In that version @list and @iri are still used in two different ways. If we
see them purely as data types we could eliminate the use of the shortcuts
"@iri": "..." and "@list": [ ... ] and require the use of "@datatype":
"@iri"/"@list" plus "@literal": "..."/[...] as alternative but this would
imply a need @subject again. I don't know if that's the right thing to do
but it certainly would simplify the spec.

Another thing that I noticed while going through the spec is that using the
words subject, property (note we aren't using predicate) and object might
confuse some people. The subject has to be a JSON object, the (LD graph)
object doesn't. We could mitigate this by talking about nodes which have
properties whose values might be other nodes or a literal value. I've added
ISSUE-47 to not forget this.



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 11 December 2011 07:33:38 UTC