Re: linking from resource -> container ..

Steve, are your example resources complete or did you show just a subset? 
By "complete" I mean did you also assume the existence of membership 
triples, or is it the case that a web client starting only with the 
container's URL would be unable to enumerate its members?

I want to understand which scenarios would be supported/able, and what if 
any additional requirements would be necessary to satisfy them beyond the 

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

From:   Steve Battle <>
To:     "" <>, 
Date:   03/10/2013 11:21 AM
Subject:        Re: linking from resource -> container ..

This is a small example to show how issue-21 (Reverse Membership 
Predicates) differs from the idea of linking from resource to container 
(the current subject). In other words, directionality and navigability are 

In the example below, the created LDP Resource itself does not contain a 
link to the container, but the membership data in the LDP Container 
includes a link with the resource as subject and the container as object.

Issue-21 is not about navigability, but selecting the best way to express 
the relationship between container and member. If the application relates 
to SKOS concept schemes and concepts, then the most natural representation 
is the reverse Membership Predicate skos:inScheme.

Container BEFORE

<> a ldp:Container, skos:ConceptScheme;
skos:prefLabel "Subject Heading";
ldp:reverseMembershipPredicate skos:inScheme.

POSTed content

<> a skos:Concept;
skos:prefLabel "Outer Space".

Container AFTER

<> a ldp:Container, skos:ConceptScheme;
skos:prefLabel "Subject Heading";
ldp:reverseMembershipPredicate skos:inScheme.
</entry1> a skos:Concept;
skos:inScheme <>.


On 8 Mar 2013, at 07:22, Arnaud Le Hors <> wrote:

Hi Roger, 
Could you show us how you would modify one of the examples in the spec so 
that it provides what you want? 
Arnaud  Le Hors - Software Standards Architect - IBM Software Group

From:        Roger Menday <> 
To:        "" <>, 
Cc:        "" <> 
Date:        03/07/2013 05:19 PM 
Subject:        Re: linking from resource -> container .. 

hi Ashok, 

>> I am referring to links which resource can use to refer it's containers 
- i.e. a Networth can point to it's Assets and Liabilities containers.
> Roger, you said this on Monday's telcon also but I'm afraid I'm not 
getting it.
> A link by which a resource can refer to (one of its) containers would be 
a URI, correct?

The Networth resource is a URI and so are the Asset and Liability 
children, so, yes. 

> So, how is it different from a back link? 

The "Networth" class of resources says it is composed of its "Assets" and 
So, each "Networth" is the parent to a number Asset and Liability 

If I de-reference a Networth resource, the representation MUST contain 
information how it links (through outgoing link) to these children, 
because through these child container resources I can manipulate the 
Networth resource. 

OK, if it doesn't work this way, how else do you see the spec allowing 
that manipulation to happen ??


> Perhaps the difference is that a backlink assumes
> that the resource belongs to a single container and you are assuming 
that a resource
> can belong to several containers -- which I'm ok with.  Is that it?
> Ashok

Steve Battle

Steve Battle
Semantic Engineer


Sysemia Limited
Bristol & Bath Science Park, Dirac Crescent, Emerson's Green, Bristol BS16 
Registered in England and Wales. Company Number: 7555456


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 Wednesday, 13 March 2013 13:04:53 UTC