Re: Review and Comments for Linked Data Platform FPWD

On 29 Oct 2012, at 20:58, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

> 
> 
> On 29/10/12 19:42, steve.battle@sysemia.co.uk wrote:
>> 
>> On 28 Oct 2012, at 20:09, David Wood <david@3roundstones.com> wrote:
>> 
>>> Hi all,
>>> 
>>> On Oct 28, 2012, at 11:23, David Wood <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> .


>> 
>>> 
>>> 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
Web: 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.