- From: Randall Leeds <randall@bleeds.info>
- Date: Tue, 23 Jun 2015 17:32:03 +0000
- To: Ivan Herman <ivan@w3.org>, Robert Sanderson <azaroth42@gmail.com>
- Cc: Doug Schepers <schepers@w3.org>, Jacob Jett <jjett2@illinois.edu>, Frederick Hirsch <w3c@fjhirsch.com>, W3C Public Annotation List <public-annotation@w3.org>
- Message-ID: <CAAL6JQjxdjQcE=GtpsrP15+OpMKXFG-tuAhJ1giwFynSNN+z+Q@mail.gmail.com>
If the motivating use for a context is to enable LD-aware servers to better
interpret simple JSON, I wonder if the case-insensitive collision is
actually a problem at all.
The core classes won't really appear in the JSON because such a
serialization isn't likely to specify the types of the values, except where
they are not inferable from the context, e.g TextPositionSelector. The core
type information for any relation is in the context, but not in the plain
old JSON object.
On Tue, Jun 23, 2015, 08:24 Ivan Herman <ivan@w3.org> wrote:
>
> > On 23 Jun 2015, at 17:11 , Robert Sanderson <azaroth42@gmail.com> wrote:
> >
> >
> > Hi Ivan, all,
> >
> > On Tue, Jun 23, 2015 at 12:12 AM, Ivan Herman <ivan@w3.org> wrote:
> >
> > > On 23 Jun 2015, at 05:04 , Doug Schepers <schepers@w3.org> wrote:
> > >> Unless case insensitivity is a goal,
> > > I think we should try for case insensitivity as a goal. Case
> sensitivity proved to be one of the most frustrating, hard-to-debug aspects
> of XML; I know it's bitten many people coding SVG, for example.
> > Doesn't JSON have case sensitivity? If so, we should decide once and for
> all for the style we use?
> >
> > It does. {"title": "foo", "Title": "bar"} is well formed, but likely to
> run into human error getting the case confused.
> >
> > Given that a class will never be in the key slot, and a predicate should
> never be in the value slot, the distinction between "selector"
> (oa:hasSelector) and "Selector" (oa:Selector) is okay.
> >
> > On the other hand, "tag" (oa:tagging) and "Tag" (oa:Tag) would both be
> in the value (of motivation and @type respectively), so I'm keen to keep
> the motivations as they are, for the same reason.
> >
> > Alternatively, we can include, in the @context, mapping of several
> formats to the same term (ie, @context can be many-to-one, afaik). But I am
> not sure I like that…
> >
> > We can't map the same json key to multiple rdf terms. Eg we can't have
> "tag" mean both "tagging" and "Tag" at the same time, otherwise processors
> would not know which one was meant. It can't be context sensitive (eg
> motivation: tag can't be different from @type: tag), and the processing
> rules mean that the most recently encountered definition is the one that's
> used.
> >
> > Also note that in a single context you can't have the same key mapped to
> multiple terms syntactically, as a JSON object can't have the same key
> multiple times. The processing rule for multiples covers the situation
> where there's multiple contexts defined separately.
> >
> > We could have multiple keys mapped to the same predicate.. eg both
> "datetime" and "timestamp" could be mapped to oa:annotatedAt. However the
> side effect is that processors going from RDF to JSON will randomly
> (AFAICT) select one or the other, making for trouble when non-LD processors
> encounter it.
>
> That is the direction I meant. Ie, we could have "tag" and "tagging" map
> on the same (RDF) predicate URL. Again, I do not really think we should do
> it, just flagging the possibility…
>
> Ivan
>
>
> >
> > So ... I would prefer we came to some single conclusion rather than
> sitting on the fence about naming :)
> >
> > Rob
> >
> >
> >
> > Ivan
> >
> >
> > >
> > >
> > >> Selector and selector seem
> > >> reasonable, especially as they'll be in different parts of the JSON --
> > >> selector will only ever be a key, and Selector will only ever be a
> value.
> > >
> > > I think this is an important distinction.
> > >
> > > I think we should differentiate them some other way, though, since it
> will be confusing to talk about 'selector' and people will get them mixed
> up. I don't have a suggestion, other than a slightly longer, more
> descriptive name for one of them.
> > >
> > >
> > >> This also occurs with oa:tagging and oa:Tag, they can't both be "tag".
> > >> For consistency, I would prefer "tagging" and "Tag" respectively.
> > >
> > > Makes sense.
> > >
> > > I have a mild preference for keeping the motivations shorter, but I
> can live their gerund form.
> > >
> > >
> > >> Made these notes in the wiki too, but as it's less about picking
> > >> individual terms and more guidelines for them, I thought I should post
> > >> here too.
> > >
> > > I think it makes sense to have the discussion here, too.
> > >
> > >> Thanks all!
> > >
> > > Thank you!
> > >
> > >
> > > Regards–
> > > –Doug
> > >
> > >
> > >
> > >>
> > >> Rob
> > >>
> > >>
> > >> On Mon, Jun 22, 2015 at 4:29 PM, Jacob Jett <jjett2@illinois.edu
> > >> <mailto:jjett2@illinois.edu>> wrote:
> > >>
> > >> Hi Doug,
> > >>
> > >> On Mon, Jun 22, 2015 at 5:17 PM, Doug Schepers <schepers@w3.org
> > >> <mailto:schepers@w3.org>> wrote:
> > >>
> > >> Hi, Jacob–
> > >>
> > >> On 6/22/15 4:50 PM, Jacob Jett wrote:
> > >>
> > >> Some quick thoughts. MIME types are usually the object for
> > >> dc:format
> > >> rather than dc:type. So a simple and relatively generic
> > >> label, like what
> > >> has been suggested for dataset, might work better, e.g.,
> > >> image, video,
> > >> etc. Then use MIME type for dc:format.
> > >>
> > >>
> > >> Seems plausible.
> > >>
> > >>
> > >> With regards to motivations, am I supposed to read them all
> > >> as verbs?
> > >> E.g., I bookmark the target; I link [to] the target; I
> > >> question the
> > >> target; etc. Is that correct? I ask because all but
> > >> identify, describe
> > >> and classify can be read as nouns.
> > >>
> > >>
> > >> I don't think it matters if you read them as verbs or nouns.
> > >>
> > >>
> > >> I was thinking that it may matter if I'm trying to indicate an
> > >> activity upon which some other activity should take place or a
> > >> document that is simply expressing some information.
> > >>
> > >> This was something of an issue of for XML. Ambiguous semantics are
> > >> the devil. Multiple readings are only efficient for (and
> exploitable
> > >> by) humans. Hence "classify" and "class" are very different kinds
> of
> > >> things. This can affect the overall interoperability of the json-ld
> > >> serializations.
> > >>
> > >> Regards,
> > >>
> > >> Jacob
> > >>
> > >>
> > >>
> > >>
> > >> _____________________________________________________
> > >> Jacob Jett
> > >> Research Assistant
> > >> Center for Informatics Research in Science and Scholarship
> > >> The Graduate School of Library and Information Science
> > >> University of Illinois at Urbana-Champaign
> > >> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> > >> (217) 244-2164 <tel:%28217%29%20244-2164>
> > >> jjett2@illinois.edu <mailto:jjett2@illinois.edu>
> > >>
> > >> As I mention earlier in this thread, that's a peculiar
> > >> convention to RDF that doesn't map well to other languages, and
> > >> sounds odd in most languages; I'd probably characterize most
> > >> procedural languages as using nouns in their terminology.
> > >>
> > >>
> > >> (With my linguistics undergrad hat on, I'll note that
> > >> contemporary American English usage tends to blur the lines
> > >> there anyway, with verbification of nouns and nonification of
> > >> verbs being very common right now, especially when creating
> > >> neologisms… e.g. the noun 'Google' becomes the verb 'to
> google',
> > >> though it's not limited to appropriation of proprietary
> eponyms.)
> > >>
> > >>
> > >> I think the goals include brevity, and flexibility for being
> > >> used as any given part of speech.
> > >>
> > >>
> > >> If there needs to be a RDF pattern for any of these, that can
> be
> > >> contained in the @context, right?
> > >>
> > >> Regards–
> > >> –Doug
> > >>
> > >>
> > >> _____________________________________________________
> > >> Jacob Jett
> > >> Research Assistant
> > >> Center for Informatics Research in Science and Scholarship
> > >> The Graduate School of Library and Information Science
> > >> University of Illinois at Urbana-Champaign
> > >> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> > >> (217) 244-2164 <tel:%28217%29%20244-2164>
> > >> jjett2@illinois.edu <mailto:jjett2@illinois.edu>
> > >> <mailto:jjett2@illinois.edu <mailto:jjett2@illinois.edu>>
> > >>
> > >> On Mon, Jun 22, 2015 at 4:41 PM, Doug Schepers
> > >> <schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>> wrote:
> > >>
> > >> Hey, folks–
> > >>
> > >> I started a wiki page [1] with some suggestions,
> > >> starting with
> > >> Rob's, then adding a few of my own. I'm not married to
> > >> any of this,
> > >> so feel free to edit the page (motivation:editing).
> > >>
> > >> If you have a suggestion for a term that already has
> an
> > >> entry in the
> > >> 'proposals' column, please add yours to the
> > >> 'alternates' column, and
> > >> any rationales in the 'notes' column. We can take that
> > >> as a starting
> > >> point for a conversation, and the WG's choice will be
> > >> moved into the
> > >> 'proposals' column.
> > >>
> > >> For example, under Provenance, Rob has suggested we
> replace
> > >> "oa:annotatedAt" with "date", while I suggest
> > >> "timestamp" or
> > >> "datetime"; I provide the rationale that "'datetime'
> is
> > >> the name of
> > >> the corresponding attribute in the HTML5 'time'
> element".
> > >>
> > >>
> > >> [1]
> https://www.w3.org/annotation/wiki/JSON_Vocabulary
> > >>
> > >> Regards–
> > >> –Doug
> > >>
> > >> On 6/22/15 3:56 PM, Robert Sanderson wrote:
> > >>
> > >>
> > >> Given our current context:
> > >> http://www.w3.org/TR/annotation-model/#json-ld-context
> > >>
> > >> I would suggest as a start:
> > >>
> > >> annotatedBy --> user
> > >> serializedBy --> generator // CF ATOM
> terminology:
> > >> https://tools.ietf.org/html/rfc4287#section-4.2.4
> > >> annotatedAt --> date
> > >> serializedAt --> ???
> > >>
> > >> It's already better than the CG's context, as we
> > >> dropped the direct
> > >> translation already for FPWD.
> > >>
> > >> Rob
> > >>
> > >> On Mon, Jun 22, 2015 at 2:34 PM, Frederick Hirsch
> > >> <w3c@fjhirsch.com <mailto:w3c@fjhirsch.com>
> > >> <mailto:w3c@fjhirsch.com <mailto:w3c@fjhirsch.com>>
> > >> <mailto:w3c@fjhirsch.com <mailto:w3c@fjhirsch.com
> >
> > >> <mailto:w3c@fjhirsch.com <mailto:w3c@fjhirsch.com>>>>
> wrote:
> > >> >
> > >> > Is there someone who could make a concrete
> > >> proposal for
> > >> revising the
> > >> JSON-LD keywords, specifically listing all the
> > >> changes? We could
> > >> then
> > >> use that as the basis for a brief
> discussion/agreement.
> > >> >
> > >> > Seems there is already rough agreement on the
> > >> list as well as a
> > >> rationale for making the change (Thanks Randall
> for
> > >> articulating
> > >> this)
> > >> >
> > >> > regards, Frederick
> > >> >
> > >> > Frederick Hirsch
> > >> > Co-Chair, W3C Web Annotation WG
> > >> >
> > >> > www.fjhirsch.com <http://www.fjhirsch.com>
> > >> <http://www.fjhirsch.com>
> > >> <http://www.fjhirsch.com>
> > >> > @fjhirsch
> > >> >
> > >> > > On Jun 18, 2015, at 11:51 AM, Robert
> Sanderson
> > >> <azaroth42@gmail.com <mailto:azaroth42@gmail.com>
> > >> <mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com>>
> > >> <mailto:azaroth42@gmail.com
> > >> <mailto:azaroth42@gmail.com> <mailto:azaroth42@gmail.com
> > >> <mailto:azaroth42@gmail.com>>>> wrote:
> > >> > >
> > >> > >
> > >> > > Yep, this is issue 12:
> > >> > >
> > >> > >
> https://github.com/w3c/web-annotation/issues/12
> > >> > >
> > >> > > Rob
> > >> > >
> > >> > > On Thu, Jun 18, 2015 at 8:42 AM, Chris Birk
> > >> <cmbirk@gmail.com <mailto:cmbirk@gmail.com>
> > >> <mailto:cmbirk@gmail.com <mailto:cmbirk@gmail.com>>
> > >> <mailto:cmbirk@gmail.com <mailto:cmbirk@gmail.com
> >
> > >> <mailto:cmbirk@gmail.com <mailto:cmbirk@gmail.com>>>>
> wrote:
> > >> > > +1 as well ( especially revisiting the
> > >> keywords ).
> > >> > >
> > >> > > I agree that the end value isn’t high for
> > >> most producers
> > >> from my
> > >> perspective, but including that information in the
> > >> HTTP return
> > >> header
> > >> should alleviate any issues there.
> > >> > >
> > >> > >
> > >> > >
> > >> > > - Chris
> > >> > > @cmbirk
> > >> > > (317) 418-9384 <tel:%28317%29%20418-9384>
> > >> <tel:%28317%29%20418-9384>
> > >> <tel:%28317%29%20418-9384>
> > >> > >
> > >> > >
> > >> > > On Thu, Jun 18, 2015 at 2:47 AM, Doug
> Schepers
> > >> <schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>>> wrote:
> > >> > >
> > >> > > Hey, folks–
> > >> > >
> > >> > > I agree with everything Randall said, and
> > >> I'll add this:
> > >> > >
> > >> > > The RDF convention around predicates (e.g.
> > >> hasX, isY,
> > >> ZedBy) is
> > >> intended
> > >> > > to impart a natural-language flow when
> > >> reading it, which I
> > >> respect. In
> > >> > > other languages and models, though, this
> violates
> > >> expectations, and
> > >> when
> > >> > > used in real natural language, keyword (even
> > >> RDF keywords)
> > >> are used as
> > >> > > different parts of speech, making it very
> > >> awkward to talk
> > >> about these
> > >> > > attributes.
> > >> > >
> > >> > > I'd very much like to revisit these
> keywords,
> > >> as Randall
> > >> suggests, and
> > >> > > design a @context that maps them to whatever
> > >> terms are
> > >> needed under the
> > >> > > hood.
> > >> > >
> > >> > > Regards–
> > >> > > –Doug
> > >> > >
> > >> > > On 6/18/15 2:01 AM, Randall Leeds wrote:
> > >> > > > See below for a response that I
> > >> accidentally sent only
> > >> to Ivan.
> > >> > > >
> > >> > > > ---------- Forwarded message ---------
> > >> > > > From: Randall Leeds <randall@bleeds.info
> > >> <mailto:randall@bleeds.info>
> > >> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info>>
> > >> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info>>>
> > >> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info>>
> > >> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info> <mailto:randall@bleeds.info
> > >> <mailto:randall@bleeds.info>>>>>
> > >> > > > Date: Wed, Jun 17, 2015 at 4:04 PM
> > >> > > > Subject: Re: JSON Serialization?
> > >> > > > To: Ivan Herman <ivan@w3.org
> > >> <mailto:ivan@w3.org> <mailto:ivan@w3.org <mailto:
> ivan@w3.org>>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>>>>
> > >> > > >
> > >> > > >
> > >> > > > On Wed, Jun 17, 2015 at 12:04 PM Ivan
> Herman
> > >> <ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>>
> > >> > > > <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>
> > >> <mailto:ivan@w3.org <mailto:ivan@w3.org>>>>> wrote:
> > >> > > >
> > >> > > >
> > >> > > > > On 17 Jun 2015, at 10:01 , Doug Schepers
> > >> <schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>>
> > >> > > > <mailto:schepers@w3.org
> > >> <mailto:schepers@w3.org> <mailto:schepers@w3.org
> > >> <mailto:schepers@w3.org>>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>
> > >> <mailto:schepers@w3.org <mailto:schepers@w3.org>>>>>
> wrote:
> > >> > > > >
> > >> > > >
> > >> > > > > A sticking point came up around JSON-LD;
> > >> I explained
> > >> to them (and
> > >> > > > I hope I'm correct) that the data model
> is very
> > >> lightweight, and
> > >> > > > that JSON-LD is not a big burden on top of
> > >> JSON, because
> > >> you don't
> > >> > > > need to include the context inline, so
> it's
> > >> just a
> > >> matter of using
> > >> > > > the same attribute names and structures.
> > >> > > >
> > >> > > > That is correct. If a client really wants,
> > >> it has the
> > >> possibility to
> > >> > > > a reference to @context in the HTTP return
> > >> header.
> > >> Pretty much
> > >> > > > invisible for anyone who does not need it.
> > >> > > >
> > >> > > > >
> > >> > > > > Even with the relatively small
> additional
> > >> overhead,
> > >> they were
> > >> > > > skeptical there is any benefit to JSON-LD
> > >> over plain
> > >> JSON; with a
> > >> > > > simple, small, well-defined vocabulary,
> > >> they didn't see
> > >> why it
> > >> > > > shouldn't simply be stand-alone. I wasn't
> > >> great at
> > >> selling the
> > >> > > > notion of "reasoning", since they aren't
> > >> using the Linked
> > >> > > > Data/SemWeb backend toolchains that would
> > >> enable that; maybe
> > >> > > > somebody else could explain it more
> > >> compellingly?
> > >> > > >
> > >> > > > My 2 cents:
> > >> > > >
> > >> > > > In my experience, reasoning as an argument
> > >> does not
> > >> really fly. In
> > >> > > > fact, only a few RDF systems do any kind
> of
> > >> reasoning in
> > >> the first
> > >> > > > place, and it does not scale over a
> certain
> > >> size anyway
> > >> (although
> > >> > > > those sizes are irrelevant for
> annotations).
> > >> > > >
> > >> > > > What JSON-LD buys us (at least in my view)
> > >> is its strong
> > >> connection
> > >> > > > to Linked Data. Ie, the annotation data
> can
> > >> be combined, if
> > >> > > > necessary, with data like the ones
> > >> represented by
> > >> dbpedia (ie, the
> > >> > > > whole of Wikipedia:-) or, these days, with
> > >> WikiData which is
> > >> > > > gradually becoming the underpinning of
> > >> Wikipedia.
> > >> DBpedia, though
> > >> > > > not prominent, is not the only example of
> > >> course, there
> > >> are tons of
> > >> > > > others. To take another example, it can
> use
> > >> the same
> > >> terms as the
> > >> > > > ones used in web sites for schema.org
> > >> <http://schema.org>
> > >> <http://schema.org> <http://schema.org>
> > >> <http://schema.org>:
> > >> > > > schema.org <http://schema.org>
> > >> <http://schema.org> <http://schema.org>
> > >> <http://schema.org> is, in
> > >>
> > >> reality, RDF, encoded in
> > >> > > > either microdata or RDFa Lite.
> > >> > > >
> > >> > > > Ie: if the annotation data is used in
> > >> strict isolation
> > >> from the rest
> > >> > > > of the world, then JSON-LD does not buy
> > >> anything. But if
> > >> a system
> > >> > > > wants to bind this data to the outside
> > >> world, it is a
> > >> different
> > >> > > > ballgame. (Ie, the important bit is 'LD',
> > >> not RDF)
> > >> > > >
> > >> > > >
> > >> > > > Agree with all of this. Thanks, Ivan.
> > >> > > >
> > >> > > > I still think the value proposition to
> > >> producers isn't
> > >> particularly
> > >> > > > strong, though. Intermediate consumers
> that
> > >> want to link
> > >> together
> > >> data
> > >> > > > from disparate sources derive value, but
> > >> the original
> > >> producers it's
> > >> > > > less clear.
> > >> > > >
> > >> > > >
> > >> > > > >
> > >> > > > > They also didn't react especially well
> to
> > >> some of the
> > >> attribute
> > >> > > > names, like annotatedBy, annotatedAt,
> > >> serializedBy,
> > >> serializedAt,
> > >> > > > which didn't seem intuitive or
> descriptive,
> > >> or to the
> > >> value prefixes
> > >> > > > (like "oa:"). I couldn't really explain
> why
> > >> some
> > >> attributes start
> > >> > > > with @, and some not. (Though on further
> > >> reading, maybe
> > >> the @
> > >> > > > represents a JSON-LD keyword [1]?)
> > >> > > >
> > >> > > > Finding the good attribute names that
> would
> > >> satisfy
> > >> everybody needs
> > >> > > > a white table and lots of drinks (if you
> are in
> > >> Amsterdam, you may
> > >> > > > want something else, too). Seriously: can
> > >> anyone imagine any
> > >> > > > attribute name that would be agreeable to
> > >> everybody? I
> > >> doubt. (Sorry
> > >> > > > to be sarcastic.)
> > >> > > >
> > >> > > >
> > >> > > > I disagree. I think simple attribute names
> > >> are really
> > >> easy to
> > >> agree on.
> > >> > > > Most people, when really challenged on it,
> > >> don't want to
> > >> bikeshed
> > >> > > > everything forever, in my opinion.
> > >> > > >
> > >> > > > However, I've never seen JSON in the wild
> > >> that is
> > >> anything like
> > >> what we
> > >> > > > have in our context document.
> > >> > > >
> > >> > > > As a developer, I would never choose
> > >> "hasTarget" over
> > >> "target". The
> > >> > > > "has" is implied by the nesting. When
> > >> working in JSON we
> > >> don't see
> > >> > > > independent triples, we see framed wholes.
> > >> The domain
> > >> model and the
> > >> > > > framing obviates these prepositions.
> > >> > > >
> > >> > > > Often, for simple vocabularies, it's
> > >> sufficient to use
> > >> the type
> > >> of the
> > >> > > > object range of the relationship as the
> key
> > >> because
> > >> there's only one
> > >> > > > meaningful relationship between the
> subject
> > >> and that
> > >> type of object.
> > >> > > >
> > >> > > > I've worked with JSON in dozens of domains
> > >> and I never see
> > >> anything like
> > >> > > > what we have.
> > >> > > >
> > >> > > > Seriously: this is not a JSON-LD issue. We
> > >> can choose
> > >> any names we
> > >> > > > want and we can agree on, that can be
> > >> mapped on the data
> > >> model terms
> > >> > > > through @context at our heart's content.
> > >> > > >
> > >> > > > As for '@': afaik, they are, sort of,
> > >> keywords. More
> > >> exactly: '@id'
> > >> > > > is, because it assigns an identification
> to
> > >> a resource.
> > >> AFAIK, one
> > >> > > > can use any attribute to 'type' (mapped
> > >> through the
> > >> context), the
> > >> > > > usage of '@type' is just a convention.
> > >> > > >
> > >> > > >
> > >> > > > Most keywords can be aliased, so this is
> > >> not a problem:
> > >> > > >
> http://www.w3.org/TR/json-ld/#aliasing-keywords
> > >> > > >
> > >> > > > I would suggest our default context use
> > >> "id" or "uri" or
> > >> anything
> > >> like
> > >> > > > this. When every single other key lacks a
> > >> "@" (in
> > >> absence of a
> > >> context
> > >> > > > document, or with it sent in a header
> link)
> > >> "@id" looks
> > >> mighty
> > >> strange
> > >> > > > and is not something I would expect anyone
> > >> to do otherwise.
> > >> > > >
> > >> > > > I am aware of a number of JSON APIs that
> > >> use a prefixing
> > >> scheme,
> > >> such as
> > >> > > > "@" or "_", to separate metadata and data,
> > >> but that
> > >> doesn't apply
> > >> here.
> > >> > > > It's all properties or relations of the
> > >> subject. None of
> > >> this is, for
> > >> > > > instance, protocal or storage "metadata"
> > >> "around" the, e.g.,
> > >> annotation.
> > >> > > >
> > >> > > >
> > >> > > > >
> > >> > > > > I wondered if maybe there might be a
> path
> > >> forward, by just
> > >> > > > defining a simplified JSON syntax that
> maps
> > >> directly to
> > >> the JSON-LD,
> > >> > > > but without the "data-typing" and URIs?
> > >> > > > >
> > >> > > > > I know that might seem like a really bad
> > >> idea, because
> > >> multiple
> > >> > > > syntaxes makes interop harder. I don't
> have
> > >> a good
> > >> answer for that.
> > >> > > > >
> > >> > > > > Can someone help me frame a description
> > >> or an argument
> > >> why this
> > >> > > > isn't a good idea?
> > >> > > > >
> > >> > > > > On the surface of it, it does have the
> > >> advantage that
> > >> it would be
> > >> > > > simpler to understand (and mildly simpler
> > >> to produce).
> > >> Would there
> > >> > > > be any other advantages?
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > I think we should take another pass at our
> > >> default
> > >> context with
> > >> an eye
> > >> > > > toward memorable, compact keys and a
> > >> default aliasing
> > >> for "@id".
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Rob Sanderson
> > >> > > Information Standards Advocate
> > >> > > Digital Library Systems and Services
> > >> > > Stanford, CA 94305
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Rob Sanderson
> > >> Information Standards Advocate
> > >> Digital Library Systems and Services
> > >> Stanford, CA 94305
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Rob Sanderson
> > >> Information Standards Advocate
> > >> Digital Library Systems and Services
> > >> Stanford, CA 94305
> > >
> >
> >
> > ----
> > Ivan Herman, W3C
> > Digital Publishing Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/0000-0003-0782-2704
> >
> >
> >
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>
Received on Tuesday, 23 June 2015 17:32:44 UTC