Re: Interaction model vs data model

* Henry Story <henry.story@bblfish.net> [2013-01-24 13:54+0100]
> 
> On 24 Jan 2013, at 13:44, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
> 
> > hello all.
> > 
> > On 2013-01-24 13:32 , "Henry Story" <henry.story@bblfish.net> wrote:
> >>> I think that we are making only trivial statements about type if one
> >>> can't predict some opperational behavior from that type. The most
> >>> practical type I can imagine is one that tells me if POSTing RDF will
> >>> append it (LDPR) or submit a new element to a container (LDPC).  To
> >>> that end, I think that LDPC and LDPR are sibling resources with some
> >>> common ancestor. It's probably worth identifying that ancestor as it
> >>> has a few properties common to both LDPCs and LDPRs, namely that GET
> >>> gets you some relevant RDF and that it's defined by LDP.
> >> Exactly :-) Thanks for making this clear.
> >>> 
> >>> 
> >>>> For what it's worth, section 5.2.1 of the LDP spec [2] states that "A
> >>>> Linked Data Platform Container must also be a conformant Linked Data
> >>>> Platform Resource." I've always read that as meaning that an LDPC is
> >>>> an 
> >>>> LDPR.
> >>>> 
> >>>> What am I missing?
> >> I think it is possible that as things change and as we formalise things,
> >> we notice that there are incompatibilities in terms of operational
> >> behavior between different types of things that we had not noticed
> >> earlier. 
> >> It is pretty tricky. We may even find that new types of things start
> >> emerging,...
> > 
> > i think this kind of exercise might be very useful. however, it would be
> > unfortunate if our re-defined ontology would say that an LDPR is something
> > and that an LDPC is something else, and that both have a common ancestor.
> > i am simply saying this because in the REST community, the term "resource"
> > is very well established, and everything that has a URI is a resource.
> > thus, to say that we have LDPC "things" that have URIs but are not
> > resources certainly would cause quite a bit of confusion for readers of
> > the spec.
> 
> I agree. That would not be the way to go.
>  
> Perhaps ldp:Content would be a better name for whatever is not an 
> ldp:Container but is an ldp:Resource .
> 
>  ldp:Content rdfs:subClassOf ldp:Resource;
>      owl:disjointWith ldp:Container .

However LDPC, LDPR and their common parent end up being labeled in the
ontology, I note that the bug tracking use case implies that LDPCs and
LDPRs are not actually disjoint.

<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html#alternative-scenario-create-a-nested-container> [[
  :top-level-container rdfs:member :issue1234 .

  :issue1234 a oslc_cm:ChangeRequest;
        dcterms:identifier "1234";
        dcterms:type "a bug";
        dcterms:related :issue1235 ;
        oslc_cm:attachments :attachments123.
]]
has a top-level container, a created issue which is also a container,
and an attahment.

If I want the server to host another attachement, I can POST an
attachment-looking thing to :issue1234. If I want to change the type
from "a bug" to "a feature", can I PUT to :issue1234?  May the server
be so clever as to sort out :issue1234 POSTs into one of:
  hostable attachment data,
  appendable issue data,
  discardable other crap
?


> If one then had say an ldp:contains relation 
> 
>   ldp:contains rdfs:subPropertyOf rdfs:member ;
>         rdfs:domain ldp:Container .
> 
> then one could think of the ldp:contains relation
> forming a tree with ldp:Content elements as the leaves .
> 
> 
> 
> > 
> > cheers,
> > 
> > dret.
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 



-- 
-ericP

Received on Thursday, 24 January 2013 16:54:49 UTC