On Mar 28, 2014, at 6:20 PM, Jason Douglas <[email protected]> wrote:
> > > On Fri Mar 28 2014 at 5:43:51 PM, Gregg Kellogg <[email protected]> > wrote: > On Mar 28, 2014, at 5:02 PM, Jason Douglas <[email protected]> wrote: > >> >> >> On Fri Mar 28 2014 at 1:17:49 PM, Gregg Kellogg <[email protected]> >> 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? In the void:Linkset case, I think it's clear that simply reversing the order of subjectsTarget and objectsTarget would have the effect of reversing the sense of the property. Definitely more challenging in the case of a simplified schema.org case, but certainly something that needs to be handled. In JSON-LD, a reverse term could be created for seeAlso (alsoSeen?) which would reverse it's direction too: { "@context": ["http://schema.org/";, { "alsoSeen": {"@reverse": "rdfs:seeAlso"} }, "@id": "restaurant/reservations/123", "@type": "Reservation", "alsoSeen": { "@id": "restaurant/reservations; "about": "schema:reservation"} } Then, at an <restaurant/reservations >, the following: { "@context": ["http://schema.org/";, { "reservedAt": {"@reverse": "schema:reservation"} }, "@id": "restaurant/reservations", "@type": "Collection", "member": [ {"@id": "restaurant/reservations/123"; "reservedAt": "restaurant"}, .. ] } In the <restaurant/reservations/123> entity, the seeAlso relationship is a reference from the Collection to the reservation and the Turtle would be the following: <restaurant/reservations/123> a schema:Reservation . <restaurant/reservations> rdfs:seeAlso <restaurant/reservations/123>; schema:about schema:reservation . <restaurant/reservations> a schema:Collection; schema:member <restaurant/reservations/123> . Anyway, that's one way it might be done. Gregg > 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 >> [email protected] >> >> On Mar 25, 2014, at 11:55 AM, Vuk Milicic <[email protected]> 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 >> >
