RDF Working Group Wiki - User contributions [en]

TF-JSON

Nrixham — Mon, 04 Apr 2011 14:25:36 GMT

Nrixham: /* JSN3 */ cleanup to match spec

= JSON RDF Task Force =

The JSON RDF Task Force is primarily responsible for creating a JSON serialization of RDF.

== Sub-pages ==
* [[TF-JSON-UC|Use cases]]
* [[JSON User Segments]]
* [[TF-JSON/Semantics of JSON|Semantics of JSON]]

== Inputs ==

* ''[http://n2.talis.com/wiki/RDF_JSON_Specification RDF JSON]'', by Talis.
* ''[http://json-ld.org/ JSON-LD]'', by Manu Sporny.
* ''[http://decentralyze.com/2010/06/04/from-json-to-rdf-in-six-easy-steps-with-jron/ JRON]'' by Sandro Hawke.
* ''[http://code.google.com/p/linked-data-api/wiki/Specification JSON serialization]'' in the Linked Data API.
* ''[http://www.w3.org/TR/rdf-sparql-json-res/ SPARQL Query Results in JSON]'' by DAWG.
* ''[http://webr3.org/apps/specs/jsn3/ JSN3]'' by Nathan.
* ''[http://www.w3.org/2009/12/rdf-ws/papers/ws02 Flat triples approach to RDF graphs in JSON]'' by Dominik Tomaszuk
* ''[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#JSON Ideas and issues from the community ]'' from RDF Core Work Items build on RDF/NextStepWorkshop, are reproduced below.
* ''[http://www.w3.org/wiki/JTriples JTriples ]'' by Michael Hausenblas
* ''[http://code.google.com/p/backplanejs/wiki/Rdfj RDFj]'' by Mark Birbeck probably.

==== Materials from RDF Next Step WorkShop ====

=====Pros=====
* Allows web authors (Javascript, HTML5, ... developers) more easily use rdf data with existing tools and techniques
* Multiple JSON formats and implementations (some interoperable) already exist showing interest in this work
=====Cons=====
* Current JSON formats are not aligned - differnent approaches - making it JSON-user friendly versus making it familiar to existing RDF users.
* Needs some R&D and alignment.
* Risk that the result would be some standard that would not be adopted if it was not 'web author' friendly.

== Deliverables ==

* JSON Serialization of RDF

== Questions to Contemplate ==

# What are the use cases for the JSON serialization?
# Are we to create a lightweight JSON based RDF interchange format optimized for machines and speed, or an easy to work with JSON view of RDF optimized for humans (developers)?
# Is it necessary for developers to know RDF in order to use the simplest form of the RDF-in-JSON serialization?
# Should we attempt to support more than just RDF? Key-value pairs as well? Literals as subjects?
# Must RDF in JSON be 100% compatible with the JSON spec? Or must it only be able to be read by a JavaScript library and thus be JSON-like-but-not-compatible (and can thus deviate from the standard JSON spec)?
# Must all major RDF concepts be expressible via the RDF in JSON syntax?
# Should we go more for human-readability, or terse/compact/machine-friendly formats? What is the correct balance?
# Should there be a migration story for the JSON that is already used heavily on the Web? For example, in REST-based services?
# Should processing be a single-pass or multi-pass process? Should we support SAX-like streaming?
# Should there be support for [http://json-ld.org/spec/ED/20110201/#disjoint-graphs disjoint graphs]?
# Should we consider how the structure may be [http://payswarm.com/vocabs/signature#JsonldSignature digitally signed]?
# How should [http://json-ld.org/spec/ED/20110201/#the-normalization-algorithm normalization] occur?
# Should [http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/ graph literals] be supported?
# Should [http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/ named graphs] be supported?
# Should [http://json-ld.org/spec/ED/20110201/#automatic-typing automatic typing] be supported?
# Should [http://json-ld.org/spec/ED/20110201/#type-coercion type coercion] be supported?
# Should there be [http://json-ld.org/spec/ED/20110201/#the-json-ld-api an API] defined in order to easily map RDF-in-JSON to/from language-native formats?

== RDF in JSON Design Requirements ==

=== There should be two serialization formats ===

There should be a machine-friendly serialization format and there should be a human-friendly serialization format.

* -1 [[User:Msporny|Manu Sporny]], given the limited time for this working group, I think we should focus on the human-friendly serialization format. RDF already has a number of machine-friendly serialization formats.
* +1 [[User:Andy_Seaborne|Andy]]. A simple "s", "p", "o" format is not the same amount of work as a human-friendly form. See [http://www.w3.org/TR/rdf-sparql-json-res/ SPARQL JSON result format]
* 0 [[User:Lfeigenb|Lee]]. I'd worry about the WG's available time and resources.
* +1 [[User:Nrixham|Nathan]] if possible.
* -0 [[User:Mbrunati|Matteo Brunati]] not enough time maybe
* -0 [[User:Cmatheus|Chris Matheus]] not a priority
* -1 [[User:Tsteiner|Thomas Steiner]] Can we avoid this? One format to rule them all.
* 0 [[User:Nhumfrey|Nicholas Humfrey]] Ideally one would be a subset of the other.
* -0 [[User:Gcarothe3|Gavin Carothers]] There does not need to be a disconnect between human-friendly and machine-friendly for readability

=== A primary goal SHOULD be to build a human-friendly version of the serialization for JSON developers ===

The serialization should be optimized for humans first, machines second. The ability for machines to quickly parse the file is secondary to the ability for developers to be able to use the serialization with JavaScript. A focus should be placed on making the serialization fit into JavaScript frameworks easily, even at the cost of JSON-LD processor implementation complexity.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Lfeigenb|Lee]]. Given the existing work in the RDFa group on an API, I'd rather see a simple, machine-friendly format that implementations can then make available via an API. I'm not convinced that a standard human-friendly JSON format is a big win.
* -0 [[User:Andy_Seaborne|Andy]] Different uses cases lead to different design tradeoffs. (e.g [http://code.google.com/p/linked-data-api/ LDA] is a tree; ideal for them, bad for different uses.)
* +1 [[User:Nrixham|Nathan]] but only if the product can be considered simple JSON objects (k/v objects with a subject set) and the caveat is recognized that by not requiring an RDF toolkit or understanding of properties, inference etc, the data isn't really RDF... it's RDF-able - else -1, waste of time.
* +1 [[User:Mbrunati|Matteo Brunati]] +1 Nathan observations
* +1 [[User:Cmatheus|Chris Matheus]] extremely helpful for users new to RDF
* +1 [[User:Tsteiner|Thomas Steiner]] Yes, please! Make it easy for developers to write RDF in JSON.
* -1 [[User:Nhumfrey|Nicholas Humfrey]] I am more interested in machines. Turtle is good for Humans.
* -1 [[User:Gcarothe3|Gavin Carothers]] Large JSON objects are already VERY human unfriendly.

=== A primary goal SHOULD be to build a machine-optimized version of the serialization ===

The serialization should be optimized for machines first, humans second. The ability to use the serialization in JavaScript is secondary to the ability for machines to quickly parse the file. A focus should be placed on making implementations very easy to write.

* -1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Lfeigenb|Lee]]
* +1 [[User:Nrixham|Nathan]]
* +1 [[User:Mbrunati|Matteo Brunati]]
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] As stated before, I'd love to see one format to rule them all.
* +1 [[User:Nhumfrey|Nicholas Humfrey]]

=== The serialization SHOULD be able to transform most JSON in use today into RDF ===

There should be a flexible mechanism, such as a "context", that is capable of mapping from JSON key-value pairs to RDF triples. This mechanism could be specified either in-band or out-of-band from the serialization. Having this feature could map much of the existing JSON in the wild into RDF.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Lfeigenb|Lee]]. Seems out-of-scope; do existing RDF-in-JSON solutions already have such mechanisms?
* -1 [[User:Andy_Seaborne|Andy]] The original data was not written to be used in this way.
* +1 [[User:Nrixham|Nathan]] Assuming we're still talking two serializations, then this would be very valuable, for twitter to be able to say here's our data, view it as simple objects or rdf graphs; although I'm unsure we can get there without a common vision across the water.
* -1 [[User:Mbrunati|Matteo Brunati]] +1 to Andy, it's not in the original usage of the data
* -1 [[User:Cmatheus|Chris Matheus]] nice to have but should not consume this team's resources
* 0 [[User:Tsteiner|Thomas Steiner]] Time permitting, not a top priority IMHO.
* -1 [[User:Nhumfrey|Nicholas Humfrey]] too complex - and not worth standardising
* -1 [[User:Gcarothe3|Gavin Carothers]] JSON-RDF should be a syntax, not something like GRDDL.

=== Developers do not need to be familiar at all with RDF to start using the serialization ===

Understanding the semantic web and the concepts of RDF (triples, graphs, etc.) should not be required in order to use the format. That means that the format may have a very simple, stripped down version for beginners and a more advanced set of features for semantic web enthusiasts.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] only if two serializations, and as per previous comments.
* -1 [[User:Rcygania2|Richard Cyganiak]] I ''think'' I disagree. If you don't want to expose developers to RDF at all, then why not just use vanilla JSON? Also I don't understand how the beginner/advanced thing should work. A server will have to generate the one or the other, so it's not like client-side developers get to choose which version they want to be exposed to.
* -1 [[User:Mbrunati|Matteo Brunati]] I think a minimal semweb context is necessary: thinking on SIMILE Exhibit framework. It's not simple to use without a prior knowledge of the model.
* 0 [[User:Cmatheus|Chris Matheus]] some very basic knowledge may be important but deep knowledge should not be required
* -1 [[User:Tsteiner|Thomas Steiner]] People should at /least/ have an understanding of triples, that's enough for most use cases.
* 0 [[User:Nhumfrey|Nicholas Humfrey]] don't hide the triples
* -1 [[User:Gcarothe3|Gavin Carothers]] RDF-JSON should act as an introduction to RDF. Not as something you can use without knowing about RDF.

=== The serialization MAY include features not in RDF ===

There are certain features, such as generic key-value pairs in JSON that do not map well to RDF. They would map well if RDF had a concept of plain literals in the subject or predicate position. The serialization could include these concepts but may specify that the values may not be serialized to all RDF serialization formats (such as RDF/XML, TURTLE or RDFa).

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Andy_Seaborne|Andy]] creates an incompatible sub-community of applications.
* +1 [[User:Nrixham|Nathan]] useful for allowing "junk" data like debugging info and session tokens, again only if two serializations.
* -1 [[User:Rcygania2|Richard Cyganiak]] as per Andy. Generic key-value pairs can be translated to <tt><nowiki><> <#key> "value"</nowiki></tt> or somesuch.
* -1 [[User:Mbrunati|Matteo Brunati]] as for Andy. making a default rule to the generic key-value stuff
* -1 [[User:Cmatheus|Chris Matheus]] shouldn't spend time on this
* -1 [[User:Tsteiner|Thomas Steiner]] Strong no. Stay compatible with RDF by all means.
* -1 [[User:Nhumfrey|Nicholas Humfrey]]
* -1 [[User:Gcarothe3|Gavin Carothers]] A single JSON object should be able to contain JSON-RDF as a value. Which addresses Nathan's need.

=== The serialization MUST be 100% compatible with the JSON spec ===

Additional features such as comments or short-hand notation to support datatypes could be supported in the serialization if we extended the JSON format. This would mean that the serialization would be incompatible with vanilla JSON readers and writers. While this may make serialization nicer, we should not make any additions/modifications to the JSON format to ensure maximum compatibility with pre-existing processors.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Andy_Seaborne|Andy]]
* +1 [[User:Lfeigenb|Lee]]
* +1 [[User:Nrixham|Nathan]] else it's not JSON..
* +1 [[User:Mbrunati|Matteo Brunati]]
* +1 [[User:Cmatheus|Chris Matheus]]
* +1 [[User:Tsteiner|Thomas Steiner]] Strong yes!
* +1 [[User:Nhumfrey|Nicholas Humfrey]]
* +1 [[User:Gcarothe3|Gavin Carothers]]

=== It is a requirement that all RDF concepts MUST be expressible in the serialization ===

There are concepts like RDF datatypes and g-snaps/graph literals that could be omitted from the serialization in order to reduce learning and implementation complexity.

* -1 [[User:Msporny|Manu Sporny]], Good design is a balancing act - we should only include what will help the most number of people.
* +1 [[User:Lfeigenb|Lee]]. I'd hesitate to say "all", but in general, a JSON RDF serialization would not be useful to us unless it was as much a 1st-class serialization of the RDF model as turtle, RDF/XML, etc.
* +1 [[User:Andy_Seaborne|Andy]] for the machine-friendly form to work with non-JSON apps and systems.
* -1 [[User:Andy_Seaborne|Andy]] for the human-friendly form but the features dropped will vary from usage to usage.
* +1 [[User:Nrixham|Nathan]] for machine (rdf in json)
* -1 [[User:Nrixham|Nathan]] for human (rdf-able json objects)
* -1 [[User:Cmatheus|Chris Matheus]] not for this round
* +0.8 [[User:Mbrunati|Matteo Brunati]] probably yes, but not this time maybe, too complexity?
* -1 [[User:Tsteiner|Thomas Steiner]] Easy things should be easy and hard things should be possible. Keep the entry barrier low (inferred types), but allow the experts to do crazy things.
* +1 [[User:Nhumfrey|Nicholas Humfrey]] Definitely for the machine version of the spec.
* +1 [[User:Gcarothe3|Gavin Carothers]] Two serializations of the same abstract RDF should be the same.

=== There should be a migration story for going from existing JSON in the wild to this new format ===

The serialization task force should ensure that there is a subset of the serialization that is useful to beginners that use pure JSON, then show how developers could sprinkle in a little RDF into their JSON, then show how developers can fully migrate to the new serialization format. The transition to the serialization format will probably take multiple years The transition should be as smooth and organic as possible. We should also understand that many may not need to transition to RDF - JSON may work just fine for their application. We should not assume that people will go straight from regular JSON to the new serialization format.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] for human rdf-able json object serialization, if we can get there.
* +1 [[User:Mbrunati|Matteo Brunati]]
* -0 [[User:Cmatheus|Chris Matheus]] time permitting
* -0 [[User:Tsteiner|Thomas Steiner]] Time permitting
* 0 [[User:Nhumfrey|Nicholas Humfrey]] Not a priority
* -1 [[User:Gcarothe3|Gavin Carothers]] Key value pairs are not RDF. There is a leap to make.

=== Memory usage and CPU usage while processing SHOULD be a primary consideration ===

Memory and CPU usage for processing JSON is low. We should ensure that processing the serialization format is only slightly more complex than processing regular JSON.

* +0 [[User:Msporny|Manu Sporny]], we want to be cognizant of resource usage but I don't think this should be a primary driver for design decisions for the language.
* -1 [[User:Lfeigenb|Lee]]. Seems like an implementation detail to me.
* -1 [[User:Andy_Seaborne|Andy]] (NB: JSON structures are read entirely into memory before the application gets to see them.)
* +0.5 [[User:Nrixham|Nathan]] there is a balance between memory and processing to be struck, ntriples = more byte, turtle = more processing, same considerations for JSON.
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] IMHO if you need the ultimate performance, use, e.g., N-Triples, readability should have a higher priority, personally speaking.
* +1 [[User:Nhumfrey|Nicholas Humfrey]] It is important that it should be parsable as a stream (single pass)

=== The design target is small snippets of RDF Data ===

"small" might be less than 1 million triples, not 10.

* +1 [[User:Andy_Seaborne|Andy]]
* 0 [[User:Nrixham|Nathan]] two different considerations for machine or human, I'd say under 10k for human, over and beyond for machine
* +1 [[User:Tsteiner|Thomas Steiner]] For huge dumps use, e.g., N-Triples IMHO.
* 0 [[User:Nhumfrey|Nicholas Humfrey]]

=== Design target: graphs or resources ===

A human friendly JSON format can be designed more towards graphs (multiple subjects) or more targeted on just describing one resource (subject). This is not to exclude one possibility over the other - this is to decide the focus.

* graphs [[User:Andy_Seaborne|Andy]]
* machine: graphs, human: resource [[User:Nrixham|Nathan]]
* graphs [[User:Msporny|Manu Sporny]], but I don't think we'll need to choose between the two if we're smart about it. For instance, JSON-LD allows expressing graphs just as easily as expressing resources.
* graphs [[User:Cmatheus|Chris Matheus]]
* resources [[User:Tsteiner|Thomas Steiner]]
* resources [[User:Nhumfrey|Nicholas Humfrey]]

=== The serialization MUST support disjoint/unconnected graphs ===

All current RDF serialization formats allow you to express two graphs that are not necessarily connected to one another. The new serialization format should allow the same mechanism. This is also important because normalization is difficult to achieve in a general way without also supporting disjoint graphs in the serialization. JSON-LD [http://json-ld.org/spec/ED/20110201/#disjoint-graphs disjoint graphs example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Andy_Seaborne|Andy]] One graph with two+ disjoint components per serialization
* +0 [[User:Andy_Seaborne|Andy]] Multiple graphs per serialziation. No more than follow work in other TFs.
* +1 [[User:Nrixham|Nathan]] as per andy's comments
* +1 [[User:Cmatheus|Chris Matheus]]

=== The serialization MUST provide a normalization algorithm ===

Normalization, also known as canonicalization, is typically used when determining whether two sub-graphs that are expressed in different ways are identical. It is also very useful when hashing sub-graphs for checksumming or digital signature purposes. JSON-LD [http://json-ld.org/spec/ED/20110201/#the-normalization-algorithm normalization example].

* +1 [[User:Msporny|Manu Sporny]], I think we need normalization because we need to have a good digital signatures story
* ? [[User:Andy_Seaborne|Andy]]. Unclear - are we signing the graph or the serialization? Is a Turtle-signed graph the same graph? Would it include IRI normalization?
* +0 [[User:Nrixham|Nathan]]
* +0 [[User:Cmatheus|Chris Matheus]] highly desirable if there's time
* +1 [[User:Tsteiner|Thomas Steiner]] Time permitting

=== The serialization SHOULD enable digital signatures ===

Digital Signatures have a number of useful purposes. When combined with g-snaps/graph literals they provide a very easy way of establishing cryptographically verifiable provenance. These features are used heavily in electronic commerce. JSON-LD [http://payswarm.com/vocabs/signature#JsonldSignature digital signature example].

* +1 [[User:Msporny|Manu Sporny]]
* +0 [[User:Nrixham|Nathan]]
* 0 [[User:Rcygania2|Richard Cyganiak]] Nice to have but won't make or break the format.
* +0 [[User:Mbrunati|Matteo Brunati]]
* 0 [[User:Cmatheus|Chris Matheus]] nice to have
* +1 [[User:Tsteiner|Thomas Steiner]] Time permitting, not highest priority IMHO, though.
* 0 [[User:Nhumfrey|Nicholas Humfrey]]

=== The serialization SHOULD support advanced graph concepts ===

The serialization format should support advanced graph concepts such as g-box, g-snap and g-text such that you can make statements about snapshots of graphs. Annotating graphs with metadata such as graph retrieval time, digital signatures on the contents of the graph, and other metadata associated with graphs are an important feature for higher-level concepts like provenance. Sandro's explanation of [http://lists.w3.org/Archives/Public/public-rdf-wg/2011Feb/0092.html advanced graph concepts].

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Rcygania2|Richard Cyganiak]] Has security implications for RDF crawlers; requires larger API surface; SPARQL only returns single graphs anyways; use case is unclear
* -1 [[User:Andy_Seaborne|Andy]] Not unless the format is following standard work done in other TFs.
* +0.5 [[User:Nrixham|Nathan]] follow other TFs
* 0 [[User:Mbrunati|Matteo Brunati]] too problematic probably, +1 Richard notes
* -0 [[User:Cmatheus|Chris Matheus]] not this round unless the Graph TF results happens quickly and their incorporation is straight forawrd

=== The serialization MUST support automatic typing ===

Being able to transform a JSON document into a native object is one of the key benefits of using JSON over other serialization formats. Automatically typing of numbers and boolean values into language-native datatypes removes an extra step that developers must perform without this feature. For example, one could easily transform a serialized number that is an xsd:integer into a language-native integer. JSON-LD [http://json-ld.org/spec/ED/20110201/#automatic-typing automatic typing example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]]
* +1 [[User:Rcygania2|Richard Cyganiak]] I'd say it's what users expect.
* +1 [[User:Mbrunati|Matteo Brunati]]
* +1 [[User:Cmatheus|Chris Matheus]]
* +1 [[User:Tsteiner|Thomas Steiner]] Strong yes. This is what the JavaScript community would expect I think.
* +1 [[User:Nhumfrey|Nicholas Humfrey]]

=== The serialization SHOULD support type coercion ===

While not immediately obvious, type coercion allows one to map regular JSON into RDF in a way that may add datatype decorators to object literals. In other words, it provides for a way to get Typed Literals from regular JSON data. JSON-LD [http://json-ld.org/spec/ED/20110201/#type-coercion type coercion example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] for human one, -1 for machine one
* +1 [[User:Tsteiner|Thomas Steiner]] Yes, as this is what people (IMHO) expect, and it keeps the entry barrier low. Still allow for overriding.
* +1 [[User:Nhumfrey|Nicholas Humfrey]]

=== The serialization SHOULD rely on microsyntaxes instead of nested structures ===

There are two common approaches to expressing RDF in JSON. One of them is to use nested structures to express language and type information for literals. The other approach is to use shallow structures with microsyntaxes mirroring TURTLE to express language and type information for literals.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Rcygania2|Richard Cyganiak]] It's ugly as hell and makes the language unusable without an API
* -1 [[User:Nrixham|Nathan]]
* -1 [[User:Mbrunati|Matteo Brunati]]
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] Microsyntaxes are easy to get wrong. Nested structures occupy more memory and require two object accesses on read/write, however, with default/inferred types, this could be OK.
* +1 [[User:Nhumfrey|Nicholas Humfrey]] It depends on how complex the micro-syntax is. I like the idea of making the JSON less verbose (for humans)

=== The serialization SHOULD provide an API ===

An API would allow developers to transform incoming documents into a format that is easier for them to work with. In other words, it would allow them to drop all type information if it wasn't useful to them, or remove any micro-syntaxes that would get in the way of basic usage of the data. Keep in mind that even JSON has an api: JSON.parse(). JSON-LD [http://json-ld.org/spec/ED/20110201/#the-json-ld-api API example].

(?? Reword as: The serialization SHOULD assume working with a JavaScript RDF API ([[User:Andy_Seaborne|Andy]]))

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Nrixham|Nathan]] the machine one will have the RDF API, the human one is pointless if it needs and API.
* +1 [[User:Mbrunati|Matteo Brunati]] as Andy said, working with an API ( are there other WG are working on that or not? )
* -1 [[User:Cmatheus|Chris Matheus]] not this round
* -1 [[User:Tsteiner|Thomas Steiner]] The JSON is the API, we just need to make it easy enough.
* 0 [[User:Nhumfrey|Nicholas Humfrey]] Nice to have - but should not be required

=== There SHOULD be one and only one way to serialize a given triple ===

The more different ways there are to express the same triple or graph, the harder it gets to use the host language's native toolbox (that is, pure JS expressions) to process data. At some point, using the host language becomes impossible without using a parser library layered on top of the host language, negating the benefit of basing the language on JSON in the first place. (Note, this is about using different JSON structures to express the same triple; not about different triples expressing the same statement in RDF Semantics, like <tt>"foo"</tt> vs <tt>"foo"^^xsd:string</tt>).

* +1 [[User:Rcygania2|Richard Cyganiak]] This is the lesson to be learnt from RDF/XML.
* +0 [[User:Msporny|Manu Sporny]], while I agree in principle I don't know how we'd enforce this in practice - that is, what's the difference between "foo" and "foo"^^xsd:string in JSON? Would you serialize the plain literal "foo" and the Typed Literal "foo"^^xsd:string in the same way in JSON? If the answer is yes, isn't the translation lossy?
** This one is inherent to the way the RDF model is defined. There's nothing that can be done about it in the syntax. The concern here was about using different JSON structures to express the same triple. I clarified the description.
* +1 [[User:Mbrunati|Matteo Brunati]] as for Richard, RDF/XML is the lesson
* ++1 [[User:Cmatheus|Chris Matheus]]
* +0 [[User:Tsteiner|Thomas Steiner]] Can it be done? How about 1.0 double vs 1.0 float? Compare, e.g., QUnit's equality tests (jQuery unit test framework): deepEqual (http://docs.jquery.com/QUnit/deepEqual#actualexpectedmessage) vs. strictEqual (http://docs.jquery.com/QUnit/strictEqual#actualexpectedmessage) vs. equal (http://docs.jquery.com/QUnit/equal#actualexpectedmessage)
* 0 [[User:Nhumfrey|Nicholas Humfrey]] Desirable

== JSON Serializations By Example ==

=== Sample Graphs ===

'''Basic Example'''

<pre>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://example/> .

<http://jondoe.example.org/#me> a foaf:Person ;
foaf:nick "Jonny" ;
foaf:givenname "Jon" ;
foaf:family_name "Doe" ;
foaf:depiction <http://jondoe.example.org/me.jpg> ;
foaf:homepage <http://jondoe.example.org/> ;
foaf:interest <http://dbpedia.org/resource/Film> ;
foaf:knows <http://janedoe.example.org/#me> ;
foaf:knows [ foaf:name "John Smith" ] .

<http://janedoe.example.org/#me> a foaf:Person ;
foaf:name "Jane Doe" .

:book1
dc:creator <http://jondoe.example.org/#me> ;
dc:contributor ( <http://janedoe.example.org/#me> [ foaf:name "John Smith" ] ) ;
dc:date "2011"^^xsd:gYear ;
dc:title "Swansea" ;
dc:subject <http://en.wikipedia.org/wiki/Swansea> .

<http://en.wikipedia.org/wiki/Swansea>
dc:date "2011-03-23"^^xsd:date ;
rdfs:label "Swansea"@en , "Abertawe"@cy .
</pre>

'''Advanced Example''' (based on this [http://www.ebusiness-unibw.org/wiki/Rdfa4google#Opening_Hours_in_Tabular_Form GoodRelations example])

<pre>
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://business.example.org/openinghours.html#business> a gr:BusinessEntity ;
rdfs:label "Example Business, Inc."@en ;
gr:hasPOS <http://business.example.org/openinghours.html#shop> ;
gr:legalName "Example Business, Inc."@en ;
foaf:page <http://business.example.com>, <http://business.example.org/openinghours.html> ;
vcard:fn "Example Business, Inc."@en ;
vcard:geo
[ vcard:latitude "49.0202626"^^xsd:float ;
vcard:longitude "12.8407428"^^xsd:float
] ;
vcard:tel "+49-12-3546789"^^xsd:string ;
vcard:url <http://business.example.com> .

<http://business.example.org/openinghours.html#shop> a gr:LocationOfSalesOrServiceProvisioning ;
gr:hasOpeningHoursSpecification
<http://business.example.org/openinghours.html#mon>,
<http://business.example.org/openinghours.html#tue>,
<http://business.example.org/openinghours.html#wed>,
<http://business.example.org/openinghours.html#thu>,
<http://business.example.org/openinghours.html#fri>,
<http://business.example.org/openinghours.html#sat>.

<http://business.example.org/openinghours.html#mon> a gr:OpeningHoursSpecification ;
gr:closes "18:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Monday ;
gr:opens "08:00:00"^^xsd:time .

<http://business.example.org/openinghours.html#tue> a gr:OpeningHoursSpecification ;
gr:closes "18:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Tuesday ;
gr:opens "08:00:00"^^xsd:time .

<http://business.example.org/openinghours.html#wed> a gr:OpeningHoursSpecification ;
gr:closes "14:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Wednesday ;
gr:opens "08:00:00"^^xsd:time .

<http://business.example.org/openinghours.html#thu> a gr:OpeningHoursSpecification ;
gr:closes "18:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Thursdays ;
gr:opens "08:00:00"^^xsd:time .

<http://business.example.org/openinghours.html#fri> a gr:OpeningHoursSpecification ;
gr:closes "20:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Friday ;
gr:opens "08:00:00"^^xsd:time .

<http://business.example.org/openinghours.html#sat> a gr:OpeningHoursSpecification ;
gr:closes "15:00:00"^^xsd:time ;
gr:hasOpeningHoursDayOfWeek gr:Saturday ;
gr:opens "09:00:00"^^xsd:time .
</pre>

Artificial data which cover many cases and many Turtle shortcuts:
<pre>
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://example/> .

:x1 :p1 1 ;
:p2 1.0 ;
:p3 1.0e0 ;
:p4 () ;
:p5 (1 2 "three" ) ;
:p6 [ :q 57 ; :q 89 ] ;
:p7 _:a .

_:a :p1 :z ;
:p2 "str" ;
:p3 "str"^^xsd:string .

[] :p :z .

:z rdfs:label "Swansea"@en , "Abertawe"@cy ;
:q1 "2011-03-23T13:40:22.489+00:00"^^xsd:dateTime ;
:q2 "2011-03-23Z"^^xsd:date ;
:q3 "2011-03-23"^^xsd:date ;
:q4 "2011+01:00"^^xsd:gYear ;
:q5 "2011"^^xsd:gYear .

("a" "b" "c" ) :p [ :p (1 2) , (3 4) ] .

[ :p (1 2) , (3 4) ] :p ("a" "b" "c" ) .
</pre>
and some short forms that are not legal Turtle, but represent legal RDF triples. They are SPARQL.
<pre>
("a" "b" "c" ) .

[ :p (1 2) , (3 4) ] .
</pre>

== JSON Serializations Lineup ==

=== Shared Example for Serialization Lineup (Turtle) ===

<pre>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix iCollide: <http://example.org/icollide#> .
@prefix : <http://example/> .

<http://jondoe.example.org/#me> a foaf:Person ;
foaf:name "Jon" ;
iCollide:name "Jon" ;
foaf:depiction <http://jondoe.example.org/me.jpg> ;
foaf:knows ( <http://janedoe.example.org/#me> [ foaf:name "John Smith" ] ) ;
foaf:birthday "2010-03-23T13:40:22.489+00:00"^^xsd:dateTime ;
foaf:age 1 ;
foaf:description "Just another Jon Doe"@en, "Justement un autre Jon Doe"@fr ;
vcard:geo [
vcard:latitude "49.0202626"^^xsd:float ;
vcard:longitude "12.8407428"^^xsd:float
] ;
vcard:tel "+49-12-3546789"^^xsd:string .

<http://janedoe.example.org/#me> a foaf:Person .
</pre>

'''Remarks''': We tried to compile a worst case real-world scenario of things that could potentially appear in Turtle, namely:
* literals
* literals with language tags
* literals with trivial data types
* literals with non-trivial data types
* blank nodes
* lists
* IRIs
* potentially colliding CURIE prefixes

=== Linked Data API ===

<pre>
{
"format": "linked-data-api",
"version": "0.2",
"result": {
"_about": "http://jondoe.example.org/#me",
"type": "http://xmlns.com/foaf/0.1/Person",
"foaf_name": "Jon",
"iCollide_name": "Jon",
"depiction": "http://jondoe.example.org/me.jpg",
"knows": [
"http://janedoe.example.org/#me",
"_:b0"
],
"birthday": "Tue Mar 23 2010 14:40:22 GMT+0100 (CET)",
"age": 1,
"description": [
"Just another Jon Doe@en",
"Justement un autre Jon Doe@fr"
],
"geo": {
"format": "linked-data-api",
"version": "0.2",
"result": {
"latitude": "49.0202626^^xsd:float",
"longitude": "12.8407428^^xsd:float"
}
},
"tel": "+49-12-3546789^^xsd:string"
}
}

{
"format": "linked-data-api",
"version": "0.2",
"result": {
"_about": "http://janedoe.example.org/#me",
"type": "http://xmlns.com/foaf/0.1/Person"
}
}

{
"format": "linked-data-api",
"version": "0.2",
"result": {
"_id": "_:b0",
"name": "John Smith"
}
}
</pre>

'''Remarks''':
* Linked Data API boilerplate at the beginning
* No concept of namespaces whatsoever (lossy RDF)
* Microsyntax for language tags
* Microsyntax for types
* Microsyntax for subject (_about)

=== JRON ===

<pre>
{
"__prefixes": {
"foaf_": "http://xmlns.com/foaf/0.1/",
"xsd_": "http://www.w3.org/2001/XMLSchema#",
"vcard_": "http://www.w3.org/2006/vcard/ns#",
"rdfs_": "http://www.w3.org/2000/01/rdf-schema#",
"iCollide_": "http://example.org/icollide#"
},
"__iri": "http://jondoe.example.org/#me",
"rdfs_type": "http://xmlns.com/foaf/0.1/Person",
"foaf_name": "Jon",
"iCollide_name": "Jon",
"foaf_depiction": "http://jondoe.example.org/me.jpg",
"foaf_knows": {
"__values": [
{
"__iri": "http://janedoe.example.org/#me"
},
{
"__node_id": "_:b0"
}
]
},
"foaf_birthday": {
"__repr": "2010-03-23T13:40:22.489+00:00",
"__type": "http://www.w3.org/2001/XMLSchema#dateTime"
},
"foaf_age": 1,
"foaf_description": [
{
"__text": "Just another Jon Doe",
"__lang": "en"
},
{
"__text": "Justement un autre Jon Doe",
"__lang": "fr"
}
],
"vcard_geo": {
"__prefixes": {
"vcard_": "http://www.w3.org/2006/vcard/ns#"
},
"vcard_latitude": {
"__repr": "49.0202626",
"__type": "http://www.w3.org/2001/XMLSchema#float"
},
"vcard_longitude": {
"__repr": "12.8407428",
"__type": "http://www.w3.org/2001/XMLSchema#float"
}
},
"vcard_tel": {
"__repr": "+49-12-3546789",
"__type": "http://www.w3.org/2001/XMLSchema#string"
}
}

{
"__prefixes": {
"rdfs_": "http://www.w3.org/2000/01/rdf-schema#"
},
"__iri": "http://janedoe.example.org/#me",
"rdfs_type": "http://xmlns.com/foaf/0.1/Person"
}

{
"__prefixes": {
"foaf_": "http://xmlns.com/foaf/0.1/"
},
"__node_id": "_:b0",
"foaf_name": "John Smith"
}
</pre>

'''Remarks''':
* Concept of namespaces in __prefixes section
* Microsyntax for subject (__iri, __node_id)
* Paired values for data types
* Paired values for language tags

=== JSN3 ===

<pre>
{
"@prefix": {
"foaf:": "http://xmlns.com/foaf/0.1/",
"xsd:": "http://www.w3.org/2001/XMLSchema#",
"vcard:": "http://www.w3.org/2006/vcard/ns#",
"rdfs:": "http://www.w3.org/2000/01/rdf-schema#",
"iCollide:": "http://example.org/icollide#"
":": "http://example/"
},
"http://jondoe.example.org/#me": {
"a": "foaf:Person",
"foaf:name": "Jon",
"iCollide:name": "Jon",
"foaf:depiction": "http://jondoe.example.org/me.jpg",
"foaf:knows": [[
"http://janedoe.example.org/#me",
{"foaf:name": "John Smith"}
]],
"foaf:birthday": {
"^^xsd:dateTime": "2010-03-23T13:40:22.489+00:00"
},
"foaf:age": 1,
"foaf:description": [
{
"@en": "Just another Jon Doe"
},
{
"@fr": "Justement un autre Jon Doe"
}
],
"vcard:geo": {
"vcard:latitude": {
"xsd:float": "49.0202626"
},
"vcard:longitude": {
"xsd:float": "12.8407428"
}
},
"vcard:tel": {
"xsd:string": "+49-12-3546789"
}
},
"http://janedoe.example.org/#me": {
"a": "foaf:Person"
}
}

</pre>

'''Remarks''':
* Concept of namespaces and base
* Subject is an object key
* Data type arcs for data types
* Language tag arcs for language tags

=== JSON-LD ===

<pre>
{
"#": {
"#base": "http://example/",
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"vcard": "http://www.w3.org/2006/vcard/ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"iCollide": "http://example.org/icollide#"
},
"@": "http://jondoe.example.org/#me",
"a": "foaf:Person",
"foaf:name": "Jon",
"iCollide:name": "Jon",
"foaf:depiction": "<http://jondoe.example.org/me.jpg>",
"foaf:knows": [
"<http://janedoe.example.org/#me>",
"_:b0"
],
"foaf:birthday": "2010-03-23T13:40:22.489+00:00^^xsd:dateTime",
"foaf:age": 1,
"foaf:description": [
"Just another Jon Doe@en",
"Justement un autre Jon Doe@fr"
],
"vcard:geo": {
"#": {
"#base": "http://example/",
"vcard": "http://www.w3.org/2006/vcard/ns#"
},
"vcard:latitude": "49.0202626^^xsd:float",
"vcard:longitude": "12.8407428^^xsd:float"
},
"vcard:tel": "+49-12-3546789^^xsd:string"
}

{
"@": "http://janedoe.example.org/#me",
"a": "foaf:Person"
}

{
"#": {
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@": "_:b0",
"foaf:name": "John Smith"
}
</pre>

'''Remarks''':
* Concept of namespaces and base
* Microsyntax for subject (@)
* Microsyntax for language tags
* Microsyntax for data types

=== JTriples ===

<pre>
[
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://www.w3.org/2000/01/rdf-schema#type>",
"o": "<http://xmlns.com/foaf/0.1/Person>"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/name>",
"o": "Jon"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://example.org/icollide#name>",
"o": "Jon"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/depiction>",
"o": "<http://jondoe.example.org/me.jpg>"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/knows>",
"o": "<http://janedoe.example.org/#me>"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/knows>",
"o": "_:b0"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/birthday>",
"o": "\"2010-03-23T13:40:22.489+00:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/age>",
"o": 1
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/description>",
"o": "\"Just another Jon Doe\"@en"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://xmlns.com/foaf/0.1/description>",
"o": "\"Justement un autre Jon Doe\"@fr"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://www.w3.org/2006/vcard/ns#geo>",
"o": "_:b1"
},
{
"s": "<http://jondoe.example.org/#me>",
"p": "<http://www.w3.org/2006/vcard/ns#tel>",
"o": "\"+49-12-3546789\"^^http://www.w3.org/2001/XMLSchema#string>"
},

{
"s": "_:b0",
"p": "<http://xmlns.com/foaf/0.1/name>",
"o": "John Smith"
},

{
"s": "_:b1",
"p": "<http://www.w3.org/2006/vcard/ns#latitude>",
"o": "\"49.0202626\"^^<http://www.w3.org/2001/XMLSchema#float>"
},
{
"s": "_:b1",
"p": "<http://www.w3.org/2006/vcard/ns#longitude>",
"o": "\"12.8407428\"^^<http://www.w3.org/2001/XMLSchema#float>"
},

{
"s": "<http://janedoe.example.org/#me>",
"p": "<http://www.w3.org/2000/01/rdf-schema#type>",
"o": "<http://xmlns.com/foaf/0.1/Person>"
}
]
</pre>

'''Remarks''':
* No concept of namespaces
* Microsyntax for language tags (with escaped quotes (\"))
* Microsyntax for data types (with escaped quotes (\"))

=== RDF/JSON ===

<pre>
{
"http://jondoe.example.org/#me": {
"http://www.w3.org/2000/01/rdf-schema#type": [
{
"value": "http://xmlns.com/foaf/0.1/Person",
"type": "uri"
}
],
"http://xmlns.com/foaf/0.1/name": [
{
"value": "Jon",
"type": "literal"
}
],
"http://example.org/icollide#name": [
{
"value": "Jon",
"type": "literal"
}
],
"http://xmlns.com/foaf/0.1/depiction": [
{
"value": "http://jondoe.example.org/me.jpg",
"type": "uri"
}
],
"http://xmlns.com/foaf/0.1/knows": [
{
"value": "http://janedoe.example.org/#me",
"type": "uri"
},
{
"value": "_:b0",
"type": "_bnode"
}
],
"http://xmlns.com/foaf/0.1/birthday": [
{
"value": "2010-03-23T13:40:22.489+00:00",
"type": "literal",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
}
],
"http://xmlns.com/foaf/0.1/age": [
{
"value": 1,
"type": "literal"
}
],
"http://xmlns.com/foaf/0.1/description": [
{
"value": "Just another Jon Doe",
"type": "literal",
"lang": "en"
},
{
"value": "Justement un autre Jon Doe",
"type": "literal",
"lang": "fr"
}
],
"http://www.w3.org/2006/vcard/ns#geo": [
{
"value": "_:b1",
"type": "bnode"
}
],
"http://www.w3.org/2006/vcard/ns#tel": [
{
"value": "+49-12-3546789",
"type": "literal",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
}
]
}
}

{
"http://janedoe.example.org/#me": {
"http://www.w3.org/2000/01/rdf-schema#type": [
{
"value": "http://xmlns.com/foaf/0.1/Person",
"type": "uri"
}
]
}
}

{
"_:b0": {
"http://xmlns.com/foaf/0.1/name": [
{
"value": "John Smith",
"type": "literal"
}
]
}

{
"_:b1": {
"http://www.w3.org/2006/vcard/ns#latitude": [
{
"value": "49.0202626",
"type": "literal",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime#float"
}
],
"http://www.w3.org/2006/vcard/ns#longitude": [
{
"value": "12.8407428",
"type": "literal",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime#float"
}
]
}
}
</pre>

'''Remarks''':
* No concept of namespaces, full IRIs as object keys
* Paired values for language tags
* Paired values for data types
* Subject as object key

=== RDFj ===

<pre>
{
"context": {
"base": "<http://example/>",
"token": {
"name": "http://xmlns.com/foaf/0.1/name",
"depiction": "http://xmlns.com/foaf/0.1/depiction",
"knows": "http://xmlns.com/foaf/0.1/knows",
"birthday": "http://xmlns.com/foaf/0.1/birthday",
"age": "http://xmlns.com/foaf/0.1/age",
"description": "http://xmlns.com/foaf/0.1/description",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"geo": "http://www.w3.org/2006/vcard/ns#geo",
"tel": "http://www.w3.org/2006/vcard/ns#tel",
"nameICollide": "http://example.org/icollide#name"
}
},
"$" :"&<http://jondoe.example.org/#me>",
"a": "foaf:Person",
"name": "Jon",
"nameICollide": "Jon",
"depiction": "<http://jondoe.example.org/me.jpg>",
"knows": [
"<http://janedoe.example.org/#me>",
"<bnode:b0>"
],
"birthday": "2010-03-23T13:40:22.489+00:00^^http://www.w3.org/2001/XMLSchema#dateTime",
"age": 1,
"description": [
"Just another Jon Doe@en",
"Justement un autre Jon Doe@fr"
],
"geo": {
"latitude": {
"context": {
"base": "<http://example/>",
"token": {
"latitude": "http://www.w3.org/2006/vcard/ns#latitude",
"longitude": "http://www.w3.org/2006/vcard/ns#longitude"
}
},
"$": "<>",
"latitude": "49.0202626^^http://www.w3.org/2001/XMLSchema#float",
"longitude": "12.8407428^^http://www.w3.org/2001/XMLSchema#float"
}
},
"tel": "+49-12-3546789^^http://www.w3.org/2001/XMLSchema#string"
}

{
"$": "http://janedoe.example.org/#me",
"a": "foaf:Person"
}

{
"context": {
"name": "http://xmlns.com/foaf/0.1/name"
},
"$": "bnode:b0",
"name": "John Smith"
}
</pre>

'''Remarks''':
* Concept of namespaces and base in form of namespaced tokens
* Microsyntax for language tags
* Microsyntax for data types
* Microsyntax for subject ($)

=== SPARQL Query Results in JSON ===

<pre>
{
"head": {
"vars": [
"name",
"depiction",
"knows",
"birthday",
"age",
"description",
"xsd",
"geo",
"tel",
"nameICollide"
]
},
"results": {
"bindings": [
{
"name": {
"type": "literal",
"value": "Jon"
},
"nameICollide": {
"type": "literal",
"value": "Jon"
},
"depiction": {
"type": "uri",
"value": "http://jondoe.example.org/me.jpg"
},
"knows": {
"type": "uri",
"value": "http://janedoe.example.org/#me"
},
"knows": {
"type": "bnode",
"value": "b1"
},
"birthday": {
"type": "typed-literal",
"value": "2010-03-23T13:40:22.489+00:00",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
},
"age": {
"type": "literal",
"value": 1
},
"description": {
"type": "literal",
"value": "Just another Jon Doe",
"xml:lang": "en"
},
"description": {
"type": "literal",
"value": "Justement un autre Jon Doe",
"xml:lang": "fr"
},
"geo": {
"type": "bnode",
"value": "b2"
},
"tel": {
"type": "typed-literal",
"value": "+49-12-3546789",
"datatype": "http://www.w3.org/2001/XMLSchema#string"
}
}
]
}
}
</pre>

'''Remarks''':
* No concept of namespaces, but un-namespaces tokens
* No support for lists
* Paired values for language tags
* Paired values for data types

=== Flat triples approach to RDF graphs in JSON ===

<pre>
{
"triples": [
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2000/01/rdf-schema#type"
},
"object": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/Person"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/name"
},
"object": {
"type": "literal",
"value": "Jon"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://example.org/icollide#name"
},
"object": {
"type": "literal",
"value": "Jon"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/depiction"
},
"object": {
"type": "uri",
"value": "http://jondoe.example.org/me.jpg"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/knows"
},
"object": {
"type": "uri",
"value": "http://janedoe.example.org/#me"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/knows"
} ,
"object": {
"type": "bnode",
"value": "_:b0"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/birthday"
},
"object": {
"type": "typed-literal",
"value": "2010-03-23T13:40:22.489+00:00",
"datatype": "http://www.w3.org/2001/XMLSchema#dateTime"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/age"
},
"object": {
"type": "literal",
"value": 1
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/description"
},
"object": {
"type": "literal",
"value": "Just another Jon Doe",
"xml:lang": "en"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/description"
},
"object": {
"type": "literal",
"value": "Justement un autre Jon Doe",
"xml:lang": "fr"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2006/vcard/ns#geo"
} ,
"object": {
"type": "bnode",
"value": "_:b1"
}
},
{
"subject": {
"type": "uri",
"value": "http://jondoe.example.org/#me"
} ,
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2006/vcard/ns#tel"
} ,
"object": {
"type": "typed-literal",
"value": "+49-12-3546789",
"datatype": "http://www.w3.org/2001/XMLSchema#string"
}
},

{
"subject": {
"type": "bnode",
"value": "_:b0"
} ,
"predicate": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/name"
} ,
"object": {
"type": "literal",
"value": "John Smith"
}
},

{
"subject": {
"type": "bnode",
"value": "_:b1"
} ,
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2006/vcard/ns#latitude"
} ,
"object": {
"type": "typed-literal",
"value": "49.0202626",
"datatype": "http://www.w3.org/2001/XMLSchema#float"
}
},
{
"subject": {
"type": "bnode",
"value": "_:b1"
} ,
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2006/vcard/ns#longitude"
},
"object": {
"type": "typed-literal",
"value": "12.8407428",
"datatype": "http://www.w3.org/2001/XMLSchema#float"
}
},

{
"subject": {
"type": "uri",
"value": "http://janedoe.example.org/#me"
},
"predicate": {
"type": "uri",
"value": "http://www.w3.org/2000/01/rdf-schema#type"
} ,
"object": {
"type": "uri",
"value": "http://xmlns.com/foaf/0.1/Person"
}
}
]
}
</pre>

'''Remarks''':
* No concept of namespaces, but subject, predicate, object sub-objects
* Paired values for language tags
* Paired values for data types

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Msporny Manu Sporny]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Cmatheus Chris Matheus]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Andy_Seaborne Andy Seaborne]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Tsteiner Thomas Steiner]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Mbrunati Matteo Brunati]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Dwood4 David Wood]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Phayes3 Pat Hayes]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Sandro Sandro Hawke]
* [[User:Nhumfrey|Nicholas Humfrey]]

F2F1

Nrixham — Wed, 16 Mar 2011 15:12:49 GMT

Nrixham:

;Date
:13-14 April 2011
;Location
: Amsterdam, The Netherlands ([http://homepages.cwi.nl/~steven/amsterdam.html a guide])
;Agenda
:tbd
;Venue
:[http://www.cwi.nl CWI]; See [http://www.cwi.nl/general/Address separate page] for directions, or the [http://homepages.cwi.nl/~steven/amsterdam.html pages on Amsterdam] done by Steven Pemberton
;Hotel Recommendations
:[[ftf-amsterdam-hotels|Hotel info]]

; Intent to attend (you must sign up to get internet access, food, ...)
: David Wood
: Ivan Herman
: Richard Cyganiak
: Matteo Brunati
: Sandro Hawke
: Steve Harris
: Guus Schreiber
: Jean-Francois Baget
: Mischa Tuffield
: Nicholas Humfrey
: Yves Raimond
: Thomas Steiner
: Dieter Fensel (trying to reschulde another meeting; will know soon)
: Fabien Gandon
; Intent to attend remotely
: Antoine Zimmermann
: Peter F. Patel-Schneider (maybe in person, but not yet determined)
: Axel Polleres
: Gavin Carothers (Time zones likely to be challenging)
: Lee Feigenbaum
: Manu Sporny
: Scott Bauer
: Nathan Rixham

; Regrets
: Andy Seaborne

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 20:49:43 GMT

Nrixham: /* Summary */

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear. For example:

<pre>彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)</pre>

[http://twitter.com/westmoon/status/43526455497474048 source]

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

==== Externalized Languages / Language Mapped to Property ====

Can't think of a decent, reliable way to do this? Maybe somebody can.

=== Syntax Structure ===

RDF is very flexible syntax-wise, because it is a graph based data model (nodes and edges), and can be expressed in any number of ways, from a set of triples, through to key/value objects with a subject assigned.

JSON is typically used to express simple key/value objects, plain old data objects.

RDF in JSON can therefore be assembled as key/value objects with a subject assigned, or in an n-triples like manner (a big list of triples) or anywhere in-between, as with turtle.

note: the benefits and disadvantages run much deeper than the simple ones mentioned in this section, as each option in this document has it's own set of trade-offs, however some primary ones are listed here which are specific to the general syntax option.

==== Triples ====

This option involves specifying the serialization to be a simple set of s,p,o triples, an example may be:
<pre>
[
{"s": "IRI", "p": "IRI", "o": {"_value": "object", "_language": "en"} },
{"s": "_:b1", "p": "IRI", "o": {"_value": "fdb3", "_datatype": "http://www.w3.org/2001/XMLSchema#base64Binary"} }
]
</pre>

Benefits:
* Unambiguous
* Simple for machines process (and to spec!)
* Could be a good machine2machine interchange format for triples.

Drawbacks:
* Requires RDF Tooling to use for most practical purposes
* Extremely unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* Extremely verbose + large bytesize over the wire

Distinguishing Features:
* approach constrains to a triple based syntax, typically lends to "one way to do each thing".

==== Iterative Reduction ====

This approach involves iteratively reducing the Triples approach until something more "turtle-list" (for lack of a better word) is created. Simple beginning steps may involve:

Allowing multiple object values:
<pre>
[
{"s": "IRI", "p": "IRI", "o": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}] }
]
</pre>

Turn each Property-Object chain in to a key/value object:

<pre>
{
"subject-IRI": {
"http://www.w3.org/2000/01/rdf-schema#label": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}],
"http://www.w3.org/2002/07/owl#sameAs": [ "http://data.nytimes.com/14085781296239331901", "http://sws.geonames.org/2643743/" ]
}
}
</pre>

and so forth, perhaps adopting some of the various options outlined in this document in the process.

Benefits:
* Reduced bytesize over the wire

Drawbacks ''(depending how close to "Objects" you get)'':
* Requires RDF Tooling to use for most practical purposes
* Unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* It's not triples, and it's not objects

Distinguishing Features:
* approach is unconstrained and every option is viable, including multiple option combinations (multiple ways to state a property for example).

note: there may be more benefits, feel free to add, the original author of this document (nathan) can't see any though, to him this is just unfriendly turtle.

==== Objects ====

This approach starts with typical plain old simple objects as found in most JSON in the wild, then focusses on keeping it as close to the JSON data that's in the wild as possible, and allowing data from specific sources to be consumed without the use of RDF tooling. This lends more to a mapping based approach.

Example starting point:
<pre>
{
"id": 1237642,
"name": "Bob",
"age": 44
}
</pre>

Typical approach would be to start with a simple key/value object then layer on subjects and additional datatypes (like IRI and dates)
<pre>
{
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Then handle URI properties (see the many options under URI Properties above for more):
<pre>
{
"@vocab": "http://example.org/schema/user#",
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Benefits:
* Simple for developers to work with when using JSON.parsed data / not nose-following
* Minimal bytesize over the wire
* Familiar to most users
* Easy to publish without requiring a full RDF tooling or tech stack changes
* Potentially allows bootstrapping of many web 2.0 data sources.

Drawbacks:
* Requires RDF Tooling to use when following your nose around the web
* Takes more processing when working with the data like RDF than the Triples approach

Distinguishing Features:
* approach is constrained such that the end result would be as close to existing typical JSON usage as possible, to simple objects that is.

==== Summary ====

There are many different variations possible, especially when taking the "Iterative Reduction" approach.

Two points to consider from nathan:
* Every follow your nose usecase always requires tooling and processing, so this can be null and voided from most of the drawback sections. The main variables are "how much processing?", "how big? (bytesize)" and "can this be easily used as simple JSON.parsed data when not following your nose?".
* It helps to have a usecase/requirements/constraints when creating things, both the "triples" and "objects" approaches have clear requirements and end goals, the "iterative reduction" option on the other hand..

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 20:49:03 GMT

Nrixham: /* Objects */

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear. For example:

<pre>彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)</pre>

[http://twitter.com/westmoon/status/43526455497474048 source]

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

==== Externalized Languages / Language Mapped to Property ====

Can't think of a decent, reliable way to do this? Maybe somebody can.

=== Syntax Structure ===

RDF is very flexible syntax-wise, because it is a graph based data model (nodes and edges), and can be expressed in any number of ways, from a set of triples, through to key/value objects with a subject assigned.

JSON is typically used to express simple key/value objects, plain old data objects.

RDF in JSON can therefore be assembled as key/value objects with a subject assigned, or in an n-triples like manner (a big list of triples) or anywhere in-between, as with turtle.

note: the benefits and disadvantages run much deeper than the simple ones mentioned in this section, as each option in this document has it's own set of trade-offs, however some primary ones are listed here which are specific to the general syntax option.

==== Triples ====

This option involves specifying the serialization to be a simple set of s,p,o triples, an example may be:
<pre>
[
{"s": "IRI", "p": "IRI", "o": {"_value": "object", "_language": "en"} },
{"s": "_:b1", "p": "IRI", "o": {"_value": "fdb3", "_datatype": "http://www.w3.org/2001/XMLSchema#base64Binary"} }
]
</pre>

Benefits:
* Unambiguous
* Simple for machines process (and to spec!)
* Could be a good machine2machine interchange format for triples.

Drawbacks:
* Requires RDF Tooling to use for most practical purposes
* Extremely unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* Extremely verbose + large bytesize over the wire

Distinguishing Features:
* approach constrains to a triple based syntax, typically lends to "one way to do each thing".

==== Iterative Reduction ====

This approach involves iteratively reducing the Triples approach until something more "turtle-list" (for lack of a better word) is created. Simple beginning steps may involve:

Allowing multiple object values:
<pre>
[
{"s": "IRI", "p": "IRI", "o": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}] }
]
</pre>

Turn each Property-Object chain in to a key/value object:

<pre>
{
"subject-IRI": {
"http://www.w3.org/2000/01/rdf-schema#label": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}],
"http://www.w3.org/2002/07/owl#sameAs": [ "http://data.nytimes.com/14085781296239331901", "http://sws.geonames.org/2643743/" ]
}
}
</pre>

and so forth, perhaps adopting some of the various options outlined in this document in the process.

Benefits:
* Reduced bytesize over the wire

Drawbacks ''(depending how close to "Objects" you get)'':
* Requires RDF Tooling to use for most practical purposes
* Unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* It's not triples, and it's not objects

Distinguishing Features:
* approach is unconstrained and every option is viable, including multiple option combinations (multiple ways to state a property for example).

note: there may be more benefits, feel free to add, the original author of this document (nathan) can't see any though, to him this is just unfriendly turtle.

==== Objects ====

This approach starts with typical plain old simple objects as found in most JSON in the wild, then focusses on keeping it as close to the JSON data that's in the wild as possible, and allowing data from specific sources to be consumed without the use of RDF tooling. This lends more to a mapping based approach.

Example starting point:
<pre>
{
"id": 1237642,
"name": "Bob",
"age": 44
}
</pre>

Typical approach would be to start with a simple key/value object then layer on subjects and additional datatypes (like IRI and dates)
<pre>
{
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Then handle URI properties (see the many options under URI Properties above for more):
<pre>
{
"@vocab": "http://example.org/schema/user#",
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Benefits:
* Simple for developers to work with when using JSON.parsed data / not nose-following
* Minimal bytesize over the wire
* Familiar to most users
* Easy to publish without requiring a full RDF tooling or tech stack changes
* Potentially allows bootstrapping of many web 2.0 data sources.

Drawbacks:
* Requires RDF Tooling to use when following your nose around the web
* Takes more processing when working with the data like RDF than the Triples approach

Distinguishing Features:
* approach is constrained such that the end result would be as close to existing typical JSON usage as possible, to simple objects that is.

==== Summary ====

There are many different variations possible, especially when taking the "Iterative Reduction" approach.

Two points to consider from nathan:
* Every follow your nose usecase always requires tooling and processing, so this can be null and voided from most of the drawback sections. The only variables are "how much processing?", "how big? (bytesize)" and "can this be easily used as simple JSON.parsed data when not following your nose?".
* It helps to have a usecase/requirements/constraints when creating things, both the "triples" and "objects" approaches have clear requirements and end goals, the "iterative reduction" option on the other hand..

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 20:43:20 GMT

Nrixham: /* Summary */

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear. For example:

<pre>彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)</pre>

[http://twitter.com/westmoon/status/43526455497474048 source]

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

==== Externalized Languages / Language Mapped to Property ====

Can't think of a decent, reliable way to do this? Maybe somebody can.

=== Syntax Structure ===

RDF is very flexible syntax-wise, because it is a graph based data model (nodes and edges), and can be expressed in any number of ways, from a set of triples, through to key/value objects with a subject assigned.

JSON is typically used to express simple key/value objects, plain old data objects.

RDF in JSON can therefore be assembled as key/value objects with a subject assigned, or in an n-triples like manner (a big list of triples) or anywhere in-between, as with turtle.

note: the benefits and disadvantages run much deeper than the simple ones mentioned in this section, as each option in this document has it's own set of trade-offs, however some primary ones are listed here which are specific to the general syntax option.

==== Triples ====

This option involves specifying the serialization to be a simple set of s,p,o triples, an example may be:
<pre>
[
{"s": "IRI", "p": "IRI", "o": {"_value": "object", "_language": "en"} },
{"s": "_:b1", "p": "IRI", "o": {"_value": "fdb3", "_datatype": "http://www.w3.org/2001/XMLSchema#base64Binary"} }
]
</pre>

Benefits:
* Unambiguous
* Simple for machines process (and to spec!)
* Could be a good machine2machine interchange format for triples.

Drawbacks:
* Requires RDF Tooling to use for most practical purposes
* Extremely unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* Extremely verbose + large bytesize over the wire

Distinguishing Features:
* approach constrains to a triple based syntax, typically lends to "one way to do each thing".

==== Iterative Reduction ====

This approach involves iteratively reducing the Triples approach until something more "turtle-list" (for lack of a better word) is created. Simple beginning steps may involve:

Allowing multiple object values:
<pre>
[
{"s": "IRI", "p": "IRI", "o": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}] }
]
</pre>

Turn each Property-Object chain in to a key/value object:

<pre>
{
"subject-IRI": {
"http://www.w3.org/2000/01/rdf-schema#label": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}],
"http://www.w3.org/2002/07/owl#sameAs": [ "http://data.nytimes.com/14085781296239331901", "http://sws.geonames.org/2643743/" ]
}
}
</pre>

and so forth, perhaps adopting some of the various options outlined in this document in the process.

Benefits:
* Reduced bytesize over the wire

Drawbacks ''(depending how close to "Objects" you get)'':
* Requires RDF Tooling to use for most practical purposes
* Unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* It's not triples, and it's not objects

Distinguishing Features:
* approach is unconstrained and every option is viable, including multiple option combinations (multiple ways to state a property for example).

note: there may be more benefits, feel free to add, the original author of this document (nathan) can't see any though, to him this is just unfriendly turtle.

==== Objects ====

This approach starts with typical plain old simple objects as found in most JSON in the wild, then focusses on keeping it as close to the JSON data that's in the wild as possible, and allowing data from specific sources to be consumed without the use of RDF tooling. This lends more to a mapping based approach.

Example starting point:
<pre>
{
"id": 1237642,
"name": "Bob",
"age": 44
}
</pre>

Typical approach would be to start with a simple key/value object then layer on subjects and additional datatypes (like IRI and dates)
<pre>
{
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Then handle URI properties (see the many options under URI Properties above for more):
<pre>
{
"@vocab": "http://example.org/schema/user#",
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Benefits:
* Simple for developers to work with when using JSON.parsed data
* Minimal bytesize over the wire
* Familiar to most users
* Easy to publish without requiring a full RDF tooling or tech stack changes
* Potentially allows bootstrapping of many web 2.0 data sources.

Drawbacks:
* Requires RDF Tooling to use when following your nose around the web
* Takes more processing when working with the data like RDF than the Triples approach

Distinguishing Features:
* approach is constrained such that the end result would be as close to existing typical JSON usage, to simple objects that is.

==== Summary ====

There are many different variations possible, especially when taking the "Iterative Reduction" approach.

Two points to consider from nathan:
* Every follow your nose usecase always requires tooling and processing, so this can be null and voided from most of the drawback sections. The only variables are "how much processing?", "how big? (bytesize)" and "can this be easily used as simple JSON.parsed data when not following your nose?".
* It helps to have a usecase/requirements/constraints when creating things, both the "triples" and "objects" approaches have clear requirements and end goals, the "iterative reduction" option on the other hand..

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 20:29:11 GMT

Nrixham: /* Syntax Structure */

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear. For example:

<pre>彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)</pre>

[http://twitter.com/westmoon/status/43526455497474048 source]

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

==== Externalized Languages / Language Mapped to Property ====

Can't think of a decent, reliable way to do this? Maybe somebody can.

=== Syntax Structure ===

RDF is very flexible syntax-wise, because it is a graph based data model (nodes and edges), and can be expressed in any number of ways, from a set of triples, through to key/value objects with a subject assigned.

JSON is typically used to express simple key/value objects, plain old data objects.

RDF in JSON can therefore be assembled as key/value objects with a subject assigned, or in an n-triples like manner (a big list of triples) or anywhere in-between, as with turtle.

note: the benefits and disadvantages run much deeper than the simple ones mentioned in this section, as each option in this document has it's own set of trade-offs, however some primary ones are listed here which are specific to the general syntax option.

==== Triples ====

This option involves specifying the serialization to be a simple set of s,p,o triples, an example may be:
<pre>
[
{"s": "IRI", "p": "IRI", "o": {"_value": "object", "_language": "en"} },
{"s": "_:b1", "p": "IRI", "o": {"_value": "fdb3", "_datatype": "http://www.w3.org/2001/XMLSchema#base64Binary"} }
]
</pre>

Benefits:
* Unambiguous
* Simple for machines process (and to spec!)
* Could be a good machine2machine interchange format for triples.

Drawbacks:
* Requires RDF Tooling to use for most practical purposes
* Extremely unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* Extremely verbose + large bytesize over the wire

Distinguishing Features:
* approach constrains to a triple based syntax, typically lends to "one way to do each thing".

==== Iterative Reduction ====

This approach involves iteratively reducing the Triples approach until something more "turtle-list" (for lack of a better word) is created. Simple beginning steps may involve:

Allowing multiple object values:
<pre>
[
{"s": "IRI", "p": "IRI", "o": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}] }
]
</pre>

Turn each Property-Object chain in to a key/value object:

<pre>
{
"subject-IRI": {
"http://www.w3.org/2000/01/rdf-schema#label": [{"_value": "London", "_language": "en"},{"_value": "Londra", "_language": "it"},{"_value": "Lontoo", "_language": "fi"}],
"http://www.w3.org/2002/07/owl#sameAs": [ "http://data.nytimes.com/14085781296239331901", "http://sws.geonames.org/2643743/" ]
}
}
</pre>

and so forth, perhaps adopting some of the various options outlined in this document in the process.

Benefits:
* Reduced bytesize over the wire

Drawbacks ''(depending how close to "Objects" you get)'':
* Requires RDF Tooling to use for most practical purposes
* Unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* It's not triples, and it's not objects

Distinguishing Features:
* approach is unconstrained and every option is viable, including multiple option combinations (multiple ways to state a property for example).

note: there may be more benefits, feel free to add, the original author of this document (nathan) can't see any though, to him this is just unfriendly turtle.

==== Objects ====

This approach starts with typical plain old simple objects as found in most JSON in the wild, then focusses on keeping it as close to the JSON data that's in the wild as possible, and allowing data from specific sources to be consumed without the use of RDF tooling. This lends more to a mapping based approach.

Example starting point:
<pre>
{
"id": 1237642,
"name": "Bob",
"age": 44
}
</pre>

Typical approach would be to start with a simple key/value object then layer on subjects and additional datatypes (like IRI and dates)
<pre>
{
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Then handle URI properties (see the many options under URI Properties above for more):
<pre>
{
"@vocab": "http://example.org/schema/user#",
"@id": "http://example.org/users/1237642#",
"name": "Bob",
"age": 44
}
</pre>

Benefits:
* Simple for developers to work with when using JSON.parsed data
* Minimal bytesize over the wire
* Familiar to most users
* Easy to publish without requiring a full RDF tooling or tech stack changes
* Potentially allows bootstrapping of many web 2.0 data sources.

Drawbacks:
* Requires RDF Tooling to use when following your nose around the web
* Takes more processing when working with the data like RDF than the Triples approach

Distinguishing Features:
* approach is constrained such that the end result would be as close to existing typical JSON usage, to simple objects that is.

==== Summary ====

There are many different variations possible, especially when taking the "Iterative Reduction" approach.

Two points to consider from the nathan:
* Every follow your nose usecase always requires tooling and processing, so this can be null and voided from most of the drawback sections. The only variables are "how much processing?", "how big? (bytesize)" and "can this be easily used as simple JSON.parsed data when not following your nose?".
* It helps to have a usecase/requirements/constraints when creating things, both the "triples" and "objects" approaches have clear requirements and end goals, the "iterative reduction" option on the other hand..

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 19:35:12 GMT

Nrixham: adding Syntax Structure section

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear. For example:

<pre>彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)</pre>

[http://twitter.com/westmoon/status/43526455497474048 source]

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

==== Externalized Languages / Language Mapped to Property ====

Can't think of a decent, reliable way to do this? Maybe somebody can.

=== Syntax Structure ===

RDF is very flexible syntax-wise, because it is a graph based data model (nodes and edges), and can be expressed in any number of ways, from a set of triples, through to key/value objects with a subject assigned.

JSON is typically used to express simple key/value objects, plain old data objects.

RDF in JSON can therefore be assembled as key/value objects with a subject assigned, or in an n-triples like manner (a big list of triples) or anywhere in-between, as with turtle.

note: the benefits and disadvantages run much deeper than the simple ones mentioned in this section, as each option in this document has it's own set of trade-offs, however some primary ones are listed here which are specific to the general syntax option.

==== Triples ====

This option involves specifying the serialization to be a simple set of s,p,o triples, an example may be:
<pre>
[
{"s": "IRI", "p": "IRI", "o": {"_value": "object", "_language": "en"} },
{"s": "_:b1", "p": "IRI", "o": {"_value": "fdb3", "_datatype": "http://www.w3.org/2001/XMLSchema#base64Binary"} },
</pre>

Benefits:
* Unambiguous
* Simple for machines process (and to spec!)
* Could be a good machine2machine interchange format for triples.

Drawbacks:
* Requires RDF Tooling to use for most practical purposes
* Extremely unfriendly for typical JSON Developers (and anybody working with the JSON.parsed data directly)
* Extremely verbose + large bytesize over the wire

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 18:59:40 GMT

Nrixham:

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 18:43:44 GMT

Nrixham: /* No Language */

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 18:41:26 GMT

Nrixham: Languages

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF, in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

=== Datatypes ===

RDF includes support for specifying the datatype of literals, commonly referred to as "Typed Literals", this allows any literal to be given a specific datatype, typically one of the xsd: types.

JSON has inbuilt support for a minimal set of datatypes, namely strings, numbers (which covers integers, doubles and decimals), booleans, arrays and objects.

Commonly used datatypes which are not in JSON but frequently used in RDF, are IRI and the various forms of date and time.

Note: Many other JSON related specifications have found a need to define support for IRIs and various forms of date/time, for example [http://activitystrea.ms/head/json-activity.html Activity Streams JSON].

Note: Objects and Arrays will typically have special meaning/usage for RDF - JSON, so will not be discussed further here.

==== Limited Expressibility ====

This approach would constrain the syntax to only being able to express those datatypes already existing in JSON, namely:
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

Benefits:
* Requires no special processing of data
* Familiar to most JSON users
* Simple

Drawbacks:
* No way to use other common or custom datatypes

==== Limited Expressibility + IRIs and Date/Time ====

This approach would extend the native JSON datatypes to include support for IRI, Date, Time and DateTime:
* IRI
* Date
* DateTime
* Time
* String (Unicode)
* Number (Integer, Double, Decimal)
* Boolean (true, false)
* Null (? does RDF have a concept of null,or datatype for it ?)

note: the additional types would need to be quoted like strings in order to keep JSON compatibility, e.g. "http://example.org/" rather than the same without quotes.

Benefits:
* Potentially requires no special processing of data
* Familiar to most users
* Simple
* Enough to cover most common use cases.

Drawbacks:
* No way to use other common or custom datatypes

==== Property Range from Vocab ====

Either of the Limited Expressibility options could be augmented with type hinting from the range of the property being used.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & tooling to do so. (nathan: is this a drawback??)

==== Map the property to a datatype ====

Either of the Limited Expressibility options could be augmented with type hinting on the property, this could be included in the serialization, or in an external map as with the External Maps option for URIs.

Benefits:
* Potentially requires no special processing of data (when not following your nose)
* Familiar to most users
* Simple
* Enough to cover most common use cases.
* Allows expression of common or custom datatypes

Drawbacks:
* Potentially requires understanding of properties when following your nose & ''new'' tooling to do so.

==== Datatypes from JSON schema ====

As above, what we're doing could be merged with JSON Schema, in fact we could fully externalize and work with JSON Schema to create a single spec which covers most of the webs JSON needs, and our own RDF needs - but that's perhaps too wild for this group and out of charter.

(nathan likes this idea)

==== In-String TypedLiterals ====

This approach involves including both the data and the datatype in a single quoted string, for example "FDE3^^xsd:base64Binary"

note: the exact format of the combined string would be up for discussion, we may want to use full IRIs for datatypes, may explicitly offer a set of predefined tokens mapped to IRIs (e.g. "^int"), may have the datatype prefixed or postfixed - many different approaches

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose
* What to do when you don't understand a datatype?

==== Paired Values - value/datatype ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": {
"_value": "FDE3",
"_datatype": "xsd:base64Binary",
}
}</pre>

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - datatype arcs ====

Using either the object or array syntax from JSON, we could specify typed literals like such:
<pre>{ "property": { "xsd:base64Binary": "FDE3" } }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#typed-literals JSN3] for more examples

Options:
* All typed literals like this, including numbers.
* Only some typed literals like this.

Benefits:
* Can express all common and custom datatypes
* Smaller bytesize on the wire (allows repetition)

Drawbacks:
* Always requires special processing
* Unfamiliar to most typical JSON users

=== Languages ===

RDF currently includes support for specifying the language strings (for example english or dutch), Plain Literals, support is often serialization specific, with RDFa delegating to the lang/xml:lang attributes, and turtle taking the "Bob"@en approach.

JSON currently has no support for specifying the language of strings.

==== No Language ====

It's an option... JSON natively supports unicode, thus strings like "花澄" are perfectly acceptable, and JSON is used effectively throughout the web without requiring a language tag, and further often text consists of multiple different languages and which language tag to use is not clear (for example "彭博社:2987名人大代表中70名最富的人资产总值为4931亿人民币，约751亿美元！The richest 70 of the 2,987 members have a combined wealth of 493.1 billion yuan ($75.1 billion)" [http://twitter.com/westmoon/status/43526455497474048 source])

==== Property Specifies Language ====

This option would involve language specific properties being created in vocabs, for example "rdfs:label-en" and "rdfs:label-ja".

Not saying much about this one as it's a huge change to RDF and quite possibly entirely impractical from almost every angle. But, it is an option.

==== Property Modifiers ====

This option involves adding a language hint to the property, as serialization sugar only, for example:
<pre>{ "label@en": "London" }</pre>

Benefits:
* Can express languages
* Potentially lighter to process than "in-string language"
* Potentially smaller bytesize on the wire than both of the paired values option (and allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Can be verbose when working with data in many languages (requires a min of one property value pair per language)

==== In-String Language ====

This approach involves including both the data and the language in a single quoted string, for example "花澄@ja"

note: the exact format of the combined string would be up for discussion, we may want to use IRIs for languages, may explicitly offer a set of predefined tokens (e.g. "@en"), may have the language prefixed ("ja@花澄") or postfixed ("花澄@ja") - many different approaches

Benefits:
* Can express languages

Drawbacks:
* Always requires special processing (including tracking back over parsed data)
* Unfamiliar to most typical JSON users

==== Paired Values - value/language ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {
"_value": "花澄",
"_language": "ja",
}
}</pre>

Benefits:
* Can express languages
* Lighter to process than "in-string language"

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users
* Verbose

==== Paired Values - language arcs ====

Using either the object or array syntax from JSON, we could specify plain literals with languages as such:
<pre>{ "property": {"@en": "London"} }</pre>

note: see [http://webr3.org/apps/specs/jsn3/#language-specification-in-plain-literals JSN3] for more examples

Benefits:
* Can express languages
* Lighter to process than "in-string language"
* Smaller bytesize on the wire than the other paired values option (allows repetition)

Drawbacks:
* Always requires special processing to use the data
* Unfamiliar to most typical JSON users

JSON Syntax Options

Nrixham — Sat, 12 Mar 2011 15:58:23 GMT

Nrixham: added datatypes options

User:Nrixham

Nrixham — Sat, 12 Mar 2011 00:34:33 GMT

Nrixham: /* Nathan Rixham */

== Nathan Rixham ==

Invited Expert in the RDF WG and do not represent any company.

=== Focus ===

Within the RDF WG I'm looking to help out wherever I can in order to support the other members, key areas I'll be focussing on are:

* Standardization of the JSON syntax (considering the RDF API and being a JS developer)
* Standardization of the Turtle syntax (with an N3 focus)
* Clean up around IRIs / RDF URI References and DataTypes/Plain Literals
* Considerations when deprecating some features of RDF (Robustness Principal etc.)
* Support for multiple graphs and graph stores (both named and literal graphs, considering the RDF API, and read-write linked data tech requirements)
* Linked Data considerations (inc Read/Write) and "follow your nose" (ties in with AWWSW TF work)

=== Other W3C Experience ===

* Member of the RDFa WG
* Member of the AWWSW TF
* Member of the WebID XG
* Editor of the RDF API

=== Background ===

I'm a developer who sits at the intersection of the Semantic Web, WebArch, HTML, WebApps, REST/HTTP, JS, Auth/Security and Web Development communities, my primary focus is converging the various web technologies in order to realize the read write web of linked data, intelligent agents, and the model outlined in TimBLs Socially Aware Cloud Storage Design Issue. Thankfully I'm in a position where I can spend most of my time helping this process along through contributing to standardization efforts, communication between groups, and contributions to open source and public domain projects; my efforts within the RDF WG will be one part of that bigger picture.

More: [http://twitter.com/webr3 @webr3] / [http://webr3.org/blog/general/generic-to-do-plan/ info]

[[category:Members]]

JSON Syntax Options

Nrixham — Fri, 11 Mar 2011 22:31:11 GMT

Nrixham: /* JSON Syntax Options */

JSON Syntax Options

Nrixham — Fri, 11 Mar 2011 22:29:24 GMT

Nrixham: /* JSON Syntax Options */

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs + Single Vocab ====

Note: this example uses a made up syntax!
<pre>
{
"#vocab": "http://example.org/my-vocab#",
"name": "Bob",
}
</pre>

To reconstruct the URI, one must append "name" to the value of #vocab ("http://example.org/my-vocab#")

Note:
This may look wonderful, but comes with the one-vocab caveat that means when publishers require multiple terms, they will be likely to create "proxy" vocabularies that simply pull together many terms from different vocabularies and merge them. There is a processing and understanding cost to that which can't be stepped in to lightly.

Benefits:
* Minimal bytesize over the wire
* Familiar to traditional JSON users
* Familiar to RDFa users
* Easy to author
* Unambiguous and easy to process.
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Requires understanding of equivalent property statements in custom vocabularies when following your nose around the web.
* Real world property equivalence is ''far'' more complicated.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

JSON Syntax Options

Nrixham — Fri, 11 Mar 2011 22:15:39 GMT

Nrixham: Created page with "== JSON Syntax Options == This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF in JSON. === URI Properties === RDF uses UR…"

== JSON Syntax Options ==

This page is being used by the RDF WG to harvest different approaches to enabling the key features of RDF in JSON.

=== URI Properties ===

RDF uses URIs to name things, including properties. A key benefit of this is that it allows different data sources to all use properties defined in open vocabularies, thus enabling shared understanding of data.

JSON on the other hand, is typically used for domain specific / silo based information where properties are simple lexical terms (like "name") and what the property "means" is documented somewhere out of band, for instance in API documentation, or in a JSON-Schema document.

There follows a collection of different approaches we can take which enable the use of URI identified properties in JSON.

==== Full URIs ====

<pre>{ "http://xmlns.com/foaf/0.1/name": "Bob" }</pre>

Benefits:
* Unambiguous and easy to process.
* When following your nose around the web, property equivalence uses the in serialization URI.

Drawbacks:
* Increased bytesize over the wire.
* Can be verbose to use when using the returned (JSON.parsed) data without an API or tooling.
* Verbose to author.

Example usage (assuming the returned data has been JSON.parsed):
<pre>obj["http://xmlns.com/foaf/0.1/name"]
obj[ foaf('name') ] // when using a tabulator ns style approach in your code
obj[ resolve('foaf:name') ] // when using a function which allows the resolution of CURIEs as found in the RDF API
</pre>

==== CURIEs ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"foaf:name": "Bob"
}
</pre>

To reconstruct the URI, one must split "foaf:name" on the colon, replace "foaf" with it's related mapping in the prefix map "http://xmlns.com/foaf/0.1/", concatenate "name" to "http://xmlns.com/foaf/0.1/".

Separator Options:
* : colon (familiar, but ''can't'' use . notation in JSON.parsed output)
* _ underscore (unfamiliar, ambiguous when property also contains an underscore)
* $ dollar (unfamiliar, but ''can'' use . notation in JSON.parsed output)

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional RDF users
* Easier to author

Drawbacks:
* Requires tooling to normalize CURIEs prior to using the data when following your nose around the web.
* Requires CURIE resolution to do property comparison (equivalence must be between URIs not CURIEs)
* Unreliable when following your nose around the web (the same URI could be shortened to "ns0:ame" or "f:name")
* Unfamiliar to traditional JSON users
* Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj["foaf:name"]; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (no colon) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"name": "Bob"
}
</pre>

To reconstruct the URI, one must replace "name" with it's related value in the map "http://xmlns.com/foaf/0.1/name"

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Easy to author
* Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* Unfamiliar to traditional RDF users

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== TERMs (with colon allowed) ====

Note: this example uses JSON-LD syntax for the prefix maps:
<pre>
{
"#": { "name": "http://xmlns.com/foaf/0.1/name", "rdfs:label": "http://www.w3.org/2000/01/rdf-schema#label" },
"name": "Bob",
"rdfs:label": "Bob"
}
</pre>

To reconstruct the URI, one must replace the term ("name", "rdfs:label") with it's related value in the map ("http://xmlns.com/foaf/0.1/name", "http://www.w3.org/2000/01/rdf-schema#label")

Benefits:
* Reduced bytesize over the wire
* Familiar to traditional JSON users
* Familiar to traditional RDF users
* Easy to author
* ''non-colon names only'': Easy to use when using the returned (JSON.parsed) data without an API or tooling.

Drawbacks:
* Requires tooling to normalize TERMs prior to using the data when following your nose around the web.
* Requires TERM resolution to do property comparison (equivalence must be between URIs not TERMs)
* Unreliable when following your nose around the web (the same URI could be shortened to "foo" or "bar")
* ''with colon names only'': Verbose to use when using the returned (JSON.parsed) data without an API or tooling.

Example usage (assuming the returned data has been JSON.parsed):
<pre>
obj.name; // non-colon - but ONLY when you are familiar with the data and NOT when following your nose
obj["rdfs:label"]; // with colon - but ONLY when you are familiar with the data and NOT when following your nose
</pre>

==== Option: External Maps ====

Three of the above options ( CURIEs, TERMs no colon, TERMS with colon ) all require a prefix or term map to be included in order to turn shortened properties in to full URIs.

There is a possibility that these maps could be factored out and referenced externally, this option comes with it's own set of benefits and drawbacks.

Benefits:
* Minimal data over the wire.
* When used with either of the TERMs options, allows bootstrapping of existing JSON data in the wild.
* Encourages vocabulary merging and reuse.
* Potentially far easier to deploy, doesn't require publishers to implement/have a sem web stack.

Drawbacks:
* Sometimes requires two GETs when following your nose.
* External map unavailability removes your ability to see the data as RDF.
* Some changes to external maps could change the meaning of the data.

TF-JSON

Nrixham — Thu, 10 Mar 2011 23:25:40 GMT

Nrixham: /* RDF in JSON Use Cases */

= JSON RDF Task Force =

The JSON RDF Task Force is primarily responsible for creating a JSON serialization of RDF.

== Inputs ==

* ''[http://n2.talis.com/wiki/RDF_JSON_Specification RDF JSON]'', by Talis.
* ''[http://json-ld.org/ JSON-LD]'', by Manu Sporny.
* ''[http://decentralyze.com/2010/06/04/from-json-to-rdf-in-six-easy-steps-with-jron/ JRON]'' by Sandro Hawke.
* ''[http://code.google.com/p/linked-data-api/wiki/Specification JSON serialization]'' in the Linked Data API.
* ''[http://www.w3.org/TR/rdf-sparql-json-res/ SPARQL Query Results in JSON]'' by DAWG.
* ''[http://webr3.org/apps/specs/jsn3/ JSN3]'' by Nathan.
* ''[http://www.w3.org/2009/12/rdf-ws/papers/ws02 Flat triples approach to RDF graphs in JSON]'' by Dominik Tomaszuk
* ''[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#JSON Ideas and issues from the community ]'' from RDF Core Work Items build on RDF/NextStepWorkshop, are reproduced below.
* ''[http://www.w3.org/wiki/JTriples JTriples ]'' by Michael Hausenblas
* ''[http://code.google.com/p/backplanejs/wiki/Rdfj RDFj]'' by Mark Birbeck probably.

==== Materials from RDF Next Step WorkShop ====

=====Pros=====
* Allows web authors (Javascript, HTML5, ... developers) more easily use rdf data with existing tools and techniques
* Multiple JSON formats and implementations (some interoperable) already exist showing interest in this work
=====Cons=====
* Current JSON formats are not aligned - differnent approaches - making it JSON-user friendly versus making it familiar to existing RDF users.
* Needs some R&D and alignment.
* Risk that the result would be some standard that would not be adopted if it was not 'web author' friendly.

== Deliverables ==

* JSON Serialization of RDF

== Questions to Contemplate ==

# What are the use cases for the JSON serialization?
# Are we to create a lightweight JSON based RDF interchange format optimized for machines and speed, or an easy to work with JSON view of RDF optimized for humans (developers)?
# Is it necessary for developers to know RDF in order to use the simplest form of the RDF-in-JSON serialization?
# Should we attempt to support more than just RDF? Key-value pairs as well? Literals as subjects?
# Must RDF in JSON be 100% compatible with the JSON spec? Or must it only be able to be read by a JavaScript library and thus be JSON-like-but-not-compatible (and can thus deviate from the standard JSON spec)?
# Must all major RDF concepts be expressible via the RDF in JSON syntax?
# Should we go more for human-readability, or terse/compact/machine-friendly formats? What is the correct balance?
# Should there be a migration story for the JSON that is already used heavily on the Web? For example, in REST-based services?
# Should processing be a single-pass or multi-pass process? Should we support SAX-like streaming?
# Should there be support for [http://json-ld.org/spec/ED/20110201/#disjoint-graphs disjoint graphs]?
# Should we consider how the structure may be [http://payswarm.com/vocabs/signature#JsonldSignature digitally signed]?
# How should [http://json-ld.org/spec/ED/20110201/#the-normalization-algorithm normalization] occur?
# Should [http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/ graph literals] be supported?
# Should [http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/ named graphs] be supported?
# Should [http://json-ld.org/spec/ED/20110201/#automatic-typing automatic typing] be supported?
# Should [http://json-ld.org/spec/ED/20110201/#type-coercion type coercion] be supported?
# Should there be [http://json-ld.org/spec/ED/20110201/#the-json-ld-api an API] defined in order to easily map RDF-in-JSON to/from language-native formats?

== RDF in JSON Use Cases ==

=== Migrating to Semantic Web Services ===

Frank runs a website that provides Web Services via a REST-based API that supports JSON. He would like developers using his system to be able to easily post and get RDF data RESTfully via his Web Services. He wants to make sure that the data that is exchanged looks very much like the JSON data that is passed to and from the Web Services that he already provides. He wants to make sure that developers can utilize the current JSON-based tools and workflows, perhaps with a tiny library for the serializations he uses, but still ensure that he can add semantics to that data in a way that is easy to explain to his Web Service customers.

=== Generalized storage of Semantic Data in Web Services ===

ACME Corp is operating a website with a JSON API. They want to give users the ability to store arbitrary additional data alongside certain objects managed via the API. For example, when a user account is created via the API, the client app should be able to also submit a digital signature or “My upcoming trips” data. The client app would be able to use that data on subsequent requests. To avoid accidental clashes between fields used by different client apps, ACME Corp wants to use RDF as the data model. Nevertheless, they want to keep the impact on the existing JSON API and existing clients to a minimum.

=== Developing a Javascript application that interacts with a graph store ===

Herbert is developing a Javascript application that interacts with an RDF store. He wants to be able to easily PUT, POST and GET RDF data RESTfully using the [http://www.w3.org/TR/sparql11-http-rdf-update/ SPARQL RDF Dataset HTTP Protocol]. Since he is working in Javascript, he wants to be able to send data to a graph store using JSON to represent the RDF data.

=== Expose a service that internally uses RDF in a JSON-friendly way ===

Stacy operates several Web Services. She designed the data that is sent and received by her Web Services in a way that maps very easily to RDF. She wants to be able to take the data that she is already publishing and transform it into RDF for internal use. She wants to be able to do this without impacting the developers that are currently using her system.

She also wants to be able to give the developers that care about RDF a data model that maps to RDF well. She would like to support both regular JSON developers and semantic web JSON developers at the same time via her JSON-based Web Services API.

=== Digital Signatures on Graphs ===

Graeme would like to publish assets for sale on his website via a JSON-based Web Services API. He would like this data to be cached on third party sites without the pricing information being changed or forged. He accomplishes this by digitally signing the graph of information that he publishes such that search engines and other caching mechanisms can relay the information without needing to directly access his site. By cryptographically signing the graph, he is also ensuring that information about the asset, including pricing information, cannot be changed or forged to different values.

=== Universal Payment Standard for the Web ===

The [http://payswarm.com/ PaySwarm Web platform] is an open web standard that enables Web browsers and Web devices to perform Universal Web Payment. The nascent standard is using a form of RDF in JSON extensively in order to support distributed listing of [http://payswarm.com/vocabs/payswarm#Asset assets], description of [http://payswarm.com/vocabs/payswarm#License licenses] and [http://payswarm.com/vocabs/payswarm#Contract digital contracts], and [http://payswarm.com/vocabs/signature#JsonldSignature digital signatures] on graphs of RDF information. Information is published via HTML+RDFa and then used in JSON-form when transmitted to and from PaySwarm-aware Web Services.

=== Treating JSON data as RDF for use in Data Spaces ===

In data integration scenarios it can be useful to “crawl” a JSON API, and reflect the crawled data in an RDF expression that can then be stored in a SPARQL store and further refined/mapped/linked with other RDF. A main challenge in “crawling” JSON APIs in a generic way is the question how to find/construct new URIs to GET from the first JSON response, as this often requires API specific knowledge, such as which fields contains URIs and which templates should be used to construct URIs from field values. Ideally, such URIs would be captured in the RDF representation so that the RDF representation captures the “link structure” in the original JSON. In this use case, producing “idiomatic” RDF that uses proper vocabularies etc from the JSON is perhaps not realistic; the structure of the produced RDF would closely reflect the JSON object structure, and vocabulary terms would be local to the API.

=== Pulling In Data From An External Linked Data Service ===

Joe has had a Justin Bieber fan site hosted on GeoCities forever. After GeoCities got shut down, he first considered migrating his content onto a Facebook fan site, however, having heard of the Semantic Web's recent success stories, decided to run his own site, get some server space, install WordPress, install a WordPress RDFa plugin, and be happy. From reading an article on W3Schools, he knows that if he writes...
<pre>
<div xmlns:foaf="http://xmlns.com/foaf/0.1/" about="http://dbpedia.org/resource/Justin_Bieber">
Justin Bieber's birthday is on
<span property="foaf:birthday" content="1994-03-01">March 1, 1994</span>
</div>
</pre>
...he makes a statement about ''the'' Justin Bieber. At some point he decides to create a Justin Bieber images widget for his site with content from that cool new Semantic Web image site where he can retrieve semantically annotated images using their HTTP API like so:
<pre>
GET http://cool-semantic-image-site.example.org/api/v1/for-sure-not-rest/images?q=dbp:Justin_Bieber&format=json
</pre>
This API returns data in application/rdf-however-we-call-it+json, so he can simply JSON.parse the result, and use it like so:
<pre>
var results = JSON.parse(responseText);
results.images.forEach(function(img) {
// build HTML
});
</pre>
He loves this API, because it is easy to work with in jQuery, plus the returned JSON code is easy to understand by just looking at it.

=== Access CONSTRUCT/DESCRIBE query results from JSON apps ===

SPARQL provides a JSON format for SELECT and ASK queries: currently a [http://www.w3.org/TR/rdf-sparql-json-res/ a W3C WG NOTE].

A JSON serialization of RDF would make the results of CONSTRUCT (and DESCRIBE) queries accessible as JSON-consuming clients.

=== Traditional JSON API over an RDF store ===

Pablo is developing a new web service. He has recently started to explore RDF, and would like to build the new service with an RDF store as the backend. However, all his other services have JSON APIs. He is concerned about alienating his customers by offering only RDF and SPARQL interfaces. He would like a solution that allows him to expose a JSON-based API on top of the RDF store. It should be similar to his other APIs and feel familiar to his users. On the other hand, he also wants to expose the full RDF data model to allow those with the right tooling to make maximum use of his data.

=== View as RDF ===

Eli has an existing popular HTTP API which returns JSON and has many users, he has recently learned of the benefits of the semantic web and linked data, and would like to provide a way for users to see his data as RDF, without changing his entire heavily invested in technology stack or breaking backwards compatibility on his API. Eli can only make minor tweaks, such as adding http based id's to the objects the API returns, and providing a map which relates object property names to well known RDF properties.

== RDF in JSON Design Requirements ==

=== There should be two serialization formats ===

There should be a machine-friendly serialization format and there should be a human-friendly serialization format.

* -1 [[User:Msporny|Manu Sporny]], given the limited time for this working group, I think we should focus on the human-friendly serialization format. RDF already has a number of machine-friendly serialization formats.
* +1 [[User:Andy_Seaborne|Andy]]. A simple "s", "p", "o" format is not the same amount of work as a human-friendly form. See [http://www.w3.org/TR/rdf-sparql-json-res/ SPARQL JSON result format]
* 0 [[User:Lfeigenb|Lee]]. I'd worry about the WG's available time and resources.
* +1 [[User:Nrixham|Nathan]] if possible.
* -0 [[User:Mbrunati|Matteo Brunati]] not enough time maybe
* -0 [[User:Cmatheus|Chris Matheus]] not a priority
* -1 [[User:Tsteiner|Thomas Steiner]] Can we avoid this? One format to rule them all.

=== A primary goal SHOULD be to build a human-friendly version of the serialization for JSON developers ===

The serialization should be optimized for humans first, machines second. The ability for machines to quickly parse the file is secondary to the ability for developers to be able to use the serialization with JavaScript. A focus should be placed on making the serialization fit into JavaScript frameworks easily, even at the cost of JSON-LD processor implementation complexity.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Lfeigenb|Lee]]. Given the existing work in the RDFa group on an API, I'd rather see a simple, machine-friendly format that implementations can then make available via an API. I'm not convinced that a standard human-friendly JSON format is a big win.
* -0 [[User:Andy_Seaborne|Andy]] Different uses cases lead to different design tradeoffs. (e.g [http://code.google.com/p/linked-data-api/ LDA] is a tree; ideal for them, bad for different uses.)
* +1 [[User:Nrixham|Nathan]] but only if the product can be considered simple JSON objects (k/v objects with a subject set) and the caveat is recognized that by not requiring an RDF toolkit or understanding of properties, inference etc, the data isn't really RDF... it's RDF-able - else -1, waste of time.
* +1 [[User:Mbrunati|Matteo Brunati]] +1 Nathan observations
* +1 [[User:Cmatheus|Chris Matheus]] extremely helpful for users new to RDF
* +1 [[User:Tsteiner|Thomas Steiner]] Yes, please! Make it easy for developers to write RDF in JSON.

=== A primary goal SHOULD be to build a machine-optimized version of the serialization ===

The serialization should be optimized for machines first, humans second. The ability to use the serialization in JavaScript is secondary to the ability for machines to quickly parse the file. A focus should be placed on making implementations very easy to write.

* -1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Lfeigenb|Lee]]
* +1 [[User:Nrixham|Nathan]]
* +1 [[User:Mbrunati|Matteo Brunati]]
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] As stated before, I'd love to see one format to rule them all.

=== The serialization SHOULD be able to transform most JSON in use today into RDF ===

There should be a flexible mechanism, such as a "context", that is capable of mapping from JSON key-value pairs to RDF triples. This mechanism could be specified either in-band or out-of-band from the serialization. Having this feature could map much of the existing JSON in the wild into RDF.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Lfeigenb|Lee]]. Seems out-of-scope; do existing RDF-in-JSON solutions already have such mechanisms?
* -1 [[User:Andy_Seaborne|Andy]] The original data was not written to be used in this way.
* +1 [[User:Nrixham|Nathan]] Assuming we're still talking two serializations, then this would be very valuable, for twitter to be able to say here's our data, view it as simple objects or rdf graphs; although I'm unsure we can get there without a common vision across the water.
* -1 [[User:Mbrunati|Matteo Brunati]] +1 to Andy, it's not in the original usage of the data
* -1 [[User:Cmatheus|Chris Matheus]] nice to have but should not consume this team's resources
* 0 [[User:Tsteiner|Thomas Steiner]] Time permitting, not a top priority IMHO.

=== Developers do not need to be familiar at all with RDF to start using the serialization ===

Understanding the semantic web and the concepts of RDF (triples, graphs, etc.) should not be required in order to use the format. That means that the format may have a very simple, stripped down version for beginners and a more advanced set of features for semantic web enthusiasts.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] only if two serializations, and as per previous comments.
* -1 [[User:Rcygania2|Richard Cyganiak]] I ''think'' I disagree. If you don't want to expose developers to RDF at all, then why not just use vanilla JSON? Also I don't understand how the beginner/advanced thing should work. A server will have to generate the one or the other, so it's not like client-side developers get to choose which version they want to be exposed to.
* -1 [[User:Mbrunati|Matteo Brunati]] I think a minimal semweb context is necessary: thinking on SIMILE Exhibit framework. It's not simple to use without a prior knowledge of the model.
* 0 [[User:Cmatheus|Chris Matheus]] some very basic knowledge may be important but deep knowledge should not be required
* -1 [[User:Tsteiner|Thomas Steiner]] People should at /least/ have an understanding of triples, that's enough for most use cases.

=== The serialization MAY include features not in RDF ===

There are certain features, such as generic key-value pairs in JSON that do not map well to RDF. They would map well if RDF had a concept of plain literals in the subject or predicate position. The serialization could include these concepts but may specify that the values may not be serialized to all RDF serialization formats (such as RDF/XML, TURTLE or RDFa).

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Andy_Seaborne|Andy]] creates an incompatible sub-community of applications.
* +1 [[User:Nrixham|Nathan]] useful for allowing "junk" data like debugging info and session tokens, again only if two serializations.
* -1 [[User:Rcygania2|Richard Cyganiak]] as per Andy. Generic key-value pairs can be translated to <tt><nowiki><> <#key> "value"</nowiki></tt> or somesuch.
* -1 [[User:Mbrunati|Matteo Brunati]] as for Andy. making a default rule to the generic key-value stuff
* -1 [[User:Cmatheus|Chris Matheus]] shouldn't spend time on this
* -1 [[User:Tsteiner|Thomas Steiner]] Strong no. Stay compatible with RDF by all means.

=== The serialization MUST be 100% compatible with the JSON spec ===

Additional features such as comments or short-hand notation to support datatypes could be supported in the serialization if we extended the JSON format. This would mean that the serialization would be incompatible with vanilla JSON readers and writers. While this may make serialization nicer, we should not make any additions/modifications to the JSON format to ensure maximum compatibility with pre-existing processors.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Andy_Seaborne|Andy]]
* +1 [[User:Lfeigenb|Lee]]
* +1 [[User:Nrixham|Nathan]] else it's not JSON..
* +1 [[User:Mbrunati|Matteo Brunati]]
* +1 [[User:Cmatheus|Chris Matheus]]
* +1 [[User:Tsteiner|Thomas Steiner]] Strong yes!

=== It is a requirement that all RDF concepts MUST be expressible in the serialization ===

There are concepts like RDF datatypes and g-snaps/graph literals that could be omitted from the serialization in order to reduce learning and implementation complexity.

* -1 [[User:Msporny|Manu Sporny]], Good design is a balancing act - we should only include what will help the most number of people.
* +1 [[User:Lfeigenb|Lee]]. I'd hesitate to say "all", but in general, a JSON RDF serialization would not be useful to us unless it was as much a 1st-class serialization of the RDF model as turtle, RDF/XML, etc.
* +1 [[User:Andy_Seaborne|Andy]] for the machine-friendly form to work with non-JSON apps and systems.
* -1 [[User:Andy_Seaborne|Andy]] for the human-friendly form but the features dropped will vary from usage to usage.
* +1 [[User:Nrixham|Nathan]] for machine (rdf in json)
* -1 [[User:Nrixham|Nathan]] for human (rdf-able json objects)
* -1 [[User:Cmatheus|Chris Matheus]] not for this round
* +0.8 [[User:Mbrunati|Matteo Brunati]] probably yes, but not this time maybe, too complexity?
* -1 [[User:Tsteiner|Thomas Steiner]] Easy things should be easy and hard things should be possible. Keep the entry barrier low (inferred types), but allow the experts to do crazy things.

=== There should be a migration story for going from existing JSON in the wild to this new format ===

The serialization task force should ensure that there is a subset of the serialization that is useful to beginners that use pure JSON, then show how developers could sprinkle in a little RDF into their JSON, then show how developers can fully migrate to the new serialization format. The transition to the serialization format will probably take multiple years The transition should be as smooth and organic as possible. We should also understand that many may not need to transition to RDF - JSON may work just fine for their application. We should not assume that people will go straight from regular JSON to the new serialization format.

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] for human rdf-able json object serialization, if we can get there.
* +1 [[User:Mbrunati|Matteo Brunati]]
* -0 [[User:Cmatheus|Chris Matheus]] time permitting
* -0 [[User:Tsteiner|Thomas Steiner]] Time permitting

=== Memory usage and CPU usage while processing SHOULD be a primary consideration ===

Memory and CPU usage for processing JSON is low. We should ensure that processing the serialization format is only slightly more complex than processing regular JSON.

* +0 [[User:Msporny|Manu Sporny]], we want to be cognizant of resource usage but I don't think this should be a primary driver for design decisions for the language.
* -1 [[User:Lfeigenb|Lee]]. Seems like an implementation detail to me.
* -1 [[User:Andy_Seaborne|Andy]] (NB: JSON structures are read entirely into memory before the application gets to see them.)
* +0.5 [[User:Nrixham|Nathan]] there is a balance between memory and processing to be struck, ntriples = more byte, turtle = more processing, same considerations for JSON.
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] IMHO if you need the ultimate performance, use, e.g., N-Triples, readability should have a higher priority, personally speaking.

=== The design target is small snippets of RDF Data ===

"small" might be less than 1 million triples, not 10.

* +1 [[User:Andy_Seaborne|Andy]]
* 0 [[User:Nrixham|Nathan]] two different considerations for machine or human, I'd say under 10k for human, over and beyond for machine
* +1 [[User:Tsteiner|Thomas Steiner]] For huge dumps use, e.g., N-Triples IMHO.

=== Design target: graphs or resources ===

A human friendly JSON format can be designed more towards graphs (multiple subjects) or more targeted on just describing one resource (subject). This is not to exclude one possibility over the other - this is to decide the focus.

* graphs [[User:Andy_Seaborne|Andy]]
* machine: graphs, human: resource [[User:Nrixham|Nathan]]
* graphs [[User:Msporny|Manu Sporny]], but I don't think we'll need to choose between the two if we're smart about it. For instance, JSON-LD allows expressing graphs just as easily as expressing resources.
* graphs [[User:Cmatheus|Chris Matheus]]
* resources [[User:Tsteiner|Thomas Steiner]]

=== The serialization MUST support disjoint/unconnected graphs ===

All current RDF serialization formats allow you to express two graphs that are not necessarily connected to one another. The new serialization format should allow the same mechanism. This is also important because normalization is difficult to achieve in a general way without also supporting disjoint graphs in the serialization. JSON-LD [http://json-ld.org/spec/ED/20110201/#disjoint-graphs disjoint graphs example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Andy_Seaborne|Andy]] One graph with two+ disjoint components per serialization
* +0 [[User:Andy_Seaborne|Andy]] Multiple graphs per serialziation. No more than follow work in other TFs.
* +1 [[User:Nrixham|Nathan]] as per andy's comments
* +1 [[User:Cmatheus|Chris Matheus]]

=== The serialization MUST provide a normalization algorithm ===

Normalization, also known as canonicalization, is typically used when determining whether two sub-graphs that are expressed in different ways are identical. It is also very useful when hashing sub-graphs for checksumming or digital signature purposes. JSON-LD [http://json-ld.org/spec/ED/20110201/#the-normalization-algorithm normalization example].

* +1 [[User:Msporny|Manu Sporny]], I think we need normalization because we need to have a good digital signatures story
* ? [[User:Andy_Seaborne|Andy]]. Unclear - are we signing the graph or the serialization? Is a Turtle-signed graph the same graph? Would it include IRI normalization?
* +0 [[User:Nrixham|Nathan]]
* +0 [[User:Cmatheus|Chris Matheus]] highly desirable if there's time
* +1 [[User:Tsteiner|Thomas Steiner]] Time permitting

=== The serialization SHOULD enable digital signatures ===

Digital Signatures have a number of useful purposes. When combined with g-snaps/graph literals they provide a very easy way of establishing cryptographically verifiable provenance. These features are used heavily in electronic commerce. JSON-LD [http://payswarm.com/vocabs/signature#JsonldSignature digital signature example].

* +1 [[User:Msporny|Manu Sporny]]
* +0 [[User:Nrixham|Nathan]]
* 0 [[User:Rcygania2|Richard Cyganiak]] Nice to have but won't make or break the format.
* +0 [[User:Mbrunati|Matteo Brunati]]
* 0 [[User:Cmatheus|Chris Matheus]] nice to have
* +1 [[User:Tsteiner|Thomas Steiner]] Time permitting, not highest priority IMHO, though.

=== The serialization SHOULD support advanced graph concepts ===

The serialization format should support advanced graph concepts such as g-box, g-snap and g-text such that you can make statements about snapshots of graphs. Annotating graphs with metadata such as graph retrieval time, digital signatures on the contents of the graph, and other metadata associated with graphs are an important feature for higher-level concepts like provenance. Sandro's explanation of [http://lists.w3.org/Archives/Public/public-rdf-wg/2011Feb/0092.html advanced graph concepts].

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Rcygania2|Richard Cyganiak]] Has security implications for RDF crawlers; requires larger API surface; SPARQL only returns single graphs anyways; use case is unclear
* -1 [[User:Andy_Seaborne|Andy]] Not unless the format is following standard work done in other TFs.
* +0.5 [[User:Nrixham|Nathan]] follow other TFs
* 0 [[User:Mbrunati|Matteo Brunati]] too problematic probably, +1 Richard notes
* -0 [[User:Cmatheus|Chris Matheus]] not this round unless the Graph TF results happens quickly and their incorporation is straight forawrd

=== The serialization MUST support automatic typing ===

Being able to transform a JSON document into a native object is one of the key benefits of using JSON over other serialization formats. Automatically typing of numbers and boolean values into language-native datatypes removes an extra step that developers must perform without this feature. For example, one could easily transform a serialized number that is an xsd:integer into a language-native integer. JSON-LD [http://json-ld.org/spec/ED/20110201/#automatic-typing automatic typing example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]]
* +1 [[User:Rcygania2|Richard Cyganiak]] I'd say it's what users expect.
* +1 [[User:Mbrunati|Matteo Brunati]]
* +1 [[User:Cmatheus|Chris Matheus]]
* +1 [[User:Tsteiner|Thomas Steiner]] Strong yes. This is what the JavaScript community would expect I think.

=== The serialization SHOULD support type coercion ===

While not immediately obvious, type coercion allows one to map regular JSON into RDF in a way that may add datatype decorators to object literals. In other words, it provides for a way to get Typed Literals from regular JSON data. JSON-LD [http://json-ld.org/spec/ED/20110201/#type-coercion type coercion example].

* +1 [[User:Msporny|Manu Sporny]]
* +1 [[User:Nrixham|Nathan]] for human one, -1 for machine one
* +1 [[User:Tsteiner|Thomas Steiner]] Yes, as this is what people (IMHO) expect, and it keeps the entry barrier low. Still allow for overriding.

=== The serialization SHOULD rely on microsyntaxes instead of nested structures ===

There are two common approaches to expressing RDF in JSON. One of them is to use nested structures to express language and type information for literals. The other approach is to use shallow structures with microsyntaxes mirroring TURTLE to express language and type information for literals.

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Rcygania2|Richard Cyganiak]] It's ugly as hell and makes the language unusable without an API
* -1 [[User:Nrixham|Nathan]]
* -1 [[User:Mbrunati|Matteo Brunati]]
* -1 [[User:Cmatheus|Chris Matheus]]
* -1 [[User:Tsteiner|Thomas Steiner]] Microsyntaxes are easy to get wrong. Nested structures occupy more memory and require two object accesses on read/write, however, with default/inferred types, this could be OK.

=== The serialization SHOULD provide an API ===

An API would allow developers to transform incoming documents into a format that is easier for them to work with. In other words, it would allow them to drop all type information if it wasn't useful to them, or remove any micro-syntaxes that would get in the way of basic usage of the data. Keep in mind that even JSON has an api: JSON.parse(). JSON-LD [http://json-ld.org/spec/ED/20110201/#the-json-ld-api API example].

(?? Reword as: The serialization SHOULD assume working with a JavaScript RDF API ([[User:Andy_Seaborne|Andy]]))

* +1 [[User:Msporny|Manu Sporny]]
* -1 [[User:Nrixham|Nathan]] the machine one will have the RDF API, the human one is pointless if it needs and API.
* +1 [[User:Mbrunati|Matteo Brunati]] as Andy said, working with an API ( are there other WG are working on that or not? )
* -1 [[User:Cmatheus|Chris Matheus]] not this round
* -1 [[User:Tsteiner|Thomas Steiner]] The JSON is the API, we just need to make it easy enough.

=== There SHOULD be one and only one way to serialize a given triple ===

The more different ways there are to express the same triple or graph, the harder it gets to use the host language's native toolbox (that is, pure JS expressions) to process data. At some point, using the host language becomes impossible without using a parser library layered on top of the host language, negating the benefit of basing the language on JSON in the first place. (Note, this is about using different JSON structures to express the same triple; not about different triples expressing the same statement in RDF Semantics, like <tt>"foo"</tt> vs <tt>"foo"^^xsd:string</tt>).

* +1 [[User:Rcygania2|Richard Cyganiak]] This is the lesson to be learnt from RDF/XML.
* +0 [[User:Msporny|Manu Sporny]], while I agree in principle I don't know how we'd enforce this in practice - that is, what's the difference between "foo" and "foo"^^xsd:string in JSON? Would you serialize the plain literal "foo" and the Typed Literal "foo"^^xsd:string in the same way in JSON? If the answer is yes, isn't the translation lossy?
** This one is inherent to the way the RDF model is defined. There's nothing that can be done about it in the syntax. The concern here was about using different JSON structures to express the same triple. I clarified the description.
* +1 [[User:Mbrunati|Matteo Brunati]] as for Richard, RDF/XML is the lesson
* ++1 [[User:Cmatheus|Chris Matheus]]
* +0 [[User:Tsteiner|Thomas Steiner]] Can it be done? How about 1.0 double vs 1.0 float? Compare, e.g., QUnit's equality tests (jQuery unit test framework): deepEqual (http://docs.jquery.com/QUnit/deepEqual#actualexpectedmessage) vs. strictEqual (http://docs.jquery.com/QUnit/strictEqual#actualexpectedmessage) vs. equal (http://docs.jquery.com/QUnit/equal#actualexpectedmessage)

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Msporny Manu Sporny]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Cmatheus Chris Matheus]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Andy_Seaborne Andy Seaborne]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Tsteiner Thomas Steiner]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Mbrunati Matteo Brunati]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Dwood4 David Wood]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Phayes3 Pat Hayes]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Sandro Sandro Hawke]

TF-Graphs

Nrixham — Wed, 09 Mar 2011 14:54:56 GMT

Nrixham:

= Task Force "Graphs" =

== Use Cases ==
Member [[TF-Graphs-UC|Use Cases]] for graphs, graph identifiers, etc.

== Terminology ==

* [[GraphConceptTerminology| Graph Concept Terminology]] to use when discussing "graphs".

== Material ==
* [[TF-Graphs/RDF-Datasets-Proposal|Proposal: RDF Datasets]]

== Workshop results ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

=====Proposals=====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

=====Technical Issues=====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack
* how does it influence the OWL semantics?

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Lfeigenb Lee Feigenbaum]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Rcygania2 Richard Cyganiak]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Fgandon Fabien Gandon]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Gcarothe3 Gavin Carothers]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Phayes3 Pat Hayes]
* [http://www.w3.org/2011/rdf-wg/wiki/User:ZheWu Zhe Wu]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Ocorby Olivier Corby]
* [http://www.w3.org/2011/rdf-wg/wiki/User:sharris2 Steve Harris]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Sandro Sandro Hawke]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Andy_Seaborne Andy Seaborne]
* [[User:Azimmerm|Antoine Zimmermann]]

TF-Graphs

Nrixham — Wed, 09 Mar 2011 14:54:33 GMT

Nrixham:

= Task Force "Graphs" =

== Use Cases ==
Member [[TF-Graphs-UC|Use Cases]] for graphs, graph identifiers, etc.

== Terminology ==

* [GraphConceptTerminology Graph Concept Terminology] to use when discussing "graphs".

== Material ==
* [[TF-Graphs/RDF-Datasets-Proposal|Proposal: RDF Datasets]]

== Workshop results ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

=====Proposals=====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

=====Technical Issues=====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack
* how does it influence the OWL semantics?

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Lfeigenb Lee Feigenbaum]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Rcygania2 Richard Cyganiak]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Fgandon Fabien Gandon]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Gcarothe3 Gavin Carothers]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Phayes3 Pat Hayes]
* [http://www.w3.org/2011/rdf-wg/wiki/User:ZheWu Zhe Wu]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Ocorby Olivier Corby]
* [http://www.w3.org/2011/rdf-wg/wiki/User:sharris2 Steve Harris]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Sandro Sandro Hawke]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Andy_Seaborne Andy Seaborne]
* [[User:Azimmerm|Antoine Zimmermann]]

Graph Terminology

Nrixham — Wed, 09 Mar 2011 14:52:49 GMT

Nrixham: created graph concept terminology page

== Graph Concept Terminology ==

The term "RDF Graph" has become used to refer to multiple different concepts over the years. This page introduces three temporary terms relating to different graph concepts, which can be used within RDF WG discussions and use cases.

=== g-box ===
A "g-box" is a container, like a "set" data structure in
programming. It holds some RDF arcs, with their nodes. (Alternatively,
it holds some RDF triples.). G-boxes can overlap, sharing some of the
same nodes and arcs. Two g-boxes can happen to have the same contents
(right now) while being distinct g-boxes. G-boxes contents can change:
today a particular g-box might contain the triples { my:a my:b _:x.
my:a my:c _:x }, and tomorrow it might instead contain { my:a my:b _:x.
my:a my:c2 _:x }.

=== g-snap ===
A "g-snap" as an idealized snapshot of a g-box; it's a mathematical
set of RDF arcs, with their nodes. (Alternatively, a mathematical set
of RDF triples.) Like g-boxes, g-snaps can overlap, sharing nodes and
arcs. Unlike g-boxes, it makes no sense to talk about g-snaps
changing: they are defined to be exactly the collection of their
elements. If a g-snap were to "change" it would simply be a different
g-snap. If two g-snaps have the same nodes/arcs, they are really the
same g-snap. The contents of a g-box at any point in time are a
g-snap.

=== g-text ===
A "g-text" is a particular sequence of characters or bytes which
conveys a particular g-snap in some language (eg turtle or rdf/xml). If
you can parse a g-text, you know what is in the g-snap it conveys
(except blank nodes, as discussed below). You can tell someone exactly
what is in a particular g-box at some instant by sending them a
g-text. (You send them the g-text which conveys the g-snap which is
the current state/contents of that g-box.)

== Possible Requirements ==

* There may exist a need to make statements about a g-box, thus a way to refer to them may be required
* There may exist a need to make statements about a g-snap, or a distinct set of triples, thus a way to refer to one may be required
* There may exist a need to make statements about a "state" of a g-box, either previous or future, thus a way to refer to a g-snap as being the state of g-box-X at Y time may be needed.

== General Story ==

A "named g-box" equates roughly to an "Information Resource" or a "Named Graph in a Quad Store", ( name , G ) where G is a set of values over time { Gs1, Gs2, ... }, each value in the set is a g-snap, a distinct set of triples, and each g-snap can be "serialized" or "represented" in many different ways (RDF/XML, turtle, rdf-json, ...). Each distinct serialization/representation is a "g-text".

==== Kudos ====
Thanks to Sandro Hawke for introducing the terms and making our lives a little easier.

TF-JSON

Nrixham — Mon, 07 Mar 2011 10:25:40 GMT

Nrixham: /* RDF in JSON Design Requirements */

TF-Turtle

Nrixham — Wed, 02 Mar 2011 16:41:50 GMT

Nrixham: /* Participants */

= Task Force "Turtle" =

== Material ==

* [[Inputs_Turtle|Inputs]]

== Participants ==
* [http://www.w3.org/2011/rdf-wg/wiki/User:Gcarothe3 Gavin Carothers]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Lfeigenb Lee Feigenbaum]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Andy_Seaborne Andy Seaborne]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]

TF-Graphs

Nrixham — Wed, 02 Mar 2011 16:41:25 GMT

Nrixham:

= Task Force "Graphs" =

== Use Cases ==
Member [[TF-Graphs-UC|Use Cases]] for graphs, graph identifiers, etc.

== Material ==

[http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items#Graph_Identification Suggestions called "Graph Identification" from Stanford Workshop] are reproduced below.

=====Pros=====
* widely used by the community
* part of SPARQL already
* numerous use cases
* clarify confusion in implementation

=====Cons=====
* adds complication and may not solve the issue nevertheless
* complicates the RDF model (potentially)
* risks with backward compatibility should be assessed (e.g., syntax)
* does it need standardization?

=====Proposals=====
* Named graphs, provenance and trust , Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005, http://www.w3.org/2009/12/rdf-ws/p613.pdf, http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/carroll-ISWC2004.pdf
* Quadstores in general
* ODM RDF Metamodel (see http://www.omg.org/spec/ODM/1.0/, section 10.5, derived from Carroll et al.)
* Michel Chein and Marie-Laure Mugnier. Positive nested conceptual graphs. In Proceedings of ICCS '97, volume 1257 of LNAI, pages 95-109, Springer, 1997. (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.3644) ; Nested Graphs: A Graph-based Knowledge Representation Model with FOL Semantics (1998) ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.5256 )
* SPARQL Specifications ([http://www.w3.org/TR/rdf-sparql-query/#rdfDataset RDF Datasets]) and related to that, [http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist Axel's proposal] to base the work on RDF Datasets (see IRC)
* Notation 3, Tim Berners-Lee, 1998 http://www.w3.org/DesignIssues/Notation3
* ideas from the Topic Maps work (see also SWBPD WG note, http://www.w3.org/TR/rdftm-survey/)
* “Triplesets: Tagging and Grouping in RDF Datasets”, http://www.w3.org/2009/12/rdf-ws/papers/ws24, Atanas Kiryakov, Vassil Momtchev
* hypergraphs (as a general mathematical domain)

=====Technical Issues=====
* mutual roles of quads vs. singleton named graphs vs. named graphs
* extension the RDF(S) semantics?
* new RDF(S) terms? rdf:Graph, rdf:subGraphOf, rdf:equivalentGraph, etc.
* syntax (TRIG, [http://www.w3.org/Submission/rdfsource/ INRIA Member submission], [http://www.springerlink.com/content/wh8x37j46n941427/ Web, Graphs and Semantics] , n3)
* graph inclusion, can named graphs share triples
* whether blank nodes can be shared among multiple graphs
* whether blank nodes can be used as graph names
* named graphs do not fully replace reification
* how would follow your nose apply to named graphs?
* relationships to SPARQL
* effects on the SW stack
* how does it influence the OWL semantics?

== Participants ==

* [http://www.w3.org/2011/rdf-wg/wiki/User:Lfeigenb Lee Feigenbaum]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Rcygania2 Richard Cyganiak]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Fgandon Fabien Gandon]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Gcarothe3 Gavin Carothers]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Phayes3 Pat Hayes]
* [http://www.w3.org/2011/rdf-wg/wiki/User:ZheWu Zhe Wu]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Ocorby Olivier Corby]
* [http://www.w3.org/2011/rdf-wg/wiki/User:sharris2 Steve Harris]
* [http://www.w3.org/2011/rdf-wg/wiki/User:Nrixham Nathan Rixham]

TF-JSON

Nrixham — Wed, 23 Feb 2011 16:40:12 GMT

Nrixham: /* Inputs */

TF-JSON

Nrixham — Sun, 20 Feb 2011 19:19:37 GMT

Nrixham: /* Questions to Contemplate */

TF-JSON

Nrixham — Sun, 20 Feb 2011 19:11:32 GMT

Nrixham:

TF-JSON

Nrixham — Sun, 20 Feb 2011 19:09:41 GMT

Nrixham:

Main Page

Nrixham — Wed, 16 Feb 2011 16:25:03 GMT

Nrixham: /* Meetings */

__NOTOC__
= RDF Working Group =

{{BlueBanner|''Mission: Update the [http://www.w3.org/standards/techs/rdf#w3c_all 2004 RDF Recommendations], extending RDF to include features desirable and important for interoperability, but without a negative effect on deployment.'' (See [http://www.w3.org/2011/01/rdf-wg-charter Charter])}}

== Deliverables ==

(Drafts will be linked from here, as they are created)

See [http://www.w3.org/2011/rdf-wg/wiki/Category:Inputs Inputs].

== Participation ==

See
[http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 list of current participants],
(or [http://www.w3.org/2000/09/dbwg/details?group=46168 with contact info]),
[[Special:ListUsers|wiki user pages]],
[http://www.w3.org/2011/rdf-wg/track/users nicknames]

If you want to join this group, see [[How to Join]].

If you are officially in the group, you will automatically receive group email and your w3.org login and password will work on this wiki.

== Meetings ==

Face-to-face: [[F2F1]] [[F2F2]] ...

Teleconferences ([http://www.w3.org/2000/09/dbwg/details?group=46168&public=1 official participants] and invited guests only):
* Wednesdays, 11am US/Eastern time, for up to 90 minutes.
* Dial +1-617-761-6200 or sip:zakim@voip.w3.org then conference code 73394#
* [http://www.w3.org/Project/IRC/ IRC] channel: [irc://irc.w3.org:6665/#rdf-wg #rdf-wg].
* An agenda is [http://lists.w3.org/Archives/Public/public-rdf-wg/latest sent] 24 hours in advance; minutes follow within a day or two.

Upcoming Telecons [[Scribes]]:
* 2011-02-16 [http://lists.w3.org/Archives/Public/public-rdf-wg/2011Feb/0018.html agenda]

Recent Past:
* None Yet

== Timeline ==

Only trivial updates since the [http://www.w3.org/2011/01/rdf-wg-charter#deliverables charter version].

* 2011-02: First teleconference
* 2011-04: First face-to-face meeting ([[F2F1]])
* 2011-05: Publication of the First Public Working Drafts for the RDF Recommendation Set
* 2011-10 or 11: Second face-to-face meeting ([[F2F2]])
* 2012-04: Third face-to-face meeting
* 2012-05: Publication of the Last Call Working Draft for the RDF Recommendation Set
* 2012-06: Publication of the Last Call Working Draft for the RDF Primer and Test Cases
* 2012-10 or 11: Fourth face-to-face meeting
* 2012-11: Publication of the Proposed Recommendations
* 2012-01: Publication of all final documents

== W3C Working Group Resources ==

* [http://www.w3.org/Guide/ Art of Consensus (guide to working at W3C)] (W3C member confidential)
* [http://www.w3.org/2005/10/Process-20051014 World Wide Web Consortium (W3C) Process Document]
* [http://www.w3.org/Member/Mail/Overview.html All W3C Groups] (W3C member confidential)

more? zakim, irc, commonscribe, tracker,

== Patent Policy ==

This Working Group operates under the [http://www.w3.org//Consortium/Patent-Policy-20040205/ W3C Patent Policy] (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the [http://www.w3.org/2004/01/pp-impl/46168/status W3C Patent Policy Status Page].

== Staff ==

Email the chairs and staff contacts at [mailto:team-rdf-chairs@w3.org team-rdf-chairs@w3.org].

* [http://www.linkedin.com/pub/david-wood/a/b24/495 David Wood], Talis Inc., Co-Chair
* [http://www.cs.vu.nl/~guus/ Guus Schreiber], Vrije Universiteit, Co-Chair
* [http://www.w3.org/People/Sandro Sandro Hawke], W3C, Staff Contact
* [http://www.w3.org/People/Ivan Ivan Herman], W3C, Staff Contact

User:Nrixham

Nrixham — Thu, 10 Feb 2011 01:02:10 GMT

Nrixham: Created page with "== Nathan Rixham == Invited Expert in the RDF WG and do not represent any company. === Focus === Within the RDF WG I'm looking to help out wherever I can in order to support t…"

== Nathan Rixham ==

Invited Expert in the RDF WG and do not represent any company.

=== Focus ===

Within the RDF WG I'm looking to help out wherever I can in order to support the other members, key areas I'll be focussing on are:

* Standardization of the JSON syntax (considering the RDF API and being a JS developer)
* Standardization of the Turtle syntax (with an N3 focus)
* Clean up around IRIs / RDF URI References and DataTypes/Plain Literals
* Considerations when deprecating some features of RDF (Robustness Principal etc.)
* Support for multiple graphs and graph stores (both named and literal graphs, considering the RDF API, and read-write linked data tech requirements)
* Linked Data considerations (inc Read/Write) and "follow your nose" (ties in with AWWSW TF work)

=== W3C Experience ===

* Member of the RDFa WG
* Member of the AWWSW TF
* Member of the WebID XG
* Editor of the RDF API

=== Background ===

I'm a developer who sits at the intersection of the Semantic Web, WebArch, HTML, WebApps, REST/HTTP, JS, Auth/Security and Web Development communities, my primary focus is converging the various web technologies in order to realize the read write web of linked data, intelligent agents, and the model outlined in TimBLs Socially Aware Cloud Storage Design Issue. Thankfully I'm in a position where I can spend most of my time helping this process along through contributing to standardization efforts, communication between groups, and contributions to open source and public domain projects; my efforts within the RDF WG will be one part of that bigger picture.

More: [http://twitter.com/webr3 @webr3] / [http://webr3.org/blog/general/generic-to-do-plan/ info]

[[category:Members]]