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

RE: How to avoid that collections "break" relationships

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 25 Mar 2014 18:40:48 +0100
To: "'Peter F. Patel-Schneider'" <pfpschneider@gmail.com>, <public-hydra@w3.org>, <public-lod@w3.org>, "'W3C Web Schemas Task Force'" <public-vocabs@w3.org>
Message-ID: <011501cf4851$5dfebc40$19fc34c0$@lanthaler@gmx.net>
On Tuesday, March 25, 2014 5:49 PM, Peter F. Patel-Schneider wrote:
> Let's see if I have this right.
> 
> You are encountering a situation where thenumber of people Markus knows
> is too big (somehow).  The proposed solution is to move this information
> to a separate location. I don't see how this helps in reducing the size
> of the information, which was the initial problem.

Cynical as usual :-) Let's just assume that the vast majority of the clients aren't interested in Markus' friends but just in information about him. Thus, they shouldn't have to process megabytes of friend relationships that they are to be ignoring anyway. Those few clients that are interested in those relationships, however, need a mechanism to find them.


> Splitting this information into pieces might help. schema.org, along
> with just about every other RDF syntax, doesnot require that all the
> information about aparticularentity is in the same spot. The problem
> then is to ensure that all the information is accessed together.
> 
> schema.org, somewhat separate from other RDF syntaxes, does have
> facilities for this.  All you needto do is to set up multiple pages,
> for example .../markus1 through.../markusn
> and on each of these pages include schema.org markup withcontent like
> <.../markusi> schema:url <.../markus>

I'm still wondering what schema:url is actually for and how it relates to Microdata's itemid, RDFa's resource and JSON-LD's @id... but that's a separate discussion.


> <.../markus> schema:knows <.../friendi1>
> ...
> <.../markus> schema:knows <.../friendimi>
> Then on .../markus you have
> <.../markus> schema:url <.../markus1>
> ...
> <.../markus> schema:url <.../markusn>
> (Maybe schema:sameAs is a better relationshipto use here, but they both
> should work.)

Yeah, this would of course work, but it doesn't tell the client at all why it should follow schema:url links to /markus{n}. The same is more or less true abut schema:sameAs.


--
Markus Lanthaler
@markuslanthaler



> Voila! (With the big provisio that I have no idea whether the schema.org
> processors actually dothe right thing here, asthere is no indication of
> what they do do.)
> 
> peter
> 
> PS:  LDP??

Linked Data Platform: http://www.w3.org/TR/ldp/

 
> On 03/24/2014 08:24 AM, Markus Lanthaler 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 17:41:29 UTC

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