Re: How to avoid that collections "break" relationships

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.

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