Re: How to avoid that collections "break" relationships

Hi Dan,

> On March 27, 2014 at 1:27 PM Dan Brickley <danbri@google.com> wrote:
>
>
> On 26 March 2014 04:26, Pat Hayes <phayes@ihmc.us> wrote:
> >
> > On Mar 25, 2014, at 11:29 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
> > 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
>

My understanding of the intended use of schema:rangeIncludes and
schema:domainIncludes was that it is intended to avoid the need to define some
synthetic union class of all classes in the range.

So today we might be able to say:

schema:knows schema:domainIncludes schema:Person

And next week we might decide to allow people to know their pets:

schema:knows schema:domainIncludes schema:Cat

Using this includes approach allows this to be done with minimal fuss.

Is it really intended usage to totally 'break' the semantics of the property by
using it to refer to an information resource that happens to be some
collection/list?

Cheers,
John