- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Mon, 22 Jun 2015 17:24:56 -0500
- To: Jacob Jett <jjett2@illinois.edu>
- Cc: Doug Schepers <schepers@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>, Web Annotation <public-annotation@w3.org>
- Message-ID: <CABevsUGrfwjud2yqG7290H_L2B4F+bOsJNLbxtJxa=0rbyOPmg@mail.gmail.com>
I'm happy with timestamp (updated wiki page to that effect) 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". Unless case insensitivity is a goal, 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. This also occurs with oa:tagging and oa:Tag, they can't both be "tag". For consistency, I would prefer "tagging" and "Tag" respectively. 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. Thanks all! Rob On Mon, Jun 22, 2015 at 4:29 PM, Jacob Jett <jjett2@illinois.edu> wrote: > Hi Doug, > > On Mon, Jun 22, 2015 at 5:17 PM, Doug Schepers <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 > 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 >>> 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 >>> >>> >>> >>> >> > -- Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305
Received on Monday, 22 June 2015 22:25:26 UTC