- From: John Arwe <johnarwe@us.ibm.com>
- Date: Wed, 13 Mar 2013 09:04:12 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <OFEC9D87A5.177D9643-ON85257B2D.00471107-85257B2D.0047CE08@us.ibm.com>
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 above. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Steve Battle <steve.battle@sysemia.co.uk> To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 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 different. 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 <>. Steve. On 8 Mar 2013, at 07:22, Arnaud Le Hors <lehors@us.ibm.com> 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? Thanks. -- Arnaud Le Hors - Software Standards Architect - IBM Software Group From: Roger Menday <roger.menday@uk.fujitsu.com> To: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org> 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 "Liabilities". So, each "Networth" is the parent to a number Asset and Liability children. 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 ?? Roger > 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 E-mail: steve.battle@sysemia.co.uk Web: www.sysemia.com Sysemia Limited 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 Wednesday, 13 March 2013 13:04:53 UTC