Re: How to avoid that collections "break" relationships

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.


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

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

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 16:49:41 UTC