Re: JSON-LD bnode canonical naming algorithm

>
> Where can we find a complete spec or documentation to the Needle
> database data model? I'd like to read up on it and learn more about it.


The "complete" Needle data-model spec addresses a lot of other concerns
beyond just expressing graphs, and so wouldn't be that helpful here. My
earlier post to this list is essentially a conceptual excerpt from it,
explaining the data-model in terms of the serialization:

http://lists.w3.org/Archives/Public/public-linked-json/2011May/0010.html

That post describes the basic approach to serializing nodes, which is the
simple part I'm suggesting the JSON-LD effort should initially consider.

Above that there are questions of vocabulary-mapping, base IRIs and
datatypes. These are a topic unto themselves, I think. The current JSON-LD
approach addresses these with special meta-syntax (@vocab, @iri, @coerce, et
al). I think this is a reasonable enough approach, although if you don't
allow per-instance datatyping you probably wouldn't call the per-type
datatyping "coerce". I think you're on the right track with the versions of
these that are designed to be layered on top of exact existing JSON, and I
would go farther and eliminate all the inline versions.

But if you really want a graph to be self-describing, then I believe you
want its schema to be part of its data, as well. So Needle doesn't split the
world the way RDF and RDFS/OWL do. Each instance node declares its type via
a _Type arc to a node of type _Type, which in turn has a data format (i.e.,
a datatype in the RDF sense) and an _Arc arc to _Arc nodes representing the
type's arcs. These types and arcs thus also have IDs. It's all nodes. I
could produce a more detailed writeup of this part if it seemed helpful.
Going this way would eliminate all the @vocab/@coerce stuff, and leave us
with, I think, just some questions about where, exactly, all the base IRIs
need to go.

glenn