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

Re: metadata about relationships

From: Dan Brickley <danbri@danbri.org>
Date: Thu, 23 Feb 2012 22:01:54 +0100
Message-ID: <CAFfrAFqXA9fXhbjY+aE3nZmGcqwUaAEEpAC=iL3J5yujNaxrRQ@mail.gmail.com>
To: Jason Douglas <jasondouglas@google.com>
Cc: Will Norris <will@willnorris.com>, public-vocabs <public-vocabs@w3.org>
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.

cheers,

Dan
Received on Thursday, 23 February 2012 21:02:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:59 GMT