Re: Example of Atom publication using LDP

On 7 Feb 2013, at 21:48, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:

> 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...)

Ok, that is helpful. It helps make more sense as to why you want to put the profile on the mime type.

But, I still think that the profile is orthogonal to the mime type. Is easy to show that it is. 

1. Orthogonality of type 
-------------------------------

Take any serialisation of rdf in any of the mime types, and let us see how your 
profile LDP profile would be written. Here are a few:

  application/json;profile=http://www.w3.org/ns/json-ld#expanded-flattened http://w3.org/ldp
  text/turtle;profile=http://w3.org/ldp
  text/n3;profile=http://w3.org/ldp
  application/rdf+xml;profile=http://w3.org/ldp
  application/x-trig;profile=http://w3.org/ldp
  something/grddlable;profile=http://w3.org/ldp

Whatever the mime type ( as currently understood ) in which you can encode a graph,
the profile will remain constant.  

And vice versa you could invent any number of profiles
which you could keep constant across any mime types.

Ie:
 let M be the set of all RDF Mime Types
 let  P be the set of all Profiles 

your structure

   M;profile=P

Will just be the set of pairs MxP, ie all possible ways of combining M and P.

2. Orthogonality of implementation
----------------------------------------------

In order to see if the profile applies you first need to parse the document
according to the syntax which you will discover by looking at the mime 
type - as understood traditionally, ignoring the profile - 
then you query the generated graph to see if it contains the triples.

These two steps are also orthogonal.

Compare this with the charset attribute on a mimate type such as

Content-Type: text/html; charset=UTF-8

Here you cannot correctly parse the document without knowing the charset. 

I would say when two things are orthogonal, it does not make sense to mix them together
like this. Another header makes more sense. 

Now to your next point

> 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).

Yes. I agree. But I don't think what you are thinking follows from this.

Let us say that we have the statement 

   :joe a foaf:Person .

It follow from this then according to your ontology that

   :joe dbo:father [] .

even though we were not told that initially. Ie we have the
following implication between these two graphs:

  {  :joe a foaf:Person . } <=> {    :joe dbo:father [] . }

Good so where is that meant to lead us? Does this restrict us to saying
things about informational things?

Let us consider the class of all books that are the Hamlet by Shakespear. 
Dean Allemang in "Semantic Web for the working Ontologist" uses this 
example and calls this class lit:Hamlet .

So I have here in my room a physical book with pages that is an instance of the 
lit:Hamlet class. Let me call this object bbl:hml.

  bbl:hml a lit:Hamlet;
              :language :english .

It follows from this that 

  bbl:hml a Book .

And many other things. But as you see I can create a class of all things that are syntactically
equivalent. Perhaps I could even create a wider class the set of all books that are hamlet 
translated into any language

  lit:InternationalHamlet

then 

  bbl:hml a lit:InternationalHamlet .

And the French version of Hamlet that is in your library call it chp:hml is also in that set

 chp:hml a lit:InternationalHamlet ;
               :language :french .

I don't think you want to deny that there is such a set of things? and yet as you 
see lit:InternationalHamlet is a set that is defined semantically, or at least it
is an equivalent set of books by translation.

  So we can speak about informational objects such as books, newspaper, 
graphs even and we can classify them. 


> 
> 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)

Yes, as I described in greater detail yesterday:

  http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0061.html

> I don't think so; link header fields and arcs in the graph both state properties of the resource, not the resource representation.

But what is the resource? Is an HTTP header not metadata about the body 
and the resource  of which it is a representation? This at least is how Atom 
thinks of it
http://www.ietf.org/rfc/rfc4287
So for example the "alternate" relation, relates the content of the entry to 
an alternate representation 
       The value "alternate" signifies that the IRI in the value of the
       href attribute identifies an alternate version of the resource
       described by the containing element.

And since the Web Linking spec is based on the Atom link element 
In Section-5 it states:

[[
   The Link entity-header field provides a means for serialising one or
   more links in HTTP headers.  It is semantically equivalent to the
   <LINK> element in HTML, as well as the atom:link feed-level element
   in Atom [RFC4287].
] http://tools.ietf.org/html/rfc5988#section-5 ]
We can use the Link Header to describe a type of content, even if we specify
this at the level of abstract syntax.


> 
> 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/
> 
> 

Social Web Architect
http://bblfish.net/