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

Hi Gregg,


> On May 29, 2014 at 3:52 PM Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
>  On May 28, 2014, at 1:15 PM, "john.walker" < john.walker@semaku.com
> <mailto: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
> >                o [ hydra:property rdf:type ; hydra:object schema:Person ]
> >          * People who know Alice
> >                o [ hydra:property schema:knows ; hydra:object </alice> ]
> >          * Things that link to Alice
> >                o [ hydra:object </alice> ]
> > 
> >  > Interesting, looked at like this, it looks very much like Rubin's SPARQL
> >  > Fragments.
> 

Yes, that's very true. Any reason why an LD Fragments API could not be described
with Hydra?

> 
>      > >          *
> >                o 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.
> 

Difference for me is that the client is not using the syntax to request a
certain collection dynamically, instead the server is advertising what
collections are available by describing them i.e. why do these things belong
together in this collection.

Perhaps SPIN SPARQL syntax could be re-used.

John

> 
>  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
> >      > <mailto:gregg@greggkellogg.net> > wrote:
> >      >
> >      >
> >      > On May 27, 2014, at 11:49 PM, "Markus Lanthaler" <
> >      > markus.lanthaler@gmx.net <mailto: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
> >      > >
> >      > >
> >      > >
> >      >
> > 
> >  >