Re: schema.org Roles design

sorry, 'itemref' was a typo, should have been 'itemid'.


On Wed, Mar 26, 2014 at 10:14 PM, Jason Douglas <jasondouglas@google.com>wrote:

> On Wed Mar 26 2014 at 1:59:47 PM, Jarno van Driel <jarno@quantumspork.nl>
> wrote:
>
>> Well if @id has the same role as 'itemref' then could there also please
>> be some info explaining how that works
>>
>
> How did itemref get into this?  That's a microdata-specific DOM-level
> mechanism and is totally different.
>
>
>
>> , because to be honest, I sort of understand the proposal but am confused
>> about @id/itemid. e.g. to me it seems @id functions the same way as
>> @resource does in RDFa, or at least that's how I read it.
>>
>> Wouldn't the Person linking back to the AmericanFootballRole create an
>> infinite loop?
>>
>
> Graphs have loops.
>
>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 26, 2014 at 9:47 PM, Jason Douglas <jasondouglas@google.com>wrote:
>>
>>> It does play the same role.  I wouldn't be surprised if there are subtle
>>> differences in the respective specs, though.
>>>
>>>
>>> On Wed Mar 26 2014 at 1:45:02 PM, Jarno van Driel <jarno@quantumspork.nl>
>>> wrote:
>>>
>>>> Quick question: is '@id' the same in JSON-LD as 'itemid' is in
>>>> Microdata?
>>>> Because I find it difficult to comprehend the functionality of '@id'.
>>>>
>>>>
>>>> On Wed, Mar 26, 2014 at 9:00 PM, Guha <guha@google.com> wrote:
>>>>
>>>>> See comments inline
>>>>>
>>>>>
>>>>> On Wed, Mar 26, 2014 at 12:15 PM, Gregg Kellogg <
>>>>> gregg@greggkellogg.net> wrote:
>>>>>
>>>>>> On Mar 26, 2014, at 9:37 AM, Dan Brickley <danbri@google.com> wrote:
>>>>>>
>>>>>> > At schema.org we have been working on a design for describing roles
>>>>>> > and contributions.
>>>>>> >
>>>>>> > I've just posted a discussion draft in the WebSchemas wiki. Please
>>>>>> take a look:
>>>>>> >
>>>>>> > Roles in Schema.org
>>>>>> > https://www.w3.org/wiki/WebSchemas/RolesPattern ->
>>>>>> > https://www.w3.org/wiki/images/b/b5/RolesinSchema.org.pdf
>>>>>>
>>>>>> Some comments on the draft:
>>>>>>
>>>>>> I think this is a really useful abstraction, but I do see some room
>>>>>> for improvement.
>>>>>>
>>>>>> I think adding date ranges to the role is conflating the role with an
>>>>>> event. Better to say that the Joe Montana is the quarterback during the
>>>>>> 1992 season of the 49ers by defining an event for the 1992 season. Jason
>>>>>> and Jean-Pierre made similar points, and I think that models better.
>>>>>>
>>>>>> One could look at anything with a temporal extent (including a
>>>>> proposition) as an event. It is not clear that buys us much. In fact,
>>>>> experience with Cyc shows that this can be confusing.  If you want, you can
>>>>> look at Role as a subclass of Event.
>>>>>
>>>>>
>>>>>> A Role seems to use different properties to describe the kind of role
>>>>>> ("position", "characterName", "graduationYear"). It might be possible to
>>>>>> simply subclass Role so that it's known the kind of role that's being
>>>>>> played, but a single property which defines this (ideally an entity, but
>>>>>> allowing a string) would be less ambiguous and would avoid falling into the
>>>>>> trap of not having considered all of the kinds of roles played. Similarly,
>>>>>> settling on a single property to reference the "agent" performing the role
>>>>>> might be better than using arbitrary properties from different classes
>>>>>> depending on where the role is referenced from. (In fact, you reference the
>>>>>> same role from different entities, so context can't really be used either).
>>>>>>
>>>>>> We don't want to be at either extreme. We don't want overly general
>>>>> slots like 'agent, 'performer' and 'object' as the only slots. Similarly,
>>>>> we don't want slots like quarterback, runningback, etc.
>>>>>
>>>>>
>>>>>> The schema for hasRole has domainIncludes and rangeIncludes reversed.
>>>>>>
>>>>>> In the appendix, you site the use of @context as a (temporary) means
>>>>>> of describing the range of hasRole to be an entity, not a literal. You
>>>>>> could eliminate the context by using an expanded form:
>>>>>>
>>>>>> {
>>>>>>   "@context": "http://schema.org/",
>>>>>>   "@type": "Movie",
>>>>>>   "name": "Ghostbusters", "hasRole": {
>>>>>>     "@type": "MovieRole",
>>>>>>     "@id": "movierole_678",
>>>>>>     "characterName": "Dr. Peter Venkman",
>>>>>>     "actor": {
>>>>>>       "@type": "Person",
>>>>>>       "name": "Bill Murray",
>>>>>>       "hasRole": {"@id": "movierole_678"}
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> But, I prefer to use a different property, as "hasRole" does not seem
>>>>>> to me to be symetric. Better than defining inverses of every property is to
>>>>>> define an inverse alias in the (forthcoming) context. For example:
>>>>>>
>>>>>>
>>>>> Agree.
>>>>>
>>>>>
>>>>>> {
>>>>>>   "@context": ["http://schema.org/", {
>>>>>>     "inRole": {"@reverse": "hasRole"}
>>>>>>   },
>>>>>>   "@type": "Movie",
>>>>>>   "name": "Ghostbusters", "hasRole": {
>>>>>>     "@type": "MovieRole",
>>>>>>     "@id": "movierole_678",
>>>>>>     "characterName": "Dr. Peter Venkman",
>>>>>>     "actor": {
>>>>>>       "@type": "Person",
>>>>>>       "name": "Bill Murray",
>>>>>>       "inRole": "movierole_678"
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> This uses the same property "hasRole", but defines a reverse term
>>>>>> which will expand, flatten or transform to RDF using the inRole property.
>>>>>>
>>>>>> Great to see progress on this issue!
>>>>>>
>>>>>> Gregg
>>>>>>
>>>>>> >> From the wiki, "For example, when we say that a Person was an
>>>>>> actor in
>>>>>> > a Movie, we might want to mention their characterName too. When we
>>>>>> say
>>>>>> > that a SportsTeam has a Person as an athlete, we might want to
>>>>>> mention
>>>>>> > the position that they play, or the time period in which they
>>>>>> > fulfilled that role.".
>>>>>> >
>>>>>> > I freely acknowledge that PDF isn't the best way to share
>>>>>> markup/code
>>>>>> > snippets and will copy those into Wiki. However we wanted to get the
>>>>>> > draft out asap.
>>>>>> >
>>>>>> > Here's a quick example extracted from the doc, expressed in JSON-LD.
>>>>>> > We want to elaborate on a basic description, so here is the mostasic
>>>>>> > version first, followed by the Role-based richer version:
>>>>>> >
>>>>>> > {
>>>>>> > "@context": "http://schema.org/",
>>>>>> > "@type": "AmericanFootballTeam",
>>>>>> > "name": "San Francisco 49ers",
>>>>>> > "athlete": {
>>>>>> >   "@type": "Person",
>>>>>> >   "name": "Joe Montana"
>>>>>> > }
>>>>>> > }
>>>>>> >
>>>>>> > Extended version using Role:
>>>>>> >
>>>>>> > {
>>>>>> >   "@context": "http://schema.org/",
>>>>>> >   "@type": "AmericanFootballTeam",
>>>>>> >   "name": "San Francisco 49ers",
>>>>>> >   "hasRole": {
>>>>>> >       "@type": "AmericanFootballRole",
>>>>>> >       "@id": "role321",
>>>>>> >       "startDate": "1979",
>>>>>> >       "endDate": "1992",
>>>>>> >       "position": "Quarterback",
>>>>>> >       "athlete": {
>>>>>> >               "@type": "Person",
>>>>>> >               "name": "Joe Montana",
>>>>>> >               "hasRole": "role321"
>>>>>> >       }
>>>>>> >   }
>>>>>> > }
>>>>>> >
>>>>>> > Effectively we interpose a new node in the graph. Instead of
>>>>>> >
>>>>>> > SanFrancisco49ers ---athlete---> JoeMontana
>>>>>> >
>>>>>> > We have
>>>>>> >
>>>>>> > SanFrancisco49ers --hasRole---> [role321] --athlete---> JoeMontana.
>>>>>> >
>>>>>> > There are a few nearby designs that may be worth discussion here. If
>>>>>> > we wanted to make things simpler for publishers, we could remove the
>>>>>> > hasRole reference from JoeMontana back to the Role. However this
>>>>>> also
>>>>>> > makes it harder for consuming applications to understand Role-based
>>>>>> > modeling across all domains. Another approach would be to use
>>>>>> > different property names for relating the 'subject' and 'predicate'
>>>>>> > entities. The appendix in the full proposal document elaborates on
>>>>>> > some of these options. I should also note for those of you using the
>>>>>> > JSON-LD playground or other generic tools that the above markup
>>>>>> needs
>>>>>> > some tweaks, since schema.org doesn't yet publish a @context file.
>>>>>> > Again, the document has details of a workaround.
>>>>>> >
>>>>>> > Please take a look. This is quite an important spec for schema.orgas
>>>>>> > it has impact across all domains, so it is important to find the
>>>>>> right
>>>>>> > balance between ease of adoption for publishers, expressivity, ease
>>>>>> of
>>>>>> > processing etc.
>>>>>> >
>>>>>> > cheers,
>>>>>> >
>>>>>> > Dan
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>