W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

Re: Documenting an an explicit URI to be used for representing POSTed new LDPC members

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Tue, 30 Oct 2012 19:38:12 +0000
CC: "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
Message-ID: <4CCEF98C-ABC2-441B-BA12-2DED7B4867C7@uk.fujitsu.com>
To: Olivier Berger <olivier.berger@it-sudparis.eu>

hi Oliver, 

I agree with most of your email. It seems to be similar to the the model we are using (briefly described in [1]). I agree that the factory pattern is a good model for the creation process. 

Regarding the client discovering (or naming) the resource, to date, we just ignore the subject ID in the request entity. The server, supplies the predicate list which it needs/likes to be able to create (like a form?), and the endpoint for POSTing. Essentially the client POSTs to the creator these predicate/object pairs. 

Note, this does actually support cloned creation, but also the case where "there is a very big difference between what you're submitting, and what ends up being server state" [2]. 

As for ignoring the subject ID :: it is easy in JSON_LD - just miss the @id attribute. And in turtle, just generate a anonymous URI.

It seems to work quite nicely in practice.  
Is there something wrong with it ? 


[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0101.html
[2] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0184.html (Eric Wilde)

On 30 Oct 2012, at 17:40, Olivier Berger wrote:
> Hi.
> I'm not sure I've been able to read all the discussions about the (base)
> URI of newly created LDPC members, when using POST to create
> them. Here's another proposal which I hope is not redundant. Pardon me
> in advance as I'm a novice in SemWeb compared to the eminent members of
> the WG.
> Let's say I want to add new members (reusing Example 2's URIs) to
> <http://example.org/netWorth/nw1>'s (sub-)container(s).
> So, let's say I should be POSTing to a its "factory"/POST enpoint
> <http://example.org/netWorth/nw1/assetContainer> a resource looking like
> the following :
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
> @prefix o: <http://example.org/ontology/>.
> <http://example.org/netWorth/nw1/assetContainer#_new>
>   a o:Stock;
>   o:value 10000.
> So, this factory_URI + '#_new' could be mandated by the specs to
> represent the URI in the posted resource, by convention (it's very
> unlikely to have a confusion between that one and other URIs of
> predicates or values.
> Would such a convention on a special fragment for representing the
> POSTed resource help solve the base URI discussions ?
> We could also make it less a convention, but an explicit URI, provided
> by the container/factory.
> So we could even render this '#_new' relative fragment explicit, as
> provided in a "ldp:newResourceUri" property of the Container(Factory)
> (which would be an optional property, and if provided, SHOULD be
> different from the Container(Factory)'s URI, otherwise it doesn't bring
> anything new to the current specs ;) :
> (Reusing the class names and example I provided in my other post
> Message-ID: <871ugfj37a.fsf@inf-8657.int-evry.fr>), that'd make (if you
> prefer "#_tobecreated" to "#_new":
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
> @prefix o: <http://example.org/ontology/>.
> <http://example.org/netWorth/nw1/assetContainer>
>   ldp:ContainerFactory;
>   ldp:newResourceUri <http://example.org/netWorth/nw1/assetContainer#_tobecreated>;
>   ldp:membershipSubject <http://example.org/netWorth/nw1>;
>   ldp:membershipPredicate o:asset.
> <http://example.org/netWorth/nw1>
>   a o:NetWorth, ldp:IndirectContainer;
>   ldp:creationFactory <http://example.org/netWorth/nw1/assetContainer>;
>   o:asset
>      <http://example.org/netWorth/nw1/assetContainer/a1>,
>      <http://example.org/netWorth/nw1/assetContainer/a2>.
> Again, hoping that it makes sense and helps.
> Best regards,
> -- 
> Olivier BERGER 
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)

Received on Tuesday, 30 October 2012 19:39:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC