W3C home > Mailing lists > Public > public-rdf-comments@w3.org > February 2013

Re: comment on JSON-LD 1.0: no @base support

From: Jeremy J Carroll <jjc@syapse.com>
Date: Tue, 26 Feb 2013 09:47:25 -0800
Cc: <public-rdf-comments@w3.org>
Message-Id: <4B67468F-5A15-49EB-8FE8-3F2087820E3F@syapse.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
I am sorry I saw this too late to attend the telecon this morning.

I was unaware of @vocab, and I am currently thinking about it.
I was also unaware that @base had been explicitly dropped because of the worthy goal of reducing variability.

I will follow up later this week after seeing the minutes of your call.

Jeremy

On Feb 26, 2013, at 3:23 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> Hi Jeremy,
> 
> Thanks for your feedback. We had support for @base in the past but decided
> to drop it to decrease the number of ways an IRI can be expressed. Is there
> a specific use case that cannot be solved using any of the existing
> mechanisms? Or is it just that it would be handy in some cases?
> 
> Personally, I'm very concerned about adding yet another mechanism to express
> IRIs. We already have:
> 
> - document-relative IRIs
> - absolute IRIs
> - terms
> - compact IRIs
> - @vocab as a global prefix for properties and values
>   coerced to @vocab
> 
> Is it really a problem to express the "custom base" using a prefix? Could
> @vocab be used?
> 
> 
>> I note that (3, the most powerful mechanism, best supports
>> reuse of existing JSON (Zero Edits, most of the time)
> 
> There are many things that would help in that regard - the most powerful
> technique probably being IRI templates (see ISSUE-108 [1]). But, at the same
> time, we must be very careful to not introduce too much variability.
> Requiring a developer to keep track of 3 (or more) base IRIs is very
> problematic in my opinion.
> 
> As you might already noticed we added your request to the agenda of today's
> telecon [2]. It's open for everyone, so please feel free to join.
> 
> 
> Cheers,
> Markus
> 
> 
> [1] https://github.com/json-ld/json-ld.org/issues/108
> [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2013Feb/0200.html
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
> 
> ------------ Original message --------------
> From: Jeremy J Carroll [mailto:jjc@syapse.com] 
> Sent: Friday, February 22, 2013 10:21 PM
> To: public-rdf-comments@w3.org
> Subject: comment on JSON-LD 1.0: no @base support
> 
> 
> Hi
> 
> this is a comment on http://www.w3.org/TR/json-ld-syntax/
> http://www.w3.org/TR/2012/WD-json-ld-syntax-20120712/
> 
> This is a formal comment, in that I would appreciate a response before
> JSON-LD exits last call.
> 
> Short form:
>   please add an optional attribute @base to be included as a Syntax Token
> and Keyword
> 
> Long form:
> 
> JSON-LD appears to provide two abbreviation mechanisms: prefixing and
> relative URIs
> 
> The draft provides good support for prefixing; but not much support for
> relative URIs, in particular no mechanism corresponding to section 5.1.1 of
> RFC 3986.
> 
> Three different designs would be:
> 1) allow an @base name/value pair at the top level of the JSON-LD document
> to specify a base URI applicable to the whole document
> [simple]
> 
> 2) allow an @base name/value pair at any level of the JSON-LD document to
> specify a base URI applicable to the scope of the document (scoped liked the
> @context)
> [more powerful]
> 
> 3) allow an @base inside the context, and to have the same scope as an
> @language within the Context
> [can be funky when multiple contexts are in separate documents, perhaps each
> specifying different @base's with relative URIs . !!!]
> 
> 
> Any one of these would adequately address the comment.
> 
> I note that (3, the most powerful mechanism, best supports reuse of existing
> JSON (Zero Edits, most of the time)
> 
> 
> thanks
> 
> Jeremy J. Carroll
> 
> 
> 
> 
Received on Tuesday, 26 February 2013 17:47:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:31 UTC