On Wed, Feb 15, 2012 at 08:49:32AM -0500, Jon Phipps wrote:
> I've been doing some wandering around in JSON land for the last few days
> and, as part of a continuing observation that RDF is an implementation
> detail rather than a core requirement, I'd like to point to this post from
> James Snell
> http://chmod777self.blogspot.com/2012/02/mostly-linked-data.html
> And the JSON Scema spec: http://json-schema.org/

It looks to me like he considers RDF to be a "format" and, as such,
comparable to JSON. Commenting on [1], he writes:

    Reading on a little further, the document goes on to expand on that third
    point, "In order to enable a wide range of different applications to
    process Web content, it is important to agree on standardized content
    formats. The agreement on HTML as a dominant document format was an
    important factor that made the Web scale. The third Linked Data principle
    therefore advocates use of a single data model for publishing structured
    data on the Web – the Resource Description Framework (RDF), a simple
    graph-based data model that has been designed for use in the context of the
    Web [70]. The RDF data model is explained in more detail later in this
    chapter."

    I can absolutely agree with the first part -- that standardized content
    formats are critical. But the "single data model" bit makes me twitch. We
    don't need a single data model.. what we need are common conventions for
    pulling out the bits of information we need regardless of the specific
    format used.

...i.e., in my reading, he is equating "data model" with a "specific format".
As I proposed yesterday, I think it is important to distinguish between RDF
"the model and abstract syntax" and RDF/XML "the concrete serialization syntax,
or format" -- not to mention other concrete RDF syntaxes such as N-Triples and
Turtle -- in DCAM's general message:

    The Dublin Core Abstract Model (DCAM) provides a language for representing
    the structure of specific Metadata Records -- put more abstractly, to
    specify a Description Set Profile -- in a form that is independent of
    particular Concrete Encoding Technologies such as XML Schema, RDF/XML,
    RelaxNG, relational databases, Schematron, or JSON.

    In order to provide compatibility with Semantic Web and Linked Data
    applications, however, DCAM is fully aligned with the Model and Abstract
    Syntax of RDF. (Note that the RDF abstract model is the basis for -- thus
    distinct from -- concrete RDF encoding technologies such as RDF/XML,
    N-Triples, and Turtle.) Knowledge of RDF is not a prerequisite for
    understanding DCAM on an informal level.

It would help if we could agree on a way to characterize this distinction
(e.g., "Concrete Encoding Technologies" versus "Model and Abstract Syntax").

Unless I'm missing the point of his argument, I do not think James Snell is
proposing JSON Activity Streams as a generic abstract syntax -- something which
would compete with RDF as a "grammatical" basis for interoperability in Linked
Data. He emphasizes his point that "If you're familiar with Activity Streams
and the linking extensions, then you'll know exactly what to do with this."
That seems consistent with what we want to do with DCAM -- with the added
distinction that if a JSON format is aligned with DCAM, and DCAM is aligned
with RDF, then one would in principle be able to express the contents of a JSON
format using an RDF concrete syntax. Indeed, James's formulation that "what we
need are common conventions for pulling out the bits of information we need
regardless of the specific format used" could almost be used verbatim in a
description of the DCAM we are discussing.

Jon writes:
> as part of a continuing observation that RDF is an implementation
> detail rather than a core requirement...

I am coming around to the idea that DCAM (or at any rate, "DCAM 2") might be
presented informally without emphasizing RDF, and that some people might find
such a DCAM useful as a very high-level way to conceptualize metadata (i.e.,
Statements, composed of Slots for information and grouped into Descriptions and
Description Sets, following common design patterns, etc...) I still do not see
the value of specifying a DCAM that is anything less than perfectly aligned
with the RDF Model and Abstract Syntax. That people may take inspiration from
such an RDF-grounded model, ignoring the RDF basis, is not something we should
worry about. But RDF, such as it is, is the only common _grammatical_ basis
for data that we currently have, and not to ground DCAM in RDF would make it
useless for the purposes of RDF-based interoperability.

Tom

[1] http://linkeddatabook.com/editions/1.0/


--
Tom Baker <[log in to unmask]>