W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2014

RE: How to avoid that collections "break" relationships

From: Jason Douglas <jasondouglas@google.com>
Date: Tue, 25 Mar 2014 16:44:03 +0000
Message-ID: <CAEiKvUAtBC+6MVPc-FGDHCv-UHyHZsopgr7w1ZsJTTu4r2_t7Q@mail.gmail.com>
To: markus.lanthaler@gmx.net, phayes@ihmc.us
Cc: public-hydra@w3.org, public-lod@w3.org, public-vocabs@w3.org
On Tue Mar 25 2014 at 9:36:21 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
wrote:

> On Tuesday, March 25, 2014 5:08 PM, Jason Douglas wrote:
> > 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.
>
> Jason, how is knows/collection different from Pat's :knowsList approach
> below? AFAICT they are exactly the same:
>

knows/collection would only list the collection metadata attributes like
current page, total number of pages, URL of the collection, etc. and not
the actual people values... those would still all be in the undecorated
knows.

it's a hack, i know, but it allows clients that don't know or care about
collection metadata to work naively as before.


>
>   schema:knows/collection :listPropertyOf schema:knows .
>
>   where :listPropertyOf has the semantic condition
>
>   aaa listPropertyOf bbb
>   xxx aaa ddd
>   ddd schema:itemListElement yyy
>
>   imply
>
>   xxx bbb yyy
>
> So
>
>   </markus> schema:knows/collection </markus/friends> .
>   </markus/friends> schema:itemList </pat>, </jason> .
>
> implies
>
>   </markus> schema:knows </pat>, </jason> .
>
>
> Pat proposal makes the semantics explicit whereas you seem to suggest to
> infer the semantics based on the URL's structure, which is against the
> principle of URI Opacity [1].
>
>
> [1] http://www.w3.org/TR/webarch/#uri-opacity
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
> ------------ Original Message ------------
> 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
>
>
>
>
>
>
>
>
Received on Tuesday, 25 March 2014 16:44:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:38 UTC