Re: Example of Atom publication using LDP

Henry,

On Thu, Feb 7, 2013 at 6:04 PM, Henry Story <henry.story@bblfish.net> wrote:

> I wonder how it is meant to work with JSON-LD... Looking here:
> http://json-ld.org/spec/latest/json-ld-syntax/
>
> I see that they have a few profiles defined, which would allow it to be
> served with:
>
> Content-Type: application/json;profile=
> http://www.w3.org/ns/json-ld#expanded-flattened
>
> Right?
>
> But then how would one add the ldp profile to that too?
>

Erik's draft [1] explicitly says "Media types defining a "profile"
parameter SHOULD define it as a whitespace-separated list of profile
URIs.", so I would expect something like that:

  application/json;profile=http://www.w3.org/ns/json-ld#expanded-flattened
http://w3.org/ldp

It seems to me that json ld is doing the right thing with its profile of
> json, because that is a syntactic spec. Whereas the type of the content
> sent is orthogonal to the syntax. The above seems to reinforce my point.
>

1/ I don't agree that profile are limited to syntax; in fact, the
introduction of Erik's draft mentions semantics explicitly. But that is not
even a problem, because...

2/ ... I think that syntax is precisely why we need profiles. But don't
forget that RDF has *two* levels of syntax: concrete syntax (turtle vs.
JSON-LD vs. RDF/XML vs...), and abstract syntax (graphs). While you are
right that the profiles proposed in the JSON-LD spec are about the concrete
syntax (i.e. how precisely the graph is encoded), nothing prevents us to
define profiles about the abstract syntax, i.e. what we can expect to
actually find in the graph (regardless of it concrete encoding). See my
example in a previous mail: it's not about the semantics, it's all about
the abstract syntax, i.e. which triples will be there.

(and I probably should not have sidetracked about obtaining those triples
with inference...)

For specifying semantics, we already have RDF-S, OWL... Profiles fullfill
an orthogonal need: constraining the abstract syntax (i.e. the graph) so
that clients know what to expect.

Here is an example: take an OWL axiom stating that a foaf:Person has
exactly one dbo:father (semantics). It does *not* guarantee that you will
*have* in your graph an arc
  X dbo:father Y
for every person X in your graph (syntax).

In any case this is a minor issue, since there is a good solution to this
> using Link elements,
> or by looking in the graph.
>

(by link elements, I assume you are refering to link header fields)
I don't think so; link header fields and arcs in the graph both state
properties of the resource, not the resource representation.

I know that [1] suggests that link header fields should be used to express
profile information, either for redundancy or when the media-type does not
support it,but I think it's a miss-feature (which I actually realized when
writing this message) -- but that is probably not the place to discuss that.

  pa

[1] http://tools.ietf.org/html/draft-wilde-profile-link-04


> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>