- From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Date: Thu, 23 Apr 2015 17:10:10 +0200
- 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