W3C home > Mailing lists > Public > public-annotation@w3.org > July 2015

Re: [web-annotation] Absolute or relative URI's in examples

From: James M Snell <jasnell@gmail.com>
Date: Thu, 30 Jul 2015 10:26:54 -0700
Message-ID: <CABP7RbcvFQvQ4PAZ1qW0UY3uOOW8taAFqCHjfcrHuQoTZD5OYA@mail.gmail.com>
To: Benjamin Young <bigbluehat@hypothes.is>
Cc: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, Rob Sanderson via GitHub <sysbot+gh@w3.org>, W3C Public Annotation List <public-annotation@w3.org>
In general, relative URL's just simply do not work in JSON-based
markup for the simple fact that the majority of implementations do not
even bother attempting to preserve the base URL context. It would
certainly be helpful if @base was promoted in JSON-LD but even that
can be problematic if it is not used consistently (particularly if a
JSON-LD document contains data aggregated from multiple sources).

On Thu, Jul 30, 2015 at 9:13 AM, Benjamin Young <bigbluehat@hypothes.is> wrote:
> On Thu, Jul 30, 2015 at 5:16 AM, Stian Soiland-Reyes
> <soiland-reyes@cs.manchester.ac.uk> wrote:
>>
>> You are right, the @base must be inside the @context - so to avoid
>> full URIs in the JSON-LD you would have to use the verbose
>>
>> { "@context":  [
>>     {"@base": "http://example.com"},
>>     "http://www.w3.org/ns/oa/context?" ]
>>
>>   "..": "..."
>> }
>
>
> Yeah...I forgot we'd need to make @context an array...which even more
> complex.
>
> Stian, do you know why @base isn't a top-level key? Would be handy and
> clearer, imo.
>
>>
>> Perhaps simpler is to use full URIs in the Turtle.
>
>
> +1
>
> I think this avoids making the JSON-LD look more complex, and still jives
> with the Turtle world.
>
>>
>> People who know
>> Turtle will know how to make relative URIs - while people who are a
>> bit fresh will still see it at a more standard 'triple level'.  This
>> should somewhat discourage people from accidentally making URIs that
>> don't resolve.
>>
>>
>> (Why is the oa @context missing from the JSON-LD example? Have we
>> decided on a URI yet?)
>
>
> It'd be too much cruft to do inline, and doesn't yet have a URI.
>
> Once it has a URI, though, we should put it in there for sure...as otherwise
> they're incomplete...unless the implementor provides a `Link` header of
> course...
>
>>
>>
>> Rant time about JSON-LD @context:
>>
>> -- we had several discussions in JSON-LD community about this.. in
>> early draft you could inherit a @base from an external @context - but
>> we changed our mind as that sounded quite confusing and dangerous, and
>> raised lots of scary issues with multiple contexts.
>>
>> In one evil version you could do an external context that defined {
>> "@base": "../" } (I actually wanted to do this! :))  and which would
>> be resolved by the location of the document (e.g.
>> file:///something/something.jsonld ) rather than from the external
>> context's URI. But that is just too far away from how relative IRIs
>> are resolved per document on the rest of the web - and hence the @base
>> inheritance was removed, and a stronger requirement for absolute URIs
>> in @base and @vocab was added.
>
>
> Yeah. That would've been confusing. :)
>
> I will double +1 my @base as a top-level key vote, though. ;)
>
> Thanks for the thoughts, Stian!
> Benjamin
>
>>
>>
>>
>>
>> On 29 July 2015 at 16:21, Benjamin Young <bigbluehat@hypothes.is> wrote:
>> > Yeah. Think that should.
>> >
>> > I'd wondered about doing the same for the JSON-LD examples, but it's
>> > some
>> > pretty heavy cruft because `@base` isn't top level (afaik), so it ends
>> > up
>> > looking like:
>> > ```json
>> > {
>> >   "@context": {
>> >     "@base": "http://example.com/"
>> >   }
>> > }
>> > ```
>> > http://www.w3.org/TR/json-ld/#base-iri
>> >
>> > Also...
>> >> Please note that the @base will be ignored if used in external
>> >> contexts.
>> >
>> > Which is kind of sad...but also makes sense.
>>
>>
>>
>> --
>> Stian Soiland-Reyes, eScience Lab
>> School of Computer Science
>> The University of Manchester
>> http://soiland-reyes.com/stian/work/
>> http://orcid.org/0000-0001-9842-9718
>
>
Received on Thursday, 30 July 2015 17:27:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:38 UTC