W3C home > Mailing lists > Public > public-ldp@w3.org > March 2013

Re: A modest attempt to re-open ISSUE-20

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Thu, 14 Mar 2013 19:50:38 +0100
Message-ID: <CA+OuRR_=_nHgXakGxxEN8BDxZUv-=MK0ubcBRWGai_X0LfoQJA@mail.gmail.com>
To: Alexandre Bertails <bertails@w3.org>
Cc: James Leigh <james@3roundstones.com>, "public-ldp@w3.org" <public-ldp@w3.org>
Funny how James's solution is similar to one I toyed with before coming up
with the alternatived proposed in my initial mail.

First, I was planning to use a "special" URI to represent the entity
resource. I had the idea of calling it :create (given the correct default
namespace), so that it read :

  ldp:create a o:Bond ;
    o:value 20000 .

I though it looked good :) But I then moved away from this pattern as it
seemed like "lying" -- or at least, it seemed wrong to use a URI as an
indexical.


I guess I still prefer my alternative, as blank nodes are really that:
variables. They exist precisely to denote a resource whose URI we don't
know. I agree that it does not allow me to create hash-URI, which is a
shame.

But couldn't I just POST a description of the resource itself, and PUT
additional triples with hash-URIs afterwards, once I know the URI ?
(making simple things simple, and complex things possible?)

  pa



On Thu, Mar 14, 2013 at 6:21 PM, Alexandre Bertails <bertails@w3.org> wrote:

> On 03/14/2013 12:49 PM, James Leigh wrote:
> > On Thu, 2013-03-14 at 17:11 +0100, Pierre-Antoine Champin wrote:
> >> James,
> >>
> >>
> >> On Thu, Mar 14, 2013 at 3:07 PM, James Leigh <james@3roundstones.com>
> >> wrote:
> >>          On Thu, 2013-03-14 at 10:03 +0100, Henry Story wrote:
> >>          >
> >>          > The relevant section of the Turtle spec is section 6.3
> >>          > http://www.w3.org/TR/turtle/#relative-iri
> >>          >
> >>          >
> >>          > Notice that you cannot use NTriples to do what you want
> >>          either, since
> >>          > you cannot
> >>          > know when creating a resource what the URI of the created
> >>          resource is
> >>          > going to be.
> >>          > You would need to only use blank nodes in the graph
> >>          produced, which
> >>          > would be
> >>          > to say the least very awkward.
> >>
> >>
> >>
> >>          In Callimachus, when a resource is created there is no funny
> >>          base-uri
> >>          going on (we use the RDF model). Although we use sparql-update
> >>          format,
> >>          any RDF format would work equally well for us including
> >>          NTriples.
> >>
> >>          Lets calls the to-be-created resource URI the entity URI. All
> >>          the
> >>          triples that are to-be-inserted to the store must either have
> >>          a blank
> >>          node subject, have a subject URI of the entity URI, or have a
> >>          subject
> >>          URI of the entity URI plus a fragment identifier. This makes
> >>          it very
> >>          clear what the entity URI is.
> >>
> >>
> >> But it prevents you from POSTing an *incoming* graph to the entity
> >> resource...
> >>
> >> What if I want to create a person and state that "I know this
> >> person" ?
> >>
> >
> > In Callimachus, you would use two requests. The first one (POST) to
> > create this new person resource and a second request (PATCH) to update
> > another person with the statement "I know them". It's fairly easy and
> > makes sense when you treat triples as belonging to their subject
> > resource.
>
> I agree with this approach. For me, this is Linked Data modeling done
> right, and I would really like this group to generalize the notion of
> "treat[ing] triples as belonging to their subject resource".
>
> IMO, that should be the pattern that we'd encourage, along with the
> use of hash-URIs.
>
> Alexandre.
>
> >
> > Graphs are created/manipulated with a different set of requests and are
> > handled separately.
>
>
>
> >
> > Regards,
> > James
> >>
> >
> >
> >
> >
>
>
>
Received on Thursday, 14 March 2013 18:51:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC