Re: @container value enumeration

Hi Rob,

On Apr 23, 2014, at 2:29 PM, Robert Sanderson <azaroth42@gmail.com> wrote:

> 
> Dear all,
> 
> 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.
> 
> 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?

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 some discussion about doing this relative to CSV-LD. Some future design note could describe something like the following:

[[[
The processing model used for interpreting a JSON-LD document may be extended using the @extension keyword. This keyword, if used within the context, identifies one or more specifications defining the types of extensions permitted. Implementations not implementing this extension MUST signal an error (warning?) when encountering an extension.

For example:

{
  "@context": {
    "@vocab": "http://schema.org/",
    "@extension": "http://example/my-extension-spec",
    "term": {"@container": "@orderedListOntology"}
  }
  ...
}

An issue will be how different extensions can avoid stepping on each other, so we may want to consider a prefix mechanism, rather than re-using the @-space.

The range of @extension could be an absolute IRI or an array of absolute IRIs.

This is a useful point for discussion.

Gregg

> Many thanks for your consideration :)
> 
> Rob
> 
> -- 
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305