On 26 March 2014 04:26, Pat Hayes <[email protected]> wrote: > > On Mar 25, 2014, at 11:29 AM, Markus Lanthaler <[email protected]> > wrote: > >> On Tuesday, March 25, 2014 5:00 PM, Pat Hayes wrote: >>> Seems to me that the, um, mistake that is made here is to use the same >>> property schema:knows for both the individual case and the list case. >> >> Exactly.. it is especially problematic if rdfs:range is involved. >> >> >>> Why not invent a new property for the list case, say :knowsList, and >>> add a relationship between them as an RDF triple: >>> >>> :knowsList :listPropertyOf schema:knows . >>> >>> where :listPropertyOf has the semantic condition >>> >>> aaa listPropertyOf bbb >>> xxx aaa ddd >>> ddd schema:itemLIstElement yyy >>> >>> imply >>> >>> xxx bbb yyy >> >> Yeah, that's very similar to an idea I had (but it wasn't so elegant). The >> issue is that you won't "discover" :knowsList if you look for schema:knows >> unless you infer the "xxx bbb yyy" triples. In other words, if you don't >> know :knowsList and thus ignore it, you would neither find the collection >> nor the schema:knows relationships. > > Hmm. I would be inclined to violate IRI opacity at this point and have a > convention that says that any schema.org property schema:ppp can have a > sister property called schema:pppList, for any character string ppp. So you > ought to check schema:knowsList when you are asked to look for schema:knows. > Then although there isn't a link in the conventional sense, there is a > computable route from schema:knows to schema:knowsList, which as far as I am > concerned amounts to a link.
In fact something very close to this was considered for the roles proposal I circulated yesterday, i.e. http://lists.w3.org/Archives/Public/public-vocabs/2014Mar/0111.html The idea was to define a URI template pattern e.g. http://schema.org/role/{propertyname} so that '/actor' would be shadowed by '/role/actor', and the latter used when describing a situation involving 3 entities (movie, role, person) rather than a binary relationship between movie and person. In this case so far we decided against introducing the complexity, but similar designs might prove appropriate for related problems. Dan
