Re: [VCARDDAV] [apps-discuss] iCalendar and vCard in JSON: WG draft charter

["Paul E. Jones" <[e-mail]>]

Markus,

While my opinion is just one, I personally don't see the point of adding
JSON-LD to the mix.  Use of JSON-LD just means there is another 50+ page
specification to go read and more work to ensure data is properly formatted.

Whether JSON-LD is used or not, the jCard spec would have to describe the
name/value pairs, arrays, or objects inside the JSON object specific to the
jCard.  Just using JSON the same example might be:

 {
   "FN": "John Doe",
   "ROLE": "Mr. Anonymous"
 }

The common underlying syntax is JSON and that's what all devices can parse.
JSON-LD seems like an unnecessary layer to me.

Paul

> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of Markus Lanthaler
> Sent: Wednesday, February 13, 2013 5:06 AM
> To: 'Barry Leiba'; 'Cyrus Daboo'
> Cc: 'IETF Apps Discuss'; [e-mail]; 'CardDAV'
> Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft
> charter
> 
> Even though I don't have any *major* objections I still wanted to raise
> some concerns about the consequences of such highly specialized formats,
> all similar but nevertheless not truly interoperable/compatible. As a
> developer you basically have to write specific code for each of those
> formats.
> 
> I was wondering if it was ever considered to use, e.g., something like
> JSON-LD [1] as the base for formats like these and limit the
> standardization to a shared vocabulary (i.e., URLs for the required
> properties) and a set of constraints and conventions captured in a
> profile (see [2] for details).
> 
> The advantage would be that much more code could be reused and data-
> integration would become much simpler. It might look complicated at
> first sight, but in reality most of what's needed is already there. For
> example, the work to define URLs for the various properties for both
> iCalendar [3] and vCard [4] has already been done at W3C (not as a REC
> though).
> 
> So, a simple vCard represented in JSON-LD would look as follows:
> 
> {
>   "@context": {
>     "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#"
>   },
>   "FN": "John Doe",
>   "ROLE": "Mr. Anonymous"
> }
> 
> You would have to define a number of constraints in the form of a
> profile if you also want clients that process this as JSON instead of
> JSON-LD to be able to interpret the data. The reason is that in JSON-LD
> you can serialize the exactly the same data in a number of different
> ways (e.g., you could use different field names that still expand to the
> same URLs; the context defines those mappings). JSON-only clients are
> less flexible and thus need to know the exact structure and field names.
> 
> The question I thus would like to ask is: Is there a compelling reason
> why this can't be based on a format as JSON-LD? Taking out the potential
> complexity by requiring a profile defining a number of constraints on
> how the data is serialized, I only see advantages of doing so.
> 
> 
> Cheers,
> Markus
> 
> 
> Disclaimer: I'm one of the authors of JSON-LD.
> 
> 
> [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become
> a W3C REC soon; it will enter last call by the end of the month) [2]
> http://tools.ietf.org/html/draft-wilde-profile-link
> [3] http://www.w3.org/TR/rdfcal/
> [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:apps-discuss-
> > [e-mail]] On Behalf Of Barry Leiba
> > Sent: Wednesday, February 13, 2013 1:03 AM
> > To: Cyrus Daboo
> > Cc: CardDAV; [e-mail]; IETF Apps Discuss
> > Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft
> > charter
> >
> > This is going to be Pete's working group, but let me add one thing to
> > what Cyrus said about the aggressive schedule and the "fast track":
> >
> > A while ago, we chartered the imapmove working group on a very fast
> > chartering schedule, and we're looking to do even more here.  The idea
> > that "it takes too long to create a working group" is something we
> > need to dispel.  In this case, we have an opportunity, with two
> > back-to-back IESG telechats a week apart, so we are looking for *this
> > Friday* (15 Feb) to put this on the telechat agenda for next week (21
> > Feb), and to have it get final approval on the 28th.  That's three
> > weeks from charter proposal to approval.
> >
> > That means that we need to hear any *major* objections to this now --
> > please have a look at this quickly and call out anything we've really
> > goofed on before Friday.  We then have until next Thursday (21st) to
> > get the details of the charter in shape for broad review.
> >
> > Barry, Applications AD
> >
> > On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo <[e-mail]> wrote:
> > > Hi folks,
> > > At the prompting of the Weirds WG there is a need to move more
> > quickly on
> > > developing specifications for JSON-based data formats for iCalendar
> > and
> > > vCard data, without necessarily waiting on other (proposed) JSON
> > working
> > > group work to proceed.
> > >
> > > A proposed charter for a "fast-track" Working Group is posted at
> > > <http://trac.tools.ietf.org/wg/appsawg/trac/wiki/jcardcal> for
> > feedback. The
> > > charter defines aggressive milestones and attempts to limit the
> > objectives
> > > such that those are achievable. Please review and post comments back
> > to the
> > > apps-discuss list.
> > >
> > > Whilst initial focus will be on the draft charter, some drafts have
> > already
> > > been published describing possible (different) approaches. One for
> > > iCalendar:
> > > <https://datatracker.ietf.org/doc/draft-kewisch-et-al-icalendar-in-
> > json/>,
> > > and one for vCard:
> > > <http://tools.ietf.org/id/draft-bhat-vcarddav-json-00.txt>. We also
> > hope to
> > > have an alternative jCard draft published in the next day or two
> > > that
> > uses
> > > the same approach as draft-kewisch-et-al-icalendar-in-json. These
> > should
> > > provide a good basis for initial input into the working group.
> > >
> > > --
> > > Cyrus Daboo
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss