02.12.2014, 22:21, "Gregg Kellogg" <gregg@greggkellogg.net>:
On Dec 2, 2014, at 2:59 AM, chaals@yandex-team.ru wrote:

01.12.2014, 21:21, "Ivan Herman" <ivan@w3.org>:
I think we should at the minimum make it clear in the note that this is, currently, *not* a microdata feature, and it may be later or it may never be.
 
I still feel uncomfortable; I think we are overstepping our document's goals. But I will not lie down on the road if the majority wants to go this way.
 
I agree with Ivan that this is not the right way around. If we have a use case, we should look at sensible ways to deal with it, and pseudo-patching microdata through some downstream spec doesn't seem right.
 
Microdata is only a Note, and readily updated if we think it is important. Yandex can provide the resources to produce a new version, through the HTML WG, if that seems like the thing we would like to do.
 
When we discussed this with Hixie, he indicated that evidence of usage in the field would be important for the WHATWG process, anyway.
 
I wasn't proposing to do it through the WHATWG process, but evidence of usage is important in general.
 
Of course, unless it is consumed, there will be no usage, and until it’s spec’d can’t really see how that would happen. If there’s another avenue to get it added through HTML WG, then of course, I’d rather see the attributes carved out there.
 
The process is pretty straightforward. You go to the HTML Working Group with a proposal to edit the spec, based on use cases ("it's painful to try and contort your content to avoid the need for inverses, schema.org doesn't really want to double the number of properties to ensure there is an inverse for everything in the vocabulary, and presumably there are other vocabularies in that situation") which lead to requirements ("match the inversion capabilities of other syntax"), and a proposed editor ("chaals").
 
Then they make a call for consensus.
 
In the mean time, the thought was that adding it as an “Experimental Feature” would carve out space for use in schema.org examples and implementations.
 
True, but there are lots of good reasons to avoid trying to extend an already small modular spec in some different one. Not least, in the case of Yandex we would far prefer to have everything in one spec given that most of our audience will prefer to have the material translated. Scattering it around in pieces isn't helpful.
 
My own Ruby implementation of RDF::Microdata does support @itemprop-reverse, which you can try using my distiller [1].
 
 
That's important, since implementation matters.
 
Equally, it would matter that some consumer is going to use the proposed property.
 

Indeed, if people are going to continue to use Microdata seriously, perhaps it is worth moving to Recommendation-track. Again, I think that is a feasible thing to do, and Yandex will provide the necessary resources if there is support for following this path. 
 
I think the combination of the two notes should be used to create a REC-track effort at some point.
 
That's mostly a question of demonstrating implementation and expectation of continued use...
 
Although, I question if the Microdata-JSON has any use at this point. I would be happy to participate in a WG pushing that forward too.
 
?
 
cheers
 
Chaals
 
 
 
Gregg
 
[1] http://rdf.greggkellogg.net/distiller

cheers
 
Chaals
 
 
Ivan

---
Ivan Herman
Tel:+31 641044153
 
(Written on mobile, sorry for brevity and misspellings...)
 
 

On 01 Dec 2014, at 19:06, Gregg Kellogg <gregg@greggkellogg.net> wrote:

On Dec 1, 2014, at 4:08 AM, Dan Brickley <danbri@google.com> wrote:

 
 

On Mon, 1 Dec 2014 17:18 null <chaals@yandex-team.ru> wrote:

01.12.2014, 14:38, "Ivan Herman" <ivan@w3.org>:
...
> https://github.com/w3c/microdata-rdf/issues
...
> However, issue #5, on @itemprop-reverse, is really open. Personally, I do not believe that feature should be included in the conversion spec; it amounts to an extension of microdata, which goes beyond what this document is for...

Yes, much as I like the idea, I think we should put the feature into microdata rather than wedge it in through this spec.

 

Having a spec for extracting item proper ever we into triples is a healthy precursor for having actual tools which do that, which in turn is a big part of making the case that such a change to microdata would be useful and used. This is only a Note - my opinion is strongly in favour of including it, although with health/status warnings.

Agreed, Hixie has indicated that it could be included in Microdata if there’s significant use in the wild, but without some spec text, this can’t really happen. It is defined as an experimental AT-RISK feature, so it could go away in a future update of the Note if this doesn’t happen. (My guess is that if it is used in a schema.org example, we’ll see quite a bit of adoption).
 
Gregg

Dan



cheers

Chaals

> Ivan
>>  On 01 Dec 2014, at 05:55 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>
>>  Last call for comments on this draft. Unless issues are raised by Friday, we'll prep it for publication.
>>
>>  Gregg Kellogg
>>  gregg@greggkellogg.net
>>>  On Nov 19, 2014, at 8:54 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>>
>>>  Based on feedback and emerging requirements, I’ve prepared another draft for an update to the Microdata to RDF Note [1]. As this is a Note of the Semantic Web Interest Group, please send feedback to semantic-web@w3.org. This update represents a substantial simplification to the algorithm by eliminating unused mechanisms and simplifies generation of implied triples (e.g. schema:additionalType).
>>>
>>>  This Working Draft is an update of the W3C Interest Group Note, published in October 2012. This update simplifies processing using the following mechanisms:
>>>
>>>  • Experimental support for @itemprop-reverse has been added. This attribute is not part of [MICRODATA] and is included as an experimental feature. Specific feedback from the community is requested. Based on addoption, the attribute may be considered for inclusion in forthcoming versions of [MICRODATA] and this note. (see issue 5 [2])
>>>
>>>  • Top-level items were previously included in a md:item RDF Collection to reconstruct the order that items appear in the DOM. This has also proven to not be useful and has been dropped. (see issue 6 [3])
>>>
>>>  • A property value may be extracted from the @content attribute of the meta element. (see issue 7 [4])
>>>
>>>  • A property value may be extracted from the @value attribute of the data or meter elements. If this value has numeric form, it will produce a datatyped literal using the appropriate datatype from [XMLSCHEMA11-2] (see issue 8 [5] and issue 9 [6])
>>>
>>>  • Property URI generation was under control of the propertyURI registry setting. This setting could previously have taken either the _vocabulary_ or _contextual_ settings. As _contextual_ was never used in a registry, and usage in the wild favors the vocabulary setting, support for _contextua_l has been eliminated, and consequently support for the propertyURI element within the registry. This issue remains open pending community review; specifically, anyone depending on this feature should provide feedback as requested below. (see issue 10 [7])
>>>
>>>  • An item having multiple values for a given property could previously having been placed in an RDF Collection if the multipleValues registry setting were set to _list_. Although the previous registry did have such a setting for some schema.orgvalues, this is not honored by most search engines, and so has been dropped, and consequently support for the multipeValues element within the registry. This issue remains open pending community review; specifically, anyone depending on this feature should provide feedback as requested below. (see issue 10 [7])
>>>
>>>  • Lastly, the previous update introduced Vocabulary Expansion using entailment rules adopted from [RDFA-CORE] under control of the vocab_expansion option. Support for Vocabulary Expansion has been substantially simplified, and is no longer under control of an option. This issue remains open pending community review; specifically, anyone depending on this feature should provide feedback as requested below. (see issue 10 [7])
>>>
>>>  The intention is to publish this draft as a new version of the Interest Group Note after gathering and incorporating community input. Please provide feedback by 5 December 2014. Please see GitHub issues for a discussion of tradeoffs considered in this version.
>>>
>>>  An updated test suite is referenced from the spec. A diff to the previous revision is available using the ReSpec key-sequence SHIFT-CTRL-ALT-S when viewing the spec.
>>>
>>>  Gregg Kellogg
>>>  gregg@greggkellogg.net
>>>
>>>  [1] http://w3c.github.io/microdata-rdf
>>>  [2] https://github.com/w3c/microdata-rdf/issues/5
>>>  [3] https://github.com/w3c/microdata-rdf/issues/6
>>>  [4] https://github.com/w3c/microdata-rdf/issues/7
>>>  [5]https://github.com/w3c/microdata-rdf/issues/8
>>>  [6] https://github.com/w3c/microdata-rdf/issues/9
>>>  [7] https://github.com/w3c/microdata-rdf/issues/10
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

 
 
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
 
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com