- From: Jason Douglas <jasondouglas@google.com>
- Date: Sat, 29 Mar 2014 01:20:23 +0000
- To: gregg@greggkellogg.net
- Cc: public-vocabs@w3.org, public-hydra@w3.org, public-lod@w3.org, mhaschke@brox.de, vuk.milicic@eurecom.fr, markus.lanthaler@gmx.net, lindstream@gmail.com
- Message-ID: <CAEiKvUBLm9izZU5Qg6gf6LhDmFEtp3NPGYpdfZP-qPMvrcqtFQ@mail.gmail.com>
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 >> >> >> >
Received on Saturday, 29 March 2014 01:20:54 UTC