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

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