Re: Issue-71: the first bug tracking example

On 05/22/2013 11:14 AM, Henry Story wrote:
> On 22 May 2013, at 16:41, Arnaud Le Hors <> wrote:
>> Henry Story <> wrote on 05/22/2013 06:27:17 AM:
>>> ...
>>> I have no idea what you mean "define containers without forcing
>>> people to change their vocabulary".
>>> The question is what is the UC&R for this functionality? Where does
>>> it come from? What is the
>>> need? (I mean for the protocol)
>> This is about allowing people to expose existing data in which they have been using something like Nandana's bt:hasBugReport predicate or something similar without forcing them to change the representation of their data to use rdf:member.
> I don't see how we are forcing people to change their data given that the LDP spec
> is not finished and this is in flux.

Henry may have some crazy ideas from time to time, but I have to admit
that on this one, I'm on his side.

My biggest fear is LDP to become a mini-language whose semantics
(eg. container membership) would depend on an external domain
model. There should be *only one way* to speak about membership.

I'm a bit puzzled by the argument "it's an easy one so let's add it"
to the spec. I believe that there is no need at all for such a feature
and as noted, there was no corresponding item in UC&R. I may be wrong,
but I'm not sure that people are desperately in need of such a feature
and if yes, it would always be possible to add it in the next version
of the spec, with very little cost.

Of course, if I had to vote on keeping or not this feature, I would
say 0 (I can live with it). But still, that makes the spec both more
complex and difficult to understand, while it should be simple and


>> I don't know that we have this requirement captured in our UC&R. If we don't we should fix this.
> The easiest way to fix this may be to be clearer about what these relations are doing
> first.
>>> The LDP spec is about GET, PUT, POST, DELETE. One whole section of
>>> the spec is about how those
>>> words are used in resources we call LDPCs . Fine. So it is quite
>>> reasonable to ask what the point of
>>> ldp:membershipPredicate is.
>> Yes, it is. But the reason is much simpler than what you seem to think and it has nothing
>> to do with validation.
> That's a pitty, because that's a good reason. I don't see why the LDP spec
> needs to otherwise add vocabulary for things that have nothing to do with
> adding resources to a container. People can add other relations to a container
> but what business is it of ours to specify it?
> It is clear from Roger Menday's "membershipObject" thread that these
> membershipXXX relations are completely orthogonal to the rdf:member-ship
> of a container. To use these relations in a way that would allow us to
> model things correctly one would end up with something like this:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <> a ldp:Container;
>     ldp:membershipSubject <#i>;
>     ldp:membershipOject ??? ;
>     ldp:membershipPredicate pets:has_pet .
> <#i> pets:has_pet <zaza#it>, <zara#it> .
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> so clearly here pets:has_pet has nothing to do with rdf:member anymore. It is
> doing something completely different. Not something that one needs be against,
> it is just orthogonal to rdf:member-ship of an LDPC.
> Let's then seperate concerns.
>>>   I gave above what seem two possible
>>> reasons for why it
>>> is needed with respect to POSTing. If you know the restrictions on
>>> the relation, you know what type
>>> of document you can or cannot POST. That still leaves room for a
>>> group such as RDF-Validation
>>> group [1] to crete a language to make such definitions machine
>>> parsable, but one could argue for
>>> the inclusion of those relations on those grounds.
>>> Henry
>>> [1]
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> Social Web Architect

Received on Wednesday, 22 May 2013 18:01:34 UTC