Re: ldp:contains characteristics

> Basically -- is it ever possible to have two different contains
ldp:contain the same resource?  One way that might happen is if
ldp:contains was used as the object of ldp:hasMemberRelation and the
membershipResource was set to some random container. An Indirect container
would make that even more messy, as you could assert ldp:contains about
random resources.  Nothing in the spec (that I can see) forbids that...

> So intent ... I was only part of the WG at the end, so certainly do not
claim any authority on the topic, but my understanding is that the intent
was that only one container should contain a resource.  Thus
InverseFunctional seems correct... if ?x ldp:contains ?y ; ?z ldp:contains
?y then ?x owl:sameAs ?z
> And then any attempt to use ldp:contains in a ldp server like above
should result in an error.

I'm hearing two different things here.

First: that there is a global constraint such that a resource may be the
object of ldp:contains statements with at most one unique subject.

Second: that a server is in error if it contains a resource in more than
one container.

The former seems to me to lead to potentially nasty identity issues of the
type Ben describes. It seems wisely avoided both in the spec and in the
turtle representation of the LDP ontology. The latter seems sufficient to
come to the conclusion "any attempt to use ldp:contains in a ldp server
like above should result in an error", though this also seems
underspecified in the actual text.

- Tom


On Mon, Apr 4, 2016 at 8:14 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
>
> On Mon, Apr 4, 2016 at 10:29 AM, Benjamin Armintor <armintor@gmail.com>
> wrote:
>
>>
>> 1. There is a recommendation that HTTP PUT SHOULD NOT update containment
>> triples (5.2.4), but no analogous recommendation for HTTP PATCH (5.2.7). Is
>> this an intentional ambiguity, an oversight, or considered unnecessary as
>> containment triples are server-managed?
>>
>
> Seems like an oversight to me. The intent (I believe) is that containment
> triples SHOULD NOT be able to be modified by client's requests directly,
> but reflect the results of creation and deletion events.
>
>
>> 2. The recommendation on HTTP PUT for ldp:contains suggests that it is
>> intended to be created only on resource creation, and thus be unique for
>> the object of the containment triple - that is, ldp:contains might be
>> (perhaps SHOULD be, following 5.2.4) understood as
>> an owl:InverseFunctionalProperty. Is that a reasonable interpretation of
>> the spec?
>>
>
> Hrm.  The answer to this is the answer to 3, as
> owl:InverseFunctionalProperty has exactly the semantics described below,
> no?
>
> Basically -- is it ever possible to have two different contains
> ldp:contain the same resource?  One way that might happen is if
> ldp:contains was used as the object of ldp:hasMemberRelation and the
> membershipResource was set to some random container. An Indirect container
> would make that even more messy, as you could assert ldp:contains about
> random resources.  Nothing in the spec (that I can see) forbids that...
>
> So intent ... I was only part of the WG at the end, so certainly do not
> claim any authority on the topic, but my understanding is that the intent
> was that only one container should contain a resource.  Thus
> InverseFunctional seems correct... if ?x ldp:contains ?y ; ?z ldp:contains
> ?y then ?x owl:sameAs ?z
> And then any attempt to use ldp:contains in a ldp server like above should
> result in an error.
>
>
> Would love to hear other opinions.
>
> Rob
>
>
> 3. I realize that this is contingent on the answers to the above as well
>> as some implementation concerns, but how do people think this is affected
>> by what OWL refers to as the "unique names" assumption (
>> https://www.w3.org/TR/owl-ref/#IndividualIdentity)? Is the presence of
>> more than one statement ?x ldp:contains <foo> a consistency problem, or an
>> implication that all ?x are identifiers of the same resource?
>>
>
>
>
>
>
>>
>>
>> Thanks for your thoughts,
>>
>> Ben
>>
>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>