RE: Heads Up: proposal deep linking

> > {
> >  "queenie": {
> >    "@id": "http://buckingham.uk/queenie",
> >    "label": {
> >      "en": "The Queen",
> >      "de": "Die Koenigin"
> >    }
> > }
> 
> [...]
> Yes, it would, and you might think of it as "value", instead of
> "@value"; but it's really just an example. The idea would be that "en"
> would basically insert a @context at that level which would set
> "@language" to "en". But, there might be other things at that level.
>
> [...]
>
> From Denny's perspective, having a single "label" with properties that
> can be iterated upon is the key here, not having multiple properties
> related by naming tricks. Also, assigning a language to label_en, for
> example, does not actually result in setting @language for other things
> contained within that property.

Are you saying that the value of "en" and "de" could also be a whole new
subtree instead of just being a string?


> > If we are going to support something like this, I think we should
> leverage
> > our @container mechanism for this. Something like
> >
> > {
> >  "@context": {
> >    "label": {
> >      "@id": "http://example.com/label",
> >      "@container": "@language"
> >    }
> >  },
> >  "@id": "http://buckingham.uk/queenie",
> >  "label": {
> >    "en": "The Queen",
> >    "de": "Die Koenigin"
> >  }
> > }
> 
> It's a pretty confusing use of @container, and the other example shows
> folding without actually introducing a language, so it's not quite that
> simple.

This example was just addressing the i18n issue and not the folding stuff.


> > How would you see @fold work when "queenie" is a property of another
> valid
> > subject, something like
> >
> > {
> >  "@id": "http://example.com/parent",
> >  "queenie": {
> >    "@id": "http://buckingham.uk/queenie",
> >    "label": [
> >     { "@value": "The Queen", "@language": "en },
> >     { "@value": "Die Königin", "@language": "de" }
> >    ]
> > }
>
> [...]
> 
> In this case, I don't think folding would apply; it's more similar to
> the case where we now use @graph to contain a list of properties; this
> would use a different name, and not have the named-graph consequence.
> The original use of @graph was to be able to list several subject
> definitions at the same level where we needed a key; the named-graph
> sense was added later.

So when does it apply and when doesn't it?


> I didn't mean to indicate that this was a fully baked concept, but that
> it was the result of some discussions where there are some common
> issues that are raised. In WikiData's case, a desire to separate
> sections of the JSON by language without imposing semantic overhead,
> and to be able to effectively use subjects are keys, also without the
> semantic overhead.

I can just comment on what you wrote and that's what I did. Sorry if I
offended you by doing so but I think any feedback is better than none.


> Perhaps Denny can chime in on some more of his specifics, but I've had
> a couple of interactions that wanted to have a means of grouping
> language-variations of property values under a common key, which is
> certainly a reasonable way to want to structure JSON.

... and shouldn't be conflated with controlled probing/folding.


> The issue of having some subject-like key is something we've seen in
> other JSON representations, and it could be considered to be a weakness
> of JSON-LD that we can't adapt to take such input.

Well, in our graph model properties are arc/edges whereas values are nodes.
Changing that is gonna be really complex IMHO. I know I proposed something
very similar some time ago but you guys convinced me that it's a) too
complex, and b) not really required. We introduced @graph in consequence...
that's why I'm skeptic about this proposal and can't see (yet) why it should
be any different this time.


> If we're not willing to listen to considered feedback from the
> community and consider changes to the spec to meet their requirements,
> then I'm not sure we're being good advocates for the community.

The fact that I devote a lot of my free time to work on JSON-LD and to
answer to mails like these should be evidence enough that I do consider
feedback from the community. Nevertheless I think I'm allowed to express my
personal opinion and report what has already been discussed and decided in
the past - and that's all I did. I know we all have our ups and downs and
everyone is sometimes frustrated that his ideas/proposals are not accepted
(or sometimes not even discussed as quite a few of mine haven't in the
recent past) and everything takes longer than hoped. We can also revisit
things that have already been discussed and were we already reached
consensus and made decisions, but I think there has to be a solid proposal
and at least a number of use cases/scenarios that have to be presented to
revisit a closed issue. That's why I asked (twice) for exactly that. I have
no interest whatsoever in blocking any reasonable proposal.


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 6 June 2012 14:29:26 UTC