List-valued properties
RDF collections (aka lists) should also map into JSON arrays:
<http://example.com/r1> eg:prop ("foo" "bar" "baz") .becomes
{
"@" : "http://example.com/r1",
"prop" : [ "foo", "bar", "baz" ]
}This means that Lists do not round trip. There are various possible solutions to this.
Status: Agreed that this should be the mapping?
Proposed that the mapping object could record sufficient information to allow round tripping in easy cases but that is not agreed yet:
"properties" : [
{ "name" : "prop",
"uri" : "http://example.com/ont#prop",
"range" : "rdfs:List" }
]
This is an interesting one -- I hadn't actually got round to looking at lists for RDFj, but I would think we can do something better, by using an intermediate object.
The first possibility would be for the object to have a type and a list of members. This has the advantage that from a JSON stand-point, it's just a new object of type 'list', which would feel no different to an object of some other type, such as 'Person':
{ "@" : "http://example.com/r1", "prop" : { "a": "list", "members", "[ "foo", "bar", "baz" ] } }Of course, when it comes to serialising this back to RDF it is treated very differently to an ordinary object.
Another approach would be to go straight to the list, without the type:
{ "@" : "http://example.com/r1", "prop" : { "list", "[ "foo", "bar", "baz" ] } }Of course, 'members' could be used again, and this might imply a list, with or without the type.
Anyway, point is that there are lots of ways this could be done, which would ensure round-tripping.
Agreed there are lots of ways.
Jeni's comments on the original list discussion said she preferred the simple-array option rather than the intermediate-object option which is why I put that one down as "proposed".
I do think that for our use cases, properties which take lists values will typically always take list values and so round tripping using the context information to disambiguate would generally work.