Re: How to avoid that collections "break" relationships

I find that so awkward since :knows is already a repeated property.  Now we
have denormalized semantics and queries have to look at both properties...
and the only gain is the metadata about pagination.  That's why I prefer an
orthogonal mechanism like knows/collection for just the metadata.

On Tue Mar 25 2014 at 9:01:33 AM, Pat Hayes <phayes@ihmc.us> wrote:

> Seems to me that the, um, mistake that is made here is to use the same
> property schema:knows for both the individual case and the list case. Why
> not invent a new property for the list case, say :knowsList, and add a
> relationship between them as an RDF triple:
>
> :knowsList :listPropertyOf schema:knows .
>
> where :listPropertyOf has the semantic condition
>
> aaa listPropertyOf bbb
> xxx aaa ddd
> ddd schema:itemLIstElement yyy
>
> imply
>
> xxx bbb yyy
>
> Which can be published as a reference in the home document for the URL for
> :listPropertyOf , but implemented by whatever code anyone finds handy.
>
> Pat Hayes
>
> On Mar 24, 2014, at 10:24 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
> wrote:
>
> > Hi all,
> >
> > We have an interesting discussion in the Hydra W3C Community Group [1]
> > regarding collections and would like to hear more opinions and ideas. I'm
> > sure this is an issue a lot of Linked Data applications face in practice.
> >
> > Let's assume we want to build a Web API that exposes information about
> > persons and their friends. Using schema.org, your data would look
> somewhat
> > like this:
> >
> >  </markus> a schema:Person ;
> >            schema:knows </alice> ;
> >            ...
> >            schema:knows </zorro> .
> >
> > All this information would be available in the document at /markus
> (please
> > let's not talk about hash URLs etc. here, ok?). Depending on the number
> of
> > friends, the document however may grow too large. Web APIs typically
> solve
> > that by introducing an intermediary (paged) resource such as
> > /markus/friends/. In Schema.org we have ItemList to do so:
> >
> >  </markus> a schema:Person ;
> >            schema:knows </markus/friends/> .
> >
> >  </markus/friends/> a schema:ItemList ;
> >            schema:itemListElement </alice> ;
> >            ...
> >            schema: itemListElement </zorro> .
> >
> > This works, but has two problems:
> >  1) it breaks the /markus --[knows]--> /alice relationship
> >  2) it says that /markus --[knows]--> /markus/friends
> >
> > While 1) can easily be fixed, 2) is much trickier--especially if we
> consider
> > cases that don't use schema.org with its "weak semantics" but a
> vocabulary
> > that uses rdfs:range, such as FOAF. In that case, the statement
> >
> >  </markus> foaf:knows </markus/friends/> .
> >
> > and the fact that
> >
> >  foaf:knows rdfs:range foaf:Person .
> >
> > would yield to the "wrong" inference that /markus/friends is a
> foaf:Person.
> >
> > How do you deal with such cases?
> >
> > How is schema.org intended to be used in cases like these? Is the above
> use
> > of ItemList sensible or is this something that should better be avoided?
> >
> >
> > Thanks,
> > Markus
> >
> >
> > P.S.: I'm aware of how LDP handles this issue, but, while I generally
> like
> > the approach it takes, I don't like that fact that it imposes a specific
> > interaction model.
> >
> >
> > [1] http://bit.ly/HydraCG
> >
> >
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >
> >
> >
> >
> >
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 home
> 40 South Alcaniz St.            (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile (preferred)
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>
>