Re: sub/super (Event, Organization, Place, CreativeWork etc.)

On 03/29/2015 10:16 PM, Dan Brickley wrote:
> On 29 March 2015 at 11:45, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:
>> Hello,
>>
>> Currently schema.org has many properties for sub/super relationships
> 
> What exactly do you mean by 'sub/super'? For example, you have
> included 'member' / 'memberOf', but not for example
> http://schema.org/alumni and http://schema.org/alumniOf, can you
> articulate the intuition that includes the one pair but not the other?
Very good question Dan!

I included member & memberOf mostly because Organization suggests
subOrganization property but to my understanding one supposed to use
memberOf to describe same relation but in reverse direction (schema.org
currently does NOT define superOrganization)

> 
>> # Event
>> * https://schema.org/subEvent
>> * https://schema.org/superEvent
>> ✗ defined as inverseOf
>>
>> # Organization
>> * https://schema.org/subOrganization
>> * no superOrganization!
>>
>> also
>> * https://schema.org/member
>> * https://schema.org/memberOf
>> ✓ defined as inverseOf
>>
>> # Place
>> * https://schema.org/containedIn
>> * no contains!
>>
>> # CreativeWork
>> * https://schema.org/hasPart
>> * https://schema.org/isPartOf
>> ✓ defined as inverseOf
>>
>> If one day schema.org will have types like Device or Project, they all
>> may also need some kind of sub/super relation. Some ideas I would like
>> to get some feedback on, even just +/-1
>>
>> 1) define generic sub / super properties (Thing)
>> 2) define them as schema:inverseOf
>> 3) define all subX / superX as rdfs:subPropertyOf sub / super
>> 4) define pairs of sub properties as schema:inverseOf (where missing)
> 
> The trouble with trying for a general theory of parts (c.f.
> http://plato.stanford.edu/entries/mereology/ ) is that it's a maze
> that you can innocently wander into, but never leave. But you're right
> that there is potential for a bit more common or documented structure
> here. Some of these above might be transititve, for example. If x is
> containedIn y, and y containedIn z, x is containedIn z. Same for
> isPartOf, and superEvent I'd argue, but not for memberOf. Most, but
> not all (memberOf) of the properties you have listed (isPartOf,
> containedIn, subOrganization, subEvent) are more or less homogenous in
> that they link things of the same type (creative works, places,
> organizations, events). Is this essential to your sense for which
> properties are sub/super? Is it essential that they don't allow loops?
> (again memberOf seems an outlier...)
I must admit not thinking about transitivity but it looks like it plays
important role here. It sounds like a good idea to keep sub/super
homogenous so defining range&domain as Thing could come tricky if people
used it on pairs of different sub types. Not sure if simple "Recommended
to use only with pairs of same types" would help. Especially that e.g.
Peninsula or Watershed (currently non defined sub types of Place) can
contain both City and Volcano.

Maybe this could just become a checkpoint when creating new types?
[ ] define sub/super (hasPart/isPartOf) properties if appropriate

Revising Organization and Place, would you see it useful to
* define superOrganization range&domain Organization
* define contains range&domain Place
* set them accordingly as inverseOf subOrganzation and containedIn

Possibly also tuning member/memberOf descriptions plus
* remove Organization from rangeIncludes of member
* remove Organization from domainIncludes of memberOf

It would recommend to use superOrganization instead of memberOf, just as
subOrganization instead of member. Not sure how now someone should
choose between subOrganization and member?

Oh, possibly also
* define department as subPropertyOf subOrganization

https://schema.org/subOrganization
"[...] See also: the more specific 'department' property."

As for *loops*, I can't think of an example where they would make sense.
Actually having loops with sub/super sounds somehow crazy!

HTH

> 
> Dan
> 
>> Cheers!
>>
>