W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 3 Jun 2014 20:39:28 +0200
To: <public-hydra@w3.org>
Message-ID: <004101cf7f5b$2b5e5e30$821b1a90$@gmx.net>
On Thursday, May 29, 2014 3:53 PM, Gregg Kellogg wrote:
> On May 28, 2014, at 1:15 PM, "john.walker" wrote:
> > I think this approach makes alot of sense, 

Good. Is anybody in favor of another proposal?

> > Would it be useful to add to the wiki page a few common use cases of
> > collections that we expect.

I think that would blow up the page too much (we would have to do it for each proposal to make them comparable). But feel free to create a new page which evaluates various use cases specifically for this design.

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

Yep, I think it's quite flexible and powerful.

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

Yeah. It could perhaps be described as follows (pseudo-code):

     a Collection
     manages [
       { subject: /alice, property: knows },  ---> /alice knows ?member
       { property: likes, object: /jazz },    ---> ?member likes /jazz

Using propertyPath instead of just property would make this even more powerful as you could for example do things such as

     a Collection
     manages [
       { subject: /alice, property: knows },  ---> /alice knows ?member
       { propertyPath: [ livesIn, country ], object: /italy},
            ---> ?member livesIn (?location country /Italy)

The question is whether we shall allow both property and propertyPath or always require propertyPath. An alternative design would be to split propertyPath into "property" and "path" (or probably better still propertyPath to make it clearer what the path refers to):

       { property: country, propertyPath: [ livesIn ], object: /italy},
            ---> ?member livesIn (?location country /Italy)


> > Also would be nice to include some examples of what the results
> > document could look like.

Absolutely. I think you just assigned yourself an action :-) Could you please create such a wiki page?


Markus Lanthaler
Received on Tuesday, 3 June 2014 18:40:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC