Re: Property-name scoping

Perhaps people could start to enumerate the goals, which could be included in a section within the spec. For me, the format should satisfy the following goals:


 *   Straight-forward representation of data in JSON using forms based on existing practice,
 *   Ability to represent data as triples (subject-predicate-object or entity-attribute-value),
 *   Ability to supplement with additional semantic information (e.g., @context for defining terms, prefixes and datatypes),
 *   Compatible with RDF data representations,
 *   Use of simple terms as attribute names,
 *   No requirement to provide datatyping information of values explicitly within representation (but ability to do so),
 *   Ability to represent relationship between an entity and one or more other entities, either by referencing document as a URI, to a representation included within the JSON-LD document, or as a sub-element of another entity

Note that the introduction already says many of these things in prose:

JSON-LD is designed as a light-weight syntax that can be used to express Linked Data. It is primarily intended to be a way to express Linked Data in Javascript and other Web-based programming environments. It is also useful when building interoperable Web Services and when storing Linked Data in JSON-based document storage engines. It is practical and designed to be as simple as possible, utilizing the large number of JSON parsers and existing code that is in use today. It is designed to be able to express key-value pairs, RDF data, Microformats data, and Microdata. That is, it supports every major Web-based structured data model in use today. It does not require anyone to change their JSON, but easily add meaning by adding context in a way that is out-of-band. The syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth migration path from JSON to JSON with added semantics. Finally, the format is intended to be fast to parse, fast to generate, stream-based and document-based processing compatible, and require a very small memory footprint in order to operate.

Best way to express your opinion on the spec is to suggest specific changes, and/or fork the repository and submit suggested changes in a pull request.

Gregg

On Jun 27, 2011, at 2:50 PM, Patrick Logan wrote:

On Mon, Jun 27, 2011 at 2:29 PM, glenn mcdonald <glenn@furia.com<mailto:glenn@furia.com>> wrote:

You're kind of rephrasing the question: what are the goals here? Is JSON-LD
a RDF serialization, or a convention for representing graphs in JSON, or
something else? If it's strictly an RDF serialization, then I probably don't
care about it, but I thought the whole point of "JSON-LD" as a new effort
distinct from the RDF/JSON working group was to reopen precisely this
question, so that it might be answered in a way that would lead to
significantly simpler and more accessible spec...

OK - now I think you are on to something. The goals of a spec should
be clear before the spec work begins.

-Patrick