Reference to [microdata-rdf] should be changed

[iherman]

At the moment, microdata-rdf is listed as a dependency. As we are adding a JSON-LD and an RDF conversion into the document (normatively), I wonder what the fate of that note, and therefore the dependency, should be.

In my view, the cleanest option will be to rescind (or something similar) the microdata-rdf document. Indeed, JSON-LD and RDF are RDF serializations, therefore it seems to be unnecessary to keep that document. A note in the new microdata spec may want to make that clear.

(In view of, albeit limited, but nevertheless existing deployment of microdata-rdf it may worth comparing and making sure that we define the same mappings in terms of RDF…)

[chaals]

microdata-rdf goes beyond the microdata spec, adding a useful concept of a registry, describing a potential itemprop-reverse, and getting better i18n - at least items are formally language-taggable.

I would prefer to publish the Recommendation, based on real and widespread implementation of something not as good, and keep the forward-looking note as a reference. I'll look at clarifying that approach and the relationship in the spec itself.

(Agreed that the mappings defined should be compatible, i.e. what is produced by the normative spec should map onto what the Note mandates. But I expect the microdata spec's mappings to produce less information - fewer triples, albeit none that aren't in both outputs - since it's basically not as good).

[iherman]

I see your point, not yet absolutely convinced... are there (m)any implementations today for the mdata->JSON-LD or mdata->RDFa? I simply do not have the data. But it may be better to carry over the, say, i18n features to the microdata spec rather than having it in a separate note (where nobody would really care).

The itemprop-reverse is really a hack unless it is part of the official microdata. This should be the subject of a schema.org discussion on microdata; if there is no interest then the feature is better if dropped.

The registry is a similar issue. What I know is that the registry itself (http://www.w3.org/ns/md) has not changed a bit since the publication of the note, and contains only what is in the note. Ie, no uptake there...

[gkellogg]

I think itemprop-reverse could be removed, as it was an experiment for schema.org that never went anywhere.

However, the Microdata-RDF doc will do a much more faithful job of transforming Microdata to RDF than either of the built-in algorithms, due to the lack of a registry, and other simplifications. It would likely affect all of the schema.org examples, which would no longer generate the same triples as the RDFa and JSON-LD.

[iherman]

@gkellogg

However, the Microdata-RDF doc will do a much more faithful job of transforming Microdata to RDF than either of the built-in algorithms…

Well... I must admit I have strong reservations for essentially providing two different mappings to RDF under the W3C auspices (even if the SWIG document is a Note only). If reproducing the Microdata-RDF features in both JSON-LD and RDFa becomes too complicated, then we should just accept that and rescind the Note nevertheless. Alternatively, the Microdata-RDF could be promoted as a standard and referred as such from the microdata spec without the JSON-LD and RDFa conversion sections… (I recognize that the latter may not be realistic due to a modest level of interest.)

(To make it clear, this is my personal opinion, not W3C's)

[iherman]

(Continuing on my previous comment…)

We could also thoroughly re-write the Microdata-JSON note on top of the new Microdata standard, saying something like "implementations/mappings may consider the following improvements on the standard mappings to improve the quality of the represented RDF", taking good care of providing additional features that would make the generated RDF an extension (as @chaals said, adding new information). This note, superseding the current one, could be published by the WebApp WG…

[gkellogg]

@iherman I have updated the note on GitHub to reflect the updated Microdata spec. The main thing that sets it apart from algorithms in Microdata is the retention of datatype information from particular elements and attributes. Otherwise, there would be nothing but URLs and strings. Also, the use of a registry, which principally affects schema:additionalProperty. While it would be unfortunate to loose that, I think we could stand it, particularly with schema.org-specific entailment rules (or the soft-version used for things like Role). Loosing datatype information would be a step back. I don't see how to do this in any sections of the Microdata spec.

I think the last bit (presuming for Microdata-RDF, rather than Microdata-JSON) is best, and essentially what the spec does now. An alternative would be to remove the direct RDF mapping, and just show improvements for the RDFa and JSON-LD parts, basically either retaining the original element/attribute (for RDFa), or using the improved property value language from Microdata-RDF for either or both.

IMO, we can drop the @itemtype-reverse bit.

[iherman]

Your last remark

An alternative would be to remove the direct RDF mapping, and just show improvements for the RDFa and JSON-LD parts, basically either retaining the original element/attribute (for RDFa), or using the improved property value language from Microdata-RDF for either or both.

seems to align with my latest comment, i.e., we seem to be on the same line… (again:-)

There are some admin/formal issues, namely who would be in position to publish such an additional note. I would leave this to @chaals for the moment:-)

[danbri]

I would leave this to @chaals for the moment:-)

I concur.

[chaals]

We removed the JSON-LD mapping. I also removed the dependency - we make informative reference to the note in other parts of the spec already.

[chaals]

Dependency removed in dae7901

[iherman]

@danbri @gkellogg @chaals Does this mean we would have to republish the note alongside the mdata Rec? I think that would be the proper way of doing this. Would it be possible to republish the updated note in the WP Workin Group, rather than the SWIG? After all the SWIG is, in theory, on its way out...

[chaals]

My preference would be for SWIG to publish it, since it goes beyond the spec and into territory that they know well while Web Platform probably doesn't have much expertise in...

Republishing it alongside the formal spec does make sense, although I don't think they need to be tightly coupled...

[iherman]

My preference would be for SWIG to publish it, since it goes beyond the spec and into territory that they know well while Web Platform probably doesn't have much expertise in...

I understand your point, @chaals, the problem may be that the SWIG is supposed to be closed down in favour of a CG (@danbri, I am not sure where we are with this), and I would think that, e.g., for the purpose of continuity, it would be better to republish it as a Note rather than a CG report...