Re: How to avoid that collections "break" relationships (ISSUE-41)

On May 28, 2014, at 1:15 PM, "john.walker" <john.walker@semaku.com> wrote:
> 
> Hi Gregg, Markus,
>  
> I think this approach makes alot of sense,
>  
> Would it be useful to add to the wiki page a few common use cases of collections that we expect.
> On top of the "people who Alice knows" example, I can think of a few others:
> People
> [ hydra:property rdf:type ; hydra:object schema:Person ]
> People who know Alice
> [ hydra:property schema:knows ; hydra:object </alice> ]
> Things that link to Alice
> [ hydra:object </alice> ]
Interesting, looked at like this, it looks very much like Rubin's SPARQL Fragments.
> I could also imagine use cases where it would be useful to have multiple 'filters' applied to a collection e.g. people who Alice knows that like jazz music.
> Any thoughts on how that might be described?

There were some discussions before about using URI templates for filter and search operations. However, there may be a way to do more with the manages block. We could use hydra:propertyPath instead of hydra:property, or add other constraints, but it might just start looking like another SPARQL syntax if we aren't careful to keep our scope narrow.

Gregg

> Also would be nice to include some examples of what the results document could look like.
>  
> John
> 
> > On May 28, 2014 at 4:55 PM Gregg Kellogg <gregg@greggkellogg.net> wrote: 
> > 
> > 
> > On May 27, 2014, at 11:49 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: 
> > > 
> > >> On Tuesday, May 27, 2014 12:02 AM, Gregg Kellogg wrote: 
> > >>> On May 26, 2014, at 10:41 PM, "Markus Lanthaler" wrote: 
> > >>> The design I like most is the one that one I summarized as "Link to the 
> > >>> collection via a generic property". Specifically this one: 
> > >>> 
> > >>> </alice> hydra:hasCollection <alice/friends> . 
> > >>> 
> > >>> </alice/friends/> hydra:manages [ 
> > >>> [hydra|rdf]:property schema:knows ; 
> > >>> [hydra|rdf]:subject </alice> . 
> > >>> ] . 
> > >> 
> > >> Don't thing rdf:subject works, as it's domain is rdf:Statement, and I 
> > > don't think we want to 
> > >> invoke Reification, so best stick with hydra:property/subject. 
> > > 
> > > Good point. Shall we introduce a class that represents the range of 
> > > hydra:manages or is that not necessary in your opinion? 
> > 
> > That makes sense, and can be used as the (a) domain for hydra:subject/property/object. 
> > 
> > >> I also need hydra:object for some of the the reverse use-cases. 
> > > 
> > > Yep. I just tried to keep the examples simple. If we choose this approach, I 
> > > would strongly favor to also introduce hydra:object. 
> > > 
> > > 
> > >> I presume the domain of hydra:manages is hydra:Collection. 
> > > 
> > > Yeah (even though perhaps it actually make more sense to switch to something 
> > > like schema:domainIncludes for Hydra than using RDF's domain. In any case, 
> > > I've already updated the wiki to clarify what is meant. 
> > 
> > schema:domainIncludes has fuzzy semantics. For hydra, better stick with rdfs, where possible, and owl, where necessary (such as hydra:property). 
> > 
> > Do you think it's necessary to further describe supported collections using constraints? Perhaps this isn't necessary any more. 
> > 
> > > -- 
> > > Markus Lanthaler 
> > > @markuslanthaler 
> > > 
> > > 
> > > 
> >