[oslc-core] Multi-types resources in JSON representation

[Olivier Berger]

Le mardi 18 janvier 2011 à 09:02 -0600, Andrew J Berner a écrit :
> 
> 
> James Conallen said:
> 
> > 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?
> 
> Why can't the spec be that properties that may be multi-valued are
> represented by an array, which could be an array of one element. 

I think turtle uses such "shortcuts" a lot also, and is far more
readable than XML/RDF in this respect.

I think the underlying principles of the RDF JSON format that has been
defined for OSLC (in the absence of an existing such standard to reuse),
was that it may be as "lightweight" as possible, much in the way turtle
does with plain text instead of JSON data structures (let aside that
cardinality of relations in RDF may be nonsense, as any property may be
multi-valued at any time, I think).

Of course, implementation wise, it could require more work from a
client, but it becomes much more "readable" to see "simple" objects than
arrays with a single element contained (singletons), at least for a
human brain which is used to such shortcuts.

In the above, I may of course be misinterpreting the intent of the
authors, as I wasn't involved in drafting such specs.

In the end, if one provider serves a "singleton" array for a single
valued property (even if that's not the recommended way to encode RDF in
JSON per OSLC Core), we should make sure that there's no semantic
ambiguity resulted. Would it be the case ?

My 2 cents,
-- 
Olivier BERGER <olivier.berger at it-sudparis.eu>
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)