Re: JSON Serialization?

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.

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.

-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
jjett2@illinois.edu

On Mon, Jun 22, 2015 at 4:41 PM, Doug Schepers <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>> 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>
>>  > @fjhirsch
>>  >
>>  > > On Jun 18, 2015, at 11:51 AM, Robert Sanderson <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>> 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>
>>  > >
>>  > >
>>  > > On Thu, Jun 18, 2015 at 2:47 AM, Doug Schepers <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>>>
>>  > > > 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>>>
>>  > > >
>>  > > >
>>  > > > 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>>> 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>>> 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>:
>>  > > > 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
>>
>
>