W3C home > Mailing lists > Public > public-vocabs@w3.org > February 2012

Re: metadata about relationships

From: Jason Douglas <jasondouglas@google.com>
Date: Thu, 23 Feb 2012 13:40:47 -0800
Message-ID: <CAEiKvUCKWAFn5a4YFZ8p6rV+p7yAnb=k568tLTd6t=AHapr9Wg@mail.gmail.com>
To: Dan Brickley <danbri@danbri.org>
Cc: Will Norris <will@willnorris.com>, public-vocabs <public-vocabs@w3.org>
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
   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)?


> cheers,
> Dan
Received on Thursday, 23 February 2012 21:41:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:22 UTC