Skip to content
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.

Add reverse property #2

Closed
chaals opened this issue Feb 7, 2017 · 12 comments
Closed

Add reverse property #2

chaals opened this issue Feb 7, 2017 · 12 comments

Comments

@chaals
Copy link
Collaborator

chaals commented Feb 7, 2017

microdata makes it hard to have inverses, unlike RDFa and JSON-LD. This means that any vocabulary which wants to work with all three has to add a whole set of inverse properties to make microdata useful.

A reverse property, or similar, as per w3c/microdata-rdf#24 would be useful.

See also https://www.w3.org/wiki/WebSchemas/InverseProperties (notes from schema.org discussions a few years ago).

@gkellogg
Copy link
Member

gkellogg commented Feb 7, 2017

It doesn't seem that @itemprop-reverse was ever used in a schema.org example, even though it was motivated by that need. Previously, we needed to see use in the wild to add such a feature, but the need, IMHO, is clear, and the processing, for RDF, is well defined.

@itemprop-reverse has a direct corollary in RDFa @rev and JSON-LD @reverse.

@chaals
Copy link
Collaborator Author

chaals commented Feb 7, 2017

Yeah, it seems there is a bit of chicken and egging here. I believe schema.org doesn't use it in examples because it isn't in the spec.

I think there is also a preference among many people behind schema.org for RDFa or JSON-LD since they are "better" than microdata.

The point of trying to make a microdata Rec is that the world at large seems to prefer microdata by a significant margin. I agree the value is clear, and with well-defined processing, and no backwards-compatibility problem I can see, it seems reasonable to add this at least while we;re in effective development and see if e.g. schema.org takes it up.

@danbri
Copy link
Contributor

danbri commented Apr 21, 2017

From a Google perspective, if I remember right... roughly @itemprop-reverse was proposed during the "Microdata or RDFa or both" debates of 2011-13, but then JSON-LD came along and was sufficiently different to both, and added real value in various settings, that most syntax discussions moved towards "hmm JSON-LD is probably the easiest for people to create". I don't believe we can currently parse @itemprop-reverse, I can look into getting that addressed but yes, chicken/egg. This always was a niche case, even when there was only one syntax. @chaals - do you know if Yandex can parse itemprop-reverse already, or would amend its parsers as this spec matures?

Re "the world at large seems to prefer microdata by a significant margin", it did have a good head start, but there is a ton of JSON-LD out there too and I consistently hear from publishers that it is less complex in terms of workflow/maintenance.

@gkellogg
Copy link
Member

Actually, we came up with @itemprop-reverse around the Role discussion; At that time, the need for reverse properties seemed greater, and the fact you couldn't do it in Microdata made it less expressive than JSON-LD or RDFa. If there's no intention of ever using reverse properties in Microdata, then no real need to promote this, or even bring it forward.

@danbri
Copy link
Contributor

danbri commented May 13, 2017

I've edited to add https://www.w3.org/wiki/WebSchemas/InverseProperties to @chaals opening comment here as it has a lot of examples and earlier discussion.

@chaals
Copy link
Collaborator Author

chaals commented May 17, 2017

Hmmm. I think we could leave this Wontfix for now, unless there is great pressure. RDFa and JSON-LD can both do the necessary, so a vocabulary can always just say "use them instead"…

@danbri
Copy link
Contributor

danbri commented May 17, 2017

@chaals @gkellogg has anyone worked out test cases?

Here is a normal syntax example, except creatorOf is not an official term at schema.org:

<p itemscope itemtype="http://schema.org/Person" >
    <span itemprop="creatorOf" 
          itemscope itemtype="http://schema.org/Book">
       <span  itemprop="name" >Some book name here.</span>
   </span>
</p>

Here is how it might look if we allowed itemprop-reverse:

<p itemscope itemtype="http://schema.org/Person" >
    <span itemprop-reverse="creator" 
          itemscope itemtype="http://schema.org/Book">
       <span  itemprop="name" >Some book name here.</span>
   </span>
</p>

Here is a bogus example that should fail, because literals can't have outgoing properties (ish):

<p itemscope itemtype="http://schema.org/Person" >
    <span itemprop-reverse="creator">Some book name here.</span>
</p>

... so this should fail somehow.

Are there other corner cases to enumerate? itemref? Should we note that @itemid can be used instead, with different nesting structure?

What should we say about Microdata "1.0" parsers encountering itemprop-reverse -based markup? Perhaps just that publishers adopting the property ought to be aware that older parsers may extract only a subset.

For example, consider this:

<p itemscope itemtype="http://schema.org/Person" >
    <span itemprop-reverse="creator" 
          itemscope itemtype="http://schema.org/Book">
       <span  itemprop="name" >Some book name here.</span>
       <span itemprop="about" itemscope itemtype="http://schema.org/Volcano">
       <span  itemprop="name" >Eyjafjallajokull</span>
       </span>
   </span>
</p>

Currently Google's Microdata parser pulls out the Book section and ignores the Person and creator part.

@gkellogg
Copy link
Member

gkellogg commented May 17, 2017

As mentioned in an email, the Microdata to RDF test suite includes such tests. See test 0081-0084.

Using rdf.greggkellogg.net/distiller, I get the following Turtle output:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

 [
     a schema:Book;
     schema:about [
       a schema:Volcano;
       schema:name "Eyjafjallajokull"
     ];
     schema:creator [ a schema:Person];
     schema:name "Some book name here."
 ] .

This uses a straight-forward implementation as described in Microdata to RDF.

@danbri
Copy link
Contributor

danbri commented May 17, 2017

Let's now try to find ugly corner cases. Can we find a way for @itemref to make this confusing enough for parsers not to agree? /cc @unor who I see on Stackoverflow was quite on top of this stuff a while back. Borrowing an example, ... but using the 'alumniOf' / 'alumni' pair:

Plain Microdata @itemref:


<div itemprop="alumniOf" itemscope itemtype="http://schema.org/Organization" id="org">
  <!-- this property (worksFor) gets added to the Person item below -->
</div>

<div itemscope itemtype="http://schema.org/Person" itemref="org">
  <!-- looks for the element with the ID "org" -->
</div>

Here's that with @itemprop-reverse in the referenced section,


<div itemprop-reverse="alumni" itemscope itemtype="http://schema.org/Organization" id="org">
  <!-- this property (worksFor) gets added to the Person item below -->
</div>

<div itemscope itemtype="http://schema.org/Person" itemref="org">
  <!-- looks for the element with the ID "org" -->
</div>

@danbri
Copy link
Contributor

danbri commented May 17, 2017

Trying those last 2 tests in http://rdf.greggkellogg.net/distiller

First the basic @itemref:

 _:g70135557640880 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person> .
 _:g70135557640880 <http://schema.org/alumniOf> _:g70135550070860 .
 _:g70135550070860 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Organization> .

And then with itemprop-reverse:

_:g70135556605600 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person> .
_:g70135556630820 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Organization> .
_:g70135556630820 <http://schema.org/alumni> _:g70135556605600 .

This all seems as it should be.

@danbri
Copy link
Contributor

danbri commented May 17, 2017

Important opensource Microdata parsers?

I would consider both the RDF community and the SEO / CMS add on scene here.

Python

Looking into Python situation, it is not clear to me which is the most popular addon for rdflib, but back in the day there were parsers from both @iherman and @edsu.

Javascript

@chaals
Copy link
Collaborator Author

chaals commented Jun 17, 2017

neither the Google nor Yandex tools seem to pick this up. I doubt Yandex will implement this unless it becomes common, and that in turn probably depends on another search system picking it up.

Marked "Maybe Later" (so we can look for closed things we might want to do after all) and closed for now.

@chaals chaals closed this as completed Jun 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants