W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

Re: Inverse properties, was: Re: Socialnetworks of a person or organization

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Mon, 14 Apr 2014 14:05:27 -0400
Message-ID: <CAGR+nnG5R2D5pzJib9fLT0w-oVy=OWFL7_PeMbfEiO_5dGcBKw@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Martin Hepp <martin.hepp@ebusiness-unibw.org>, Dan Brickley <danbri@google.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, W3C Web Schemas Task Force <public-vocabs@w3.org>, Guha Guha <guha@google.com>
On Mon, Apr 14, 2014 at 1:30 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> On Apr 14, 2014, at 10:16 AM, martin.hepp@ebusiness-unibw.org wrote:
> > Hi Gregg,
> > Thanks for your very interesting proposal! As far as I understand,
> however, this would mean that we will have to define new names for the
> inverse variant of each property - not in the vocabulary, but in the
> schema.org context specification. If that is correct, I think this is
> only a second-best solution if we could not achieve an update of the
> Microdata specification. This for the following reasons:
> >
> > 1. For using the reverse form of a property in Microdata, one would have
> to use the special name for the inverse variant, while in JSON-LD, RDFa,
> and Turtle, we would use the same name for both directions.
> Well, in this regard, Microdata is much like Turtle. You could always
> create another item with the same @itemid to put it in the subject
> position. It's not as useful as the RDFa @rev property, but this needs to
> be weighed against the cost of updating the syntax. (We debated adding a
> reverse operator to Turtle in the last update, but it was rejected by the
> WG. The thought was a separate group might come together to create a "super
> Turtle/TriG", which could address many other useful markup cases).
> I'm not totally opposed to defining a Microdata extension for this, I'm
> just looking for a more minimal way to achieve the desired effect. Adding
> more attributes will make it more confusing for developers, whereas using
> guidance from the schema.org documentation on how to reverse the property
> direction using an alias may be simpler for developers to understand. IMO,
> most serious HTML markup is done using RDFa, anyway, so we're really just
> trying to incrementally make Microdata more useful.

This was my initial reaction too. Microdata was designed to be a simpler
alternative to RDFa, but we're talking about making it closer to RDFa and
in doing so, we're defeating its purpose of being simple. There is also the
argument that this kind of reverse property feature (like additionalType)
are available in other formats. We keep bending microdata/schema.org to
support features it was originally designed for, features which are
available in JSON-LD and RDFa.

> While JSON-LD supports the use of @reverse in node definitions, this is
> really to have an unambiguous way to expand the data; reasonable use would
> create a term definition using @reverse, so having this worked out by
> schema.org in advance would be a good thing. Of course, JSON-LD allows a
> term to be defined within the scope of the document, which Microdata does
> not.
> > 2. Some properties in schema.org have names that do not clearly
> indicate the default direction (e.g. creator means hasCreator, but could
> also be read as isCreatorOf) or that cannot be simply modified by is* or
> has* prefixes (like  http://schema.org/mentions) in an algorithmic way.
> This would mean we have to manually create and maintain the names for the
> inverse variants, which is what I wanted to avoid at any cost.
> I think the range and domain of creator make this clear to anyone who
> looks at the property definitions. Maybe it's a difference between English
> and German, but to to me, "creator" identifies the creator of a thing, and
> would not make as much sense as the property of a Person; "created" would
> work, but "isCreatorOf" makes it clearer for everyone. Of course, there are
> more ambiguous property names.

We should also consider a prefix-based convention like
itemprop="rev-author" or itemprop="rev-alumni". It eliminates the need to
maintain a custom list of reverse properties and make the processing
trivial since properties are CamelCase, and it's easy to strip the prefix
and reverse the relation.


> Gregg
> > So I still think that updating the Microdata spec is the preferred way
> to go.
> >
> > Martin
> >
> >
> >
> > On 14 Apr 2014, at 18:50, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> >
> >> I've been thinking about updates to the Microdata to RDF note [1] as
> well. In particular, abandoning the registry [2], which rapidly becomes
> outdated, and making use of the JSON-LD context, which one day soon (?)
> will show up at http://schema.org. One opportunity this might give us is
> to use @reverse term definitions in the JSON-LD context as the value of an
> @itemprop. If schema.org defined and supported such term definitions,
> this would provide a mechanism to get the effect of reverse properties
> without needing to change Microdata.
> >>
> >> This works well for Microdata when interpreted as RDF, but is more
> problematic in the original transformation to Microdata JSON, where the
> data model is that of a tree, and not a graph. I'm sure it could be done,
> but it does provide some challenges to the processing algorithm, whereas
> doing this in the context of an RDF transformation is more natural.
> >>
> >> The example from the Wiki, a schema.org context could assert the
> following term:
> >>
> >> {
> >> "@context": {
> >>   "@vocab": "http://schema.org/",
> >>   "isCreatorOf": {"@reverse": "creator"},
> >>   ...
> >> }
> >> }
> >>
> >> You could then use this in microdata as follows:
> >>
> >> <div id="creator" itemprop="creator" itemscope itemtype="
> http://schema.org/Person">
> >>      <span itemprop="name">William Shakespeare</name>
> >>      <link itemProp="isCreatorOf" href="
> http://www.freebase.com/m/0yq9mqd">
> >> </div>
> >>
> >> In a way, this is like defining reverse properties, except that it does
> not confuse the vocabulary, but really just exists as a syntactic shortcut.
> >>
> >> This would also be useful to describe @itemprop values as being in a
> list or not, which may be useful for properties such as event,
> itemListElement and recipeInstructions, if the schema.org JSON-LD context
> made use of the @container: @list term definition.
> >>
> >> While we're at it, we could re-visit the need for md:item in the RDF
> transformation to keep all top-level @itemscope entries in order. This was
> a relic from the original RDF transformation in Microdata that in
> retrospect, I think provides little value in an RDF interpretation.
> >>
> >> IMO, the Microdata JSON model is not as useful as the RDF model for use
> with schema.org, so focusing on improving the transformation of Microdata
> to RDF makes more sense, and more closely aligns it with JSON-LD and RDFa.
> >>
> >> Gregg Kellogg
> >> gregg@greggkellogg.net
> >>
> >> [1] http://www.w3.org/TR/microdata-rdf/
> >> [2] http://www.w3.org/ns/md
> >>
> >> On Apr 14, 2014, at 7:57 AM, martin.hepp@ebusiness-unibw.org wrote:
> >>
> >>> I just added eight markup examples of how useful a new keyword for
> reverse properties in Microdata would be:
> >>>
> >>>
> https://www.w3.org/wiki/WebSchemas/InverseProperties#Examples_and_Use_Cases
> >>>
> >>> Best
> >>> Martin
> >>>
> >>> -----------------------------------
> >>> martin hepp  http://www.heppnetz.de
> >>> mhepp@computer.org          @mfhepp
> >>>
> >>>
> >>
> >>
> >

Received on Monday, 14 April 2014 18:05:58 UTC

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