RE: Merging @base and @vocab and change their behavior

I understand how they are used and what the differences are. But I still
think they add unnecessary complexity without any clear advantages. Do we
really expect that in most of the use cases just one vocabulary is used?

Having @base and @vocab makes it very difficult to read a JSON-LD document
since one have to keep in mind two (three?) base IRIs. Is this really
necessary? I wouldn't even be opposed to drop both, @base and @vocab.



> -----Original Message-----
> From: public-linked-json-request@w3.org [mailto:public-linked-json-
> request@w3.org] On Behalf Of Niklas Lindström
> Sent: Monday, September 05, 2011 11:01 PM
> To: Markus Lanthaler
> Cc: public-linked-json@w3.org
> Subject: Re: Merging @base and @vocab and change their behavior
> 
> Hello!
> 
> I have to go with -1 on this. It would mean dropping the ability to
> use them for the separate concerns of resolving resources and their
> properties/classes.
> 
> I don't think it is the common case that subjects and objects share
> the same base as the used vocabulary/vocabularies. Think for instance
> of foaf profiles, bibo records and goodrelations items. It is very
> beneficial to use @vocab to set the prefix IRIs of either foaf, bibo
> or gr, hence enabling the use of simple term tokens. But that would
> not be the useful to resolve subjects and objects against, which will
> likely reside on one or many domains separate from that of these
> vocabularies. (And even more so with data described using the
> schema.org vocabulary!)
> 
> And note that @vocab doesn't (at least it shouldn't!) resolve relative
> IRIs – it is prepended to "opaque" terms the result of which is
> interpreted as an IRI. Quite different from the base URI mechanism (of
> at least HTML, XML and Turtle).
> 
> In my current work, I use the canonical IRI of the current subject as
> @base, enabling me to use absolute IRIs (starting with "/") to link to
> other resources within the same domain (data space) *and* to use
> fragment IRIs to link to parts of the same resource (e.g. "#p_1" for a
> paragraph). And I also use @vocab for the main vocabulary (which is
> quite separate from the current resource).
> 
> The analogy of @vocab and @base in JSON-LD to their equivalents in
> Turtle would in my view be:
> 
>   @prefix : <http://example.org/def/stuff#> . # like @vocab in JSON-LD
>   @base <http://example.com/document/one> . # like @base in JSON-LD
> 
>   <> a :Document;
>     :hasVersion </document/two> .
> 
> Which is equivalent to:
> 
>   @prefix : <http://example.org/def/stuff#> .
> 
>   <http://example.com/document/one> a :Document;
>     :hasVersion <http://example.com/document/two> .
> 
> 
> Of course, JSON-LD could use @base to resolve non-CURIEs if there is
> no defined @vocab. But that might be quite complex if resolving
> against them works differently (IRI resolution vs. plain
> concatenation). In fact, if you're looking to simplify things, I'd
> suggest dropping @base (thus requiring the use of full IRIs in
> subjects and objects) and leaving @vocab as it works now. Personally
> though (as evident from my mentioned work) I find @base useful.
> 
> And note that I definitely think that @base should work for both
> subjects and objects. (If it doesn't that sounds like a spec bug.)
> 
> (On a side note, it may be worth noting that it's easier to pattern
> match on full IRIs (i.e. not use @base), in case you're interested in
> an (optional) auto-coercion mechanism for such things. But I digress.)
> 
> Best regards,
> Niklas
> 
> 
> 
> On Thu, Sep 1, 2011 at 3:49 PM, Markus Lanthaler
> <markus.lanthaler@gmx.net> wrote:
> > In the current spec we have @base and @vocab to change the base IRI
> for
> > objects and properties (but nothing for subjects). I think that's
> > unnecessarily complicated and inconsistent.
> >
> > I would thus propose to merge @base and @vocab to @base and make it
> work as
> > it currently does in HTML and Turtle, i.e., @base would overwrite the
> base
> > IRI for *all* relative IRIs in the document.
> >
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >
> >
> >
> >



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 11 September 2011 21:49:48 UTC