Re: metadata about relationships

On Thu, Feb 23, 2012 at 1:01 PM, Dan Brickley <danbri@danbri.org> wrote:

> On 23 February 2012 19:04, Jason Douglas <jasondouglas@google.com> wrote:
> > On Wed, Feb 22, 2012 at 8:05 AM, Will Norris <will@willnorris.com>
> wrote:
> >>
> >> (2nd attempt at sending, hopefully not a duplicate)
> >>
> >> In general, schema.org (or microdata in general?) seems to lack the
> >> ability to specify metadata for the relationship between items.  I'm
> curious
> >> if there is a general pattern for how this data should be modeled.
> >
> >
> > I think the simplest way to do this is to create a new type for the
> > relationship itself.  For example, rather than just have a price
> attribute,
> > Product points to an Offer object that has additional information like
> > availability window.
> >
> >>
> >> First a concrete example.  The Person type describes an individual
> person,
> >> and the EducationalOrganization type describes an actual education
> >> institution.  The 'alumniOf' property defines the existence of a
> >> relationship between a Person and an EducationalOrganization, but there
> is
> >> nowhere to provide additional metadata about that relationship.  Things
> like
> >> graduation year, field of study, etc.  Similarly for work information
> >> defined by either 'worksFor' or the more general 'affiliation'.  I know
> >> there has been discussion of including a CV schema which would likely
> >> address these specific examples, but this seems to be a more general
> problem
> >> with RDF style triples.  There's plenty of space to exhaustively define
> the
> >> subject and object, but no room to provide metadata around the
> predicate.
> >>  How is this type of thing handled in general?
> >
> >
> > This can be done in the same way as Offer with new types that describe a
> > specific kind of relationship such as EmploymentTenure, Marriage,
> > Performance, etc.  However, this kind of mediation comes at an
> > implementation complexity cost, which is why I believe it was used
> sparingly
> > in the initial release schema.org.  However, if enough use cases require
> > this additional data for a specific , I think the case could be made for
> > proposing changes to the schema.
> >
> >>
> >> And more specifically, how should it be handled in the above examples?
>  We
> >> include this metadata in Google+ profiles, and are able to include it
> >> cleanly in Portable Contacts, but I don't see how to represent it
> >> in schema.org.
>
> Yes, it's a classic tradeoff and not limited to RDF/Microdata. In some
> cases, creating an intermediate entity pays off, in others it's not
> worth the effort. You can see it in the difference between DBpedia and
> Freebase representations of "who stars in this film". DBpedia uses a
> simple 'starring' link from film to actor (details
> http://danbri.org/words/2011/05/10/675 ); in Freebase you get an
> intermediary node, which lets you hang other information like
> character name.
>
> There are some RDF-like graph data models e.g.
> https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model
> where edges in the graph can carry minor property/value annotations of
> their own, and this can be very handy. The W3C RDF WG are currently
> looking into how to handle properties of graphs, and graphs (including
> subgraphs) as first class describable objects. I'll pass Will's mail
> along to the group as motivation towards allowing such annotations in
> the next revision of RDF. But even if this went ahead, I'm not aware
> of any drafts proposing ways of handling such property annotations
> within concrete syntaxes like Microdata or RDFa. It's an intriguing
> idea but the devil is in the details, and it could in practice be
> quite complex, especially if embedded within mainstream HTML markup.
> The intermediary node approach is at least pretty well understood.
>

I think it would be nice if the complexity were incremental.... i.e., if my
site just has a simple list of actors, that's easy to markup, but if I have
a list of performances (actor + character + etc.), that's still possible.
 I could see at least two alternatives for that:

   1. Allow either Person or Performance as the expected type for
   Movie/actors
   2. Have two separate properties on Movie, one called actors, one called
   performances, each with the appropriate expected type

Any thoughts on which would be better (or other alternatives)?

-jason


> cheers,
>
> Dan
>