How to avoid that collections "break" relationships

schema:knows can be multi-valued so it's already a "collection" of sorts.

Would it be correct to summarize your question as, how do we enable
"mechanical" features like addressability and pagination to a value
collection in a way that doesn't interfere with its semantics (i.e., change
the range)?

For a different, but related, use case I was finding it desirable to have a
general property instance annotation mechanism.  In the process, I was
drawn to the idea of inventing syntactic hack for these meta descriptions.
 Any alternative approach seemed to involve abstractions so obtuse to be
unusable.  So something like:

knows/collection --> </markus/friends>

that could live alongside the existing knows.  As there precedent for
something like this?  Surely this can't be the first time this has been
desired...

-jason

On Mon Mar 24 2014 at 8:25:58 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
>
>
>
>
>
>