W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2014

Re: How to avoid that collections "break" relationships

From: Sam Goto <goto@google.com>
Date: Mon, 31 Mar 2014 11:35:03 -0700
Message-ID: <CAMtUnc6Vgs8=ZX4eyRrNvLrbpqgU_Y=XxTkdvvC=kcWdN4g7ww@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Jason Douglas <jasondouglas@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>, "public-hydra@w3.org" <public-hydra@w3.org>, Linked Data community <public-lod@w3.org>, mhaschke@brox.de, vuk.milicic@eurecom.fr, Markus Lanthaler <markus.lanthaler@gmx.net>, lindstream@gmail.com
On Fri, Mar 28, 2014 at 5:43 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.
>

Just on the record, I understand how ItemList is a hack (because it extends
CreativeWork), I don't personally mind a brand new Collection class.


>
>
>> 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
>>
>>
>>
>
Received on Monday, 31 March 2014 18:35:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:38 UTC