- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 22 Jun 2015 17:17:12 -0400
- To: Jacob Jett <jjett2@illinois.edu>
- CC: Robert Sanderson <azaroth42@gmail.com>, Frederick Hirsch <w3c@fjhirsch.com>, Web Annotation <public-annotation@w3.org>
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. 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 > 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>> 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>>> 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> > > @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>>> 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>>> 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> > > > > > > > > > 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>>> 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>>>> > > > > 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>>>> > > > > > > > > > > > > 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>>>> 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>>>> 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>: > > > > 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 > > >
Received on Monday, 22 June 2015 21:17:18 UTC