On Mar 26, 2014, at 4:33 PM, エリクソン トーレ <[email protected]> wrote:
> Alternative suggestion from the spectator seat:
>
>> 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.
>
> </markus> a schema:Person ;
> rdfs:seeAlso </markus/friends/> .
> </markus/friends/> foaf:topic schema:knows .
>
> And in </markus/friends/> (or its redirection target):
>
> </markus> schema:knows </alice>,
> ...
> </zorro> .
>
> Replace foaf:topic with appropriate schema: properyy if necessary.
That's an interesting idea; in a JSON-LD representation, it might look like the
following:
{
"@id": "/markus",
"@type": "schema:Person",
"rdfs:seeAlso": {
"@id": "/markus/friends",
"foaf:primaryTopic": "schema:knows"
}
}
{
"@id": "/markus/knows",
"@type": "hydra:Container",
"hydra:member": "/gregg"
}
The only problem I see from a Linked Data perspective is that </markus/friends>
appears to be defined in the </markus> node definition, so it wouldn't be
obvious that you would do a further redirection to get the container.
Gregg
> Tore
