Re: How to avoid that collections "break" relationships

On Fri Mar 28 2014 at 5:43:51 PM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> On Mar 28, 2014, at 5:02 PM, Jason Douglas <jasondouglas@google.com>
> wrote:
>
>
>
> On Fri Mar 28 2014 at 1:17:49 PM, Gregg Kellogg <gregg@greggkellogg.net>
> wrote:
>
>> The conversation split between just the Hydra mailing list, and the wider
>> mailing list including Web Schemas and LOD.
>>
>> In my opinion, we have a way forward: For a generic Hydra interface use a
>> rdfs:seeAlso predicate to reference a void:Linkset annotated with the
>> predicate it relates to (based on Niklas' suggestion). For example, the
>> example we've been using might be described as follows:
>>
>> </markus> a foaf:Person;
>>   rdfs:seeAlso [
>>     a void:Linkset;
>>     void:subjectsTarget </markus>;
>>     void:objectsTarget </markus/friends>;
>>     void:linkPredicate foaf:knows
>>   ] .
>>
>> The resource at </markus/friends> is a hydra:Collection, but also
>> contains triples that assert the individual foaf:knows relations:
>>
>> </markus/friends> a hydra:Collection; hydra:member </gregg>, ...
>> </markus> foaf:knows </gregg> .
>>
>> In a schema.org variety, this might simply be done with a more direct
>> relationship:
>>
>> </markus> a schema:Person; rdfs:seeAlso </markus/friends> .
>> </markus/friends>  schema:about schema:knows .
>>
>> Then in the </markus/friends> resource:
>>
>> </markus/friends> a schema:ItemList; schema:itemListMember </gregg>, ...
>> </markus> schema:knows </gregg> .
>>
>
> [Aside] I appreciate re-using an existing Class, but I think ItemList was
> intended for a different use case than collections (I've given the same
> feedback to Sam).  It's a subclass of CreativeWork because it's for
> "editorialized" lists (top 10 list, playlists, etc.). I think we need
> something new like an actual Collection class in schema.org
>
>
> I think a Collection class would be great; it should also allow for
> pagination. This could be done in the scope of this proposal where specific
> guidance is given on how to separate entity definitions into collections,
> so that large numbers of relationships can be effectively managed.
>

+1


>
>
>> In the first (pure) example, the void:Linkset specifically relates
>> subects in </markus> with objects in </markus/friends> using the foaf:knows
>> predicate. An API client would know to dereference the </markus/friends> if
>> it is interested in following foaf:knows relationships.
>>
>> In the second example, a client knows which of possibly several
>> rdfs:seeAlso relationships are follow because each object is described as
>> being "about" whatever the predicate used within the ItemList uses. It's
>> less accurate than the void:Linkset, but seems more in keeping with the
>> simplicity of schema.org. A schema:seeAlso predicate might also be
>> useful.
>>
>
> I'm not sure I follow. So schema.org only (because, you know, namespaces
> ;-) would be something like this?
>
> {
>   "@context" : "http://schema.org",
>   "@type": "Person",
>   "@id": "markus",
>   "seeAlso" : {
>     "@type": "Collection",
>     "@id" : "markus/friends",
>     "member" : {
>        "@type" : "Person",
>        "@id" : "gregg"
>     },
>     "relation" : "knows"
>   }
> }
>
>
> The idea is to separate out the people Markus knows from the main
> definition of Markus. Markus knows a lot of people, and the list grows
> every day! There are likely other relationships Markus has that can be
> unbound (numbers of email messages, for example), and all of these are
> appropriate for using collections. For this example, I'll use two resources:
>
> {
>   "@context": "http://schema.org/",
>   "@id": "markus",
>   "@type": "Person",
>   "seeAlso": { "@id": "markus/friends; "about": "schema:knows"}
> }
>
> Then, at an <markus/friends>, the following:
>
> {
>   "@context": ["http://schema.org/", {
>     "knownBy": {"@reverse": "knows"}
>   },
>   "@id": "markus/friends",
>   "@type": "Collection",
>   "member": [
>     {"@id": "gregg"; "knownBy": "markus"},
>     ..
>   ]
> }
>
> (I'm presuming schema:Collection and schema:member have reasonable
> semantics, but consider them standins).
>
> This shows that the <markus> entity is extended using what's referenced
> from seeAlso. One such reference is <markus/friends> with an associated
> relationship of schema:knows. Following that reference yields a Collection
> containing references to the people Markus knows. I use a reverse
> relationship here to avoid @graph.
>

Thank you, now I get it.

What about the opposite case where the property from the member direction
already exists, but not the reverse of that.  For example, there's a
property pointing from a Reservation to a Restaurant, but not a Restaurant
to its Reservations.  In that case, if I'm describing the Restaurant and
want to point to its collection of Reservations, would there be a way to
refer to the reverse in the seeAlso.about slot?


> This should be equivalent to the following Turtle:
>
> <markus> a :Person; :seeAlso <markus/friends> .
> <markus/friends> :about schema:knows .
>
> <markus/friends> a :Collection; :member <gregg> .
> <markus> :knows <gregg> .
>
> The fact that <markus/friends> is the value of a seeAlso, and that it is
> about schema:knows is what would drive application logic to understand that
> this IRI can be dereferenced to find out more about who Markus knows. These
> lists could then be paginated to provide a large number of results to
> extend the knowledge base.
>
> Gregg
>
>  Gregg Kellogg
>> gregg@greggkellogg.net
>>
>> On Mar 25, 2014, at 11:55 AM, Vuk Milicic <vuk.milicic@eurecom.fr> wrote:
>>
>> Markus,
>>
>> OK.. this is quite similar to what we discussed in the Hydra CG (and what
>> LDP does):
>>
>>    </markus> a schema:Person ;
>>
>>    </markus/friends/>:manages [
>>       :subject </markus> ;
>>       :property schema:knows
>>    ] ;
>>
>> The thing I don't really like with these approaches is that you have to
>> peek
>> into the container to find out whether it contains/manages the information
>> you are interested in.
>>
>>
>> Conceptually, </marcus/friends> is not a container, but a class -- my
>> point from the beginning.
>> That RDF is basically equivalent to what I wrote in [1] using OWL, why
>> reinventing the wheel?
>>
>> [1] http://lists.w3.org/Archives/Public/public-lod/2014Mar/0111.html
>>
>> -
>> Vuk MIilcic
>> @faviki
>>
>>
>>
>