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

Re: How to avoid that collections "break" relationships

From: Jason Douglas <jasondouglas@google.com>
Date: Sat, 29 Mar 2014 00:02:22 +0000
Message-ID: <CAEiKvUDpJnb-A+1T2Eu6DmQDt4rjnFEP_hjVyi2E7o+MDLBshA@mail.gmail.com>
To: gregg@greggkellogg.net, public-vocabs@w3.org, public-hydra@w3.org, public-lod@w3.org
Cc: mhaschke@brox.de, vuk.milicic@eurecom.fr, markus.lanthaler@gmx.net, lindstream@gmail.com
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


>
> 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"
  }
}




> 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 Saturday, 29 March 2014 00:02:52 UTC

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