Re: A modest attempt to re-open ISSUE-20

Hi Martynas



On Thu, Mar 14, 2013 at 1:23 PM, Martynas Jusevičius
<martynas@graphity.org>wrote:

> Hey Reto,
>
> if the LDP WG would have like to consult the public, it had every
> chance to do so. I have followed the development, and it doesn't seem
> that the interest is there however.
>
> The WG is considering such decisions as RDF graphs with relative URIs,
> which would result in restricting the LDP-supported syntaxes, require
> new specifications, and break tool support. What it is not
> considering, quite strangely, that maybe the premises that led to
> these kind of outcomes were false.
>
> It has not considered, for example, that maybe containers based on
> membership predicates make no sense at all. That an LDP platform could
> simply be a RESTful front for an RDF dataset performing update
> operations, and it doesn't matter which container (or which URI at
> all) the RDF request is submitted to. And that containers may only be
> useful for pagination. But instead it continues to build on top of
> that, and add more layers of complexity like aggregation, composition
> etc.
>

I must admit I haven't studied the container feature closely. I will when
I'll try to implement this stuff on top of clerezza.


>
> The WG has not considered either, that there likely is a more formal
> way to specify a Linked Data Platform. That an LDP instance could
> consist of an RDF dataset, declarative description (ontology), and a
> specification of the (state-machine) processor, that produces RDF
> responses based on those inputs. It is not unlike how XSLT works:
> given input XML document and a stylesheet, the processor produces a
> result XML.
>

I think this is an important point. A by the hypertext requirement of REST
a REST client should need nothing more than an entry URI and a shared media
type to be able to fully use a REST service. No spec reading should be
needed except for understanding the media type. Now for Semantic REST
service in my opinion the common media type is trivially given and the
requirement should be the common ontology. So the specification of a
Semantic REST service is nothing but specifying the ontology. And ok,
mandating a serialization format the service must support if you insist.


>
> This WG is designing probably the most anticipated Linked Data
> specification, but if it continues on the current track, it will
> discredit it with a bloated result that will not help the adoption of
> Linked Data but harm it (what RDF/XML did to RDF back in the day). The
> spec will be too complex for a Web developer looking to go the
> semantic way, and useful mostly for the companies behind the current
> draft.
>

I agree that spec is quite long already. Maybe the number of code lines for
the reference implementation should be limited to 2000? ;)

Cheers,
Reto


>
> Martynas
> graphity.org
>
> On Thu, Mar 14, 2013 at 1:16 PM, Reto Bachmann-GmĆ¼r <reto@apache.org>
> wrote:
> > On Thu, Mar 14, 2013 at 10:02 AM, Andy Seaborne
> > <andy.seaborne@epimorphics.com> wrote:
> >>
> >>
> >> The spec will have to note that you can not use N-triples for POST to a
> >> LDPC.
> >
> >
> > Plese don't go that way. Stay in RDF, have LDP describe the
> communication in
> > terms of RDF graphs. Of course many serializations formats can easily be
> > tweaked to allow serializing a superset of RDF including graphs with
> > relative URIs. But only by defining LDP in terms of RDF you make sure all
> > present and future RDF serialization formats are supported.
> >
> > Even using text/turte as media type is a lie (too use the emotive term).
> > You're using a subset of the turtle syntax (turtle without @base) to
> express
> > something other than what turtle expresses (turtle is "a textual syntax
> for
> > RDF" according to its spec).
> >
> >
> >> On 14/03/13 08:09, Henry Story wrote:
> >>>
> >>>
> >>> On 14 Mar 2013, at 08:26, Reto Bachmann-GmĆ¼r <reto@apache.org
> >>> <mailto:reto@apache.org>> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Wed, Mar 13, 2013 at 11:54 AM, Henry Story <
> henry.story@bblfish.net
> >>>> <mailto:henry.story@bblfish.net>> wrote:
> >>>>
> >>>>
> >> ...
> >>
> >>
> >>>> IIUC, the server will know but the producer of the RDF serialization
> >>>> does not. So what is effectively serialized is not actually RDF but a
> >>>> pseudo RDF supporting relative URIs that can only be serialized in
> >>>> those RDF serializations implicitly supporting this.
> >>>
> >>>
> >>> What you are serialising is a concrete syntax, not an abstract syntax.
> >>> Concrete syntaxes can have
> >>> relative URLs.
> >>
> >>
> >> Concrete syntax is the Turtle.  Abstract syntax is the RDF.
> >>
> >> I don't understand that statement - surely the stuff you are serializing
> >> from has absolute URIs if it's RDF?
> >>
> >>
> >>> When the Jena or Sesame APIs allow you to create such serialisations
> are
> >>> those libraries lying because they don't know where the serialisation
> is
> >>> going to end up on your hard drive or on your server?
> >>
> >>
> >> Yes - although "lying" is too emotive.
> >
> >
> > Well to support this turtle abuse at least the definition of the
> respective
> > method in jena would have to be adapted [1] as it currently does not
> mandate
> > that all URIs are made relative but even explicitly allows the base to
> > appear in the serialized format. I didn't look at the Sesame API but it's
> > probably similar
> >
> >
> >
> >>
> >>
> >> It would be better to call them baseless URIs when in client form.
> >>
> >>
> >> (pun intended :-))
> >>
> >>
> >>> When an artist
> >>> produced HTML with relative URLs and sends a tar of it to the company
> >>> that made the request, is the html sent  to them flawed because the
> >>> artist does not know the exact path for where the html is going to end
> >>> up at? ( Put some RDFa in the html if you feel like saying the example
> >>> is irrelevant )
> >>
> >>
> >> The URIs in the content change and the sender can not be sure the
> intended
> >> meaning is preserved.
> >>
> >> Would you sign such a document as back up claims against it?
> >>
> >>
> >>>> I think not letting the client deal with the RDF on the abstract
> >>>> syntax level is quite a severe limitation.
> >>>
> >>>
> >>> That is why we are using the concrete syntax Turtle to pass information
> >>> to and fro, not the abstract one.
> >>
> >>
> >> I think the point is how does the client create such baseless data, not
> >> how is it exchanged.
> >>
> >> For example, the client can only generate local data in this fashion -
> any
> >> data they have received or gathers from elsewhere will be using absolute
> >> URIs.
> >>
> >> So if you view the client as editting information to reside in the LDPR,
> >> then arguing at the pure syntax level if fine.  It's an exchange of
> bytes,
> >> not of RDF.
> >>
> >> If you view the client as creating some abstract syntax (information)
> and
> >> publishing it at an LDPR whether via an LDPC or PUT and maybe
> publishing the
> >> information at the places as well), then you have to talk in terms of a
> >> template, not actual information.
> >>
> >> In defining POST-LDPC, the spec needs to say that you can't use
> N-triples.
> >> There's no base, internally or externally.
> >
> >
> > It's not just N-Triple that can't easily be abused for this (trix, and
> some
> > json fomats come to mind). So if LDP really want to go that route it
> should
> > enumerate the formats that can be abused and describe how. Or a choose
> > cleaner approach define Baseless RDF as an abstract syntax and then be
> open
> > for new serialization formats for that thing. But again, even if an
> elegant
> > solution for the concrete issue may not be obvious please stay in RDF and
> > define the messages in term of RDF.
> >
> > Reto
> >
> >>
> >>
> >>         Andy
> >>
> >
> >
> > [1]
> >
> http://jena.apache.org/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/Model.html#write%28java.io.OutputStream,%20java.lang.String,%20java.lang.String%29
> >
>