W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2014

RE: @container value enumeration

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 24 Apr 2014 16:00:00 +0200
To: "'Gregg Kellogg'" <gregg@greggkellogg.net>, "'Robert Sanderson'" <azaroth42@gmail.com>
Cc: "'Linked JSON'" <public-linked-json@w3.org>, "'Tom Johnson'" <johnson.tom@gmail.com>
Message-ID: <009501cf5fc5$7ca4b9c0$75ee2d40$@gmx.net>
On Thursday, April 24, 2014 12:08 AM, Gregg Kellogg wrote:
> On Apr 23, 2014, at 2:29 PM, Robert Sanderson wrote:
> > The @container property has an enumerated set of possible values
> > (@list, @set, @language, @index, null) where, in particular, @list
> > gets turned into an rdf:List.
> > 
> > There are several other ontologies that express an ordering in RDF,
> > such as the Ordered List Ontology (
> > http://smiy.sourceforge.net/olo/spec/orderedlistontology.html ) or
> > Resource List ( http://vocab.org/resourcelist/schema )
> > 
> > It was felt that it would be nice to be able to specify different ways
> > to parse/serialize the different list structures into JSON-LD.  This
> > would allow interoperability at the JSON level, without mandating a
> > particular ordered list construction in the RDF graph.

What does "interoperability at the JSON level mean"? That the JSON
representation looks the same? That's a very weak level of interoperability.


> > Our first thought was to put some identifier as the value of
> > @container, and have a specialized parser/serializer that recognized
> > other @containers and would generate the right syntax, other than
> > rdf:List (or JSON list from the triples).  However as the enumerated
> > @container ship has sailed, is there an alternative?   Could we,
> > perhaps, use @container:@list, and the some other field to give the
> > appropriate syntax to use for the list?

The question is what exactly you want to achieve. What should happen if the
data is being processed by JSON-LD processor that doesn't know of your
extensions? Should it fail with an error? Or should it just ignore your
extension and process the data as a normal rdf:List?

There's a straightforward to solution to both approaches. If you want other
processors to fail with an error, simply set @container to something else
(preferably a URL pointing to a description of your extension):

  "term": { "@id": "...", "@container": "http://example.com/OLOContainer" }

If you want other processors to ignore your extension, define your terms as
follows:

  "term": { "@id": "...", "@container": "@list",
"http://example.com/OLOContainer": true }

Processors that don't understand your http://example.com/OLOContainer
extension will silently ignore it and serialize the array to a rdf:List.


> OLO in particularly did come up in our discussions. What we failed to
> do was to provide an extension mechanism that would allow a particular
> document to say that it extends JSON-LD in some way so that a
> processor understanding this extension can operate property. There was

As outlined above, there are already multiple ways to achieve this. So I
wouldn't say we "failed" in that regard :-)


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 24 April 2014 14:00:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:41 UTC