Re: Review and Comments for Linked Data Platform FPWD

On 29/10/12 23:11, steve.battle@sysemia.co.uk wrote:
> On 29 Oct 2012, at 20:58, Andy Seaborne <andy.seaborne@epimorphics.com
> <mailto:andy.seaborne@epimorphics.com>> wrote:
>
>>
>>
>> On 29/10/12 19:42, steve.battle@sysemia.co.uk
>> <mailto:steve.battle@sysemia.co.uk> wrote:
>>>
>>> On 28 Oct 2012, at 20:09, David Wood <david@3roundstones.com
>>> <mailto:david@3roundstones.com>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> On Oct 28, 2012, at 11:23, David Wood <david@3roundstones.com
>>>> <mailto:david@3roundstones.com>>
>>>> wrote:
>>>>> - Section 5.4.8 says that "LDPC servers MUST interpret the null
>>>>> relative URI for the subject of triples... as referring to the
>>>>> entity in the request body". I understand why you would want to
>>>>> do that, but this is another case where implementors should be
>>>>> expected to scream.  You are asking them to introspect each
>>>>> triple during ingest just in case it might contain a null
>>>>> relative URI in the. subject position.  Then you are asking them
>>>>> to assign a URI for the resource before the parsing is known to
>>>>> be valid...
>>>>
>>>> The more I think about this, the more I think that this is a real
>>>> problem for implementors.  Load speeds are always an issue and this
>>>> would make things much worse.
>>>
>>> David, no introspection is required, implementors would parse the
>>> POSTed RDF serialization with the document base set to the created
>>> resource URI. Expansion of the null relative URI proceeds according
>>> to the usual semantics of the language (at least for Turtle and
>>> RDF/XML).
>>
>> But it does assume that parsing is not done immediately that data is
>> received as might be natural when systems separate the basic request
>> handling from the
>>
>>>
>>> Admittedly generating the pesky null relative URIs on the client side
>>> presents a problem for many of today's tools - not entirely sure
>>> why.
>>
>> Because to create RDF, you need absolute URIs.  Creating RDF without
>> absolute URIs is not what normal tools support.  It requires fakery
>> (rewrite on output) or addition, non-RDF, assumptions about the tools.
>> And no use of N-triples.
>>
>
> Fakery or not, what I'm unsure about is why the following jena 2.7.4
> code doesn't output the null relative URI (whereas if RDF/XML is
> selected as the RDF Writer we get the equivalent rdf:about="").
>
> public class TestNullRelativeURI {
> public static void main(String[] args) {
> Model m = ModelFactory.createMemModelMaker().createDefaultModel();
> m.setNsPrefix("foaf", "http://xmlns.com/foaf/0.1/");
> Resource s = m.createResource("http://example.com/this");
> Resource t =
> m.createResource("http://xmlns.com/foaf/0.1/PersonalProfileDocument");
> Property p = m.createProperty("http://xmlns.com/foaf/0.1/primaryTopic");
> Resource o = m.createResource("http://example.com/this#me");
> m.add(s,RDF.type,t);
> m.add(s,p,o);
> m.write(System.out,"TURTLE","http://example.com/this");
> }
> }
>
> outputs:
>
> @prefix foaf:    <http://xmlns.com/foaf/0.1/> .
>
> <http://example.com/this>
>        a       foaf:PersonalProfileDocument ;
>        foaf:primaryTopic <http://example.com/this#me> .

Submit a patch.

Experience showed that output that separated the information (separate 
the base for the content) lead to people writing out data, putting it up 
on the web and then being surprised they did not get the same RDF 
triples.  Either because there is no such thing as *a* base URI (there 
are many due to trivial details of DNS names for example) or because the 
don't realise that they need to know the name where it will reside 
before they write the file.

If you want the feature, submit a patch to the Jena JIRA on Apache. 
There is a new TTL writer coming along so a patch to that would be 
better but it's mostly a clean up of the old one so either will do.

	Andy

>
>
>>>
>>>>
>>>> Would the WG accept a compromise?  I propose that clients MUST
>>>> inform servers if they expect null relative URIs to be placed with
>>>> the newly created URI for the resource.  That way, servers only
>>>> need to incur the cost of the extra parsing and computation when
>>>> they are told they need to do it.  Does that work?
>>>
>>> In that case, how otherwise would we refer to the subject of the
>>> resource creation? The URI is unknown at the time of the POST.
>>
>> Why not POST to create the new resource, using an empty body, get the
>> URI back "Location:"), then PUT the contents?  c.f. 303 roundtrip.
>>  Then the RDF to be stored can be created after the URI is allocated
>> and standard toolkits can be used.
>>
>> This also allows you to POST the entry in the container - or POST to
>> the container itself, c.f. ?non-member-properties.
>
>
> Yes - neat solution. And also consistent with the current spec. There
> wouldn't be any need to send a special flag to indicate non-usage of the
> null relative URI form.
>
>>
>> Andy
>>
>>>
>>>>
>>>> The flag can be passed to the server on the PUT URL by appending
>>>> ?updateNull or some such.
>>>>
>>>> Regards, Dave
>>>>
>>>>
>>>
>>>
>>> Steve Battle
>>>
>>
>
> Steve Battle
>
> --
> Steve Battle
> Semantic Engineer
>
> E-mail: steve.battle@sysemia.co.uk <mailto:steve.battle@sysemia.co.uk>
> Web: www.sysemia.com <http://www.sysemia.com/>
>
> Sysemia Limited
> The Innovation Centre, Bristol&  Bath Science Park, Dirac Crescent,
> Emerson's Green, Bristol BS16 7FR
> Registered in England and Wales. Company Number: 7555456
>
> DISCLAIMER
>
> Information contained in this e-mail is intended for the use of the
> addressee only, and is confidential and may also be privileged. If you
> receive this message in error, please advise us immediately. If you are
> not the intended recipient(s), please note that any form of
> distribution, copying or use of this communication or the information in
> it is strictly prohibited and may be unlawful. Attachments to
> this e-mail may contain software viruses which may damage your
> systems. Sysemia Ltd have taken reasonable steps to minimise this risk,
> but we advise that any attachments are virus checked before they are opened.
>
>
>
>

Received on Tuesday, 30 October 2012 11:40:27 UTC