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

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.

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.

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.

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
>

Received on Thursday, 14 March 2013 12:23:53 UTC