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

Re: How to avoid that collections "break" relationships

From: Vuk Milicic <vuk.milicic@eurecom.fr>
Date: Tue, 25 Mar 2014 16:29:54 +0100
Cc: public-hydra@w3.org, W3C Web Schemas Task Force <public-vocabs@w3.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, public-lod@w3.org
Message-Id: <7E6D2439-144C-43E4-9C0C-A226D20A9874@eurecom.fr>
To: Martynas Jusevičius <martynas@graphity.org>
Martynas,

From Markus' example I understood that </markus> and </alice> are instances of schema:Person (</markus> a schema:Person; schema:knows </alice>...), thus identifying people, not documents.

Vuk Milicic
@faviki


On 25 Mar 2014, at 14:10, Martynas Jusevičius <martynas@graphity.org> wrote:

> Vuk,
> 
> If URIs like </alice> identify documents, then your example treats documents as persons. In other words, you conflate information resources and real-world resources.
> 
> Martynas
> graphityhq.com
> 
> On Mar 25, 2014 11:35 AM, "Vuk Milicic" <vuk.milicic@eurecom.fr> wrote:
> Hi Markus,
> 
> How about this:
> 
> </markus/friends/> rdfs:subClassOf schema:Person .
> </alice> a </markus/friends/> .
> </markus> schema:knows </alice> .
> 
> 
> Vuk Milicic
> @faviki
> 
> 
> On 24 Mar 2014, at 16:24, 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
> >
> >
> >
> >
> >
> 
> 
> 
Received on Tuesday, 25 March 2014 15:30:47 UTC

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