W3C home > Mailing lists > Public > public-linked-json@w3.org > December 2011

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

From: Alexandre Passant <alex@seevl.net>
Date: Mon, 12 Dec 2011 17:11:10 +0000
Message-ID: <CALF6uCkGuxCSyH2cBzaHcWLcs6iPxk2ptvbnM1NRvJ8xcZZExw@mail.gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: Linked JSON <public-linked-json@w3.org>
Hi all,

On Sun, Dec 11, 2011 at 7:32 AM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> 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:

[snip]

> @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).

I found that one particularly useful. I'd like to hide URIs in JSON
and base is helpful for this.

e.g

{
    "@base": "http://example.org"
    "friend":  {
            "id": "foobar#id",
    }
}

Instead of

{
    "friend":  {
            "uri": "http://example.org/foobar#id"
    }
}

So +1 from my side to keep it or something similar.

I'd also favor a "@suffix" element, so that I could use

{
    "@base": "http://example.org"
    "@suffix": "#id"
    "friend":  {
            "id": "foobar",
    }
}

or - compact form proposal

{
    "@base": "http://example.org{@iri}#id"
    "friend":  {
            "id": "foobar",
    }
}

Alex.

>
> 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
>
>
>
>



-- 
Dr. Alexandre Passant - @terraces
Founder, CEO - http://seevl.net - @seevl
http://facebook.com/seevl.net - http://angel.co/seevl
Received on Monday, 12 December 2011 17:11:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT