Re: How to avoid that collections "break" relationships

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

Received on Thursday, 27 March 2014 12:28:04 UTC