I think the issue here is not whether any given instance of a resource has one type (therefore no array) or multiple types (therefore array). But (if I remember the conversations right) the concerns were that if done this way, all clients would have check to see if a property is an array or not every time when accessing the property.
So the general rule for a client is, if a property could be multi-valued, then to access it you MUST check to see if it is an array first, if not then access it as a single valued object, if it is an array then access each value through the array. Is anyone concerned that this might be a burdensome pattern for clients? <jim/> jim conallen CAM Lead Architect, OSLC AM Lead [email protected] Rational Software, IBM Software Group From: Olivier Berger <[email protected]> To: James Conallen/Philadelphia/IBM@IBMUS Cc: [email protected] Date: 01/18/2011 05:17 AM Subject: Re: [oslc-core] Multi-types resources in JSON representation Hi. Le vendredi 14 janvier 2011 à 15:00 -0500, James Conallen a écrit : > The guidance for JSON states that JSON representations should have a > type: > > > rdf:type A resource can have multiple types, so this is a JSON > Array of objects, each with an rdf:resource field that is a > type of the resource. > I'm not sure rdf:type should be any different than any other property of a resource. Thus, the rules in [0] : 1.0 For each property of a resource * 1.1 Add field to the resource's JSON object with name set to Prefixed Name of property o 1.1.1 If the property is specified as a single-valued property, then make field's value literal or JSON Object o 1.1.2 If the property is specified as a multi-valued property, then make field's value JSON Array would lead me to believe that unique rdf types should not be arrays and multiple ones should. [0] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON Any other opinions ? Best regards, -- Olivier BERGER <[email protected]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
