- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 22 Jun 2015 23:04:01 -0400
- To: Robert Sanderson <azaroth42@gmail.com>, Jacob Jett <jjett2@illinois.edu>
- CC: Frederick Hirsch <w3c@fjhirsch.com>, Web Annotation <public-annotation@w3.org>
Hi, Rob– On 6/22/15 6:24 PM, Robert Sanderson wrote: > > I'm happy with timestamp (updated wiki page to that effect) I'd prefer 'datetime', since it matches the attribute on the HTML5 <time> element, which would be nice for the possible HTML serialization. > There does need to be a distinction between a few things though, in > particular there's a few collisions that need to be changed. > > For example, oa:Selector and oa:hasSelector can't both be "selector". True. > 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. > 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
Received on Tuesday, 23 June 2015 03:04:17 UTC