W3C home > Mailing lists > Public > public-socialweb@w3.org > April 2015

Re: Proposal: de-namespace vcard in the normative AS2 JSON-LD context

From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
Date: Thu, 23 Apr 2015 17:10:10 +0200
Message-ID: <55390B52.8000901@wwelves.org>
To: James M Snell <jasnell@gmail.com>, "public-socialweb@w3.org" <public-socialweb@w3.org>
CC: Harry Halpin <hhalpin@w3.org>
Hi James,

On 04/22/2015 05:41 PM, James M Snell wrote:
> See: https://github.com/jasnell/w3c-socialwg-activitystreams/issues/102
> 
> ----
> 
> Currently, the normative JSON-LD context for Activity Streams 2.0
> includes a namespaced reference to vcard, allowing things like:
> 
> {
>   "@context": "http://www.w3.org/ns/activitystreams#",
>   "@type":  ["Person", "vcard:Individual"],
>   "vcard:fn": "Jane Jones"
> }
> 
> While this is helpful, the use of the namespace prefix is irritating.
> Given that there are currently no naming conflicts between AS2 and
> VCard terms, I would like to propose that we de-namespace the VCard
> terms within the AS2 normative context. That would mean allowing and
> implementer to do:
> 
> {
>   "@context": "http://www.w3.org/ns/activitystreams#",
>   "@type":  ["Person", "Individual"],
>   "fn": "Jane Jones"
> }

I see this question relevant to
ISSUE-36: Role and evolution of recommended JSON-LD contexts
-> https://www.w3.org/Social/track/issues/36

Also from my perspective *vcard:fn* makes it pretty self descriptive for
someone who knows vcard, for people who don't know it *fn* might make no
sense and give no hint where to look it up, not in
activitystreams-vocabulary for example.

While on that, I would see it interesting to continue discussion about
microformats.org if not also about FOAF and schema.org terms:
* vcard:n
* vcard:given-name
* vcard:family-name
* mf2:p-name
* mf2:p-given-name
* mf2:p-family-name
* schema:name
* schema:givenName
* schema:familyName
* foaf:name
* foaf:givenName
* foaf:familyName

What do you think about resolving this kind of dilemmas as part of IG
Vocabulary TF and focus in WG on clarifying general strategy for
recommended JSON-LD context?

Also if we can't use even minimalistic inference (ACTION-43) e.g. based
on RDFa Vocabulary Expansierties, we should discourage picking different
properties from different vocabularies for the same purpose. Instead
document equivalent properties from those we identified and recommend
which one to use. Possibly even mapping it in JSON-LD @context and
removing namespace prefix as you suggest here.

Cheers!
Received on Thursday, 23 April 2015 15:10:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 December 2016 15:48:21 UTC