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

Re: additionalType property, vs extending Microdata syntax for multiple types

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Tue, 19 Jun 2012 11:32:42 +0200
Cc: Ivan Herman <ivan@w3.org>, Jason Douglas <jasondouglas@google.com>, "public-vocabs@w3.org Vocabs" <public-vocabs@w3.org>, Egor Antonov <elderos@yandex-team.ru>, Peter Mika <pmika@yahoo-inc.com>, Dan Brickley <danbri@danbri.org>, Ramanathan Guha <guha@google.com>, Jeni Tennison <jeni@jenitennison.com>
Message-Id: <DA348466-0A3C-4030-8405-F798AEAD4564@ebusiness-unibw.org>
To: Adrian Giurca <giurca@tu-cottbus.de>

On Jun 19, 2012, at 11:18 AM, Adrian Giurca wrote:

>> 
>> schema.org happens to use a schema-wide scope for properties (at least until now), e.g. the property "telephone" means the same for all itemtypes.
> "happens"? I reviewed the Schema.org from property perspective and I believe the meaning of a property will never change, i.e. "telephone" will have the same meaning no matter which class may include it. Or? This issue raise concerns on the potential logic of the Schema classes and properties.
> 
> I guess the Schema initiative should explain on this issue.

While I cannot speak for schema.org, the current design decision is to use globally defined property identifiers.
But if the vocabulary grows, this may lead to problems because intuitive names my trigger different expectations depending on the type of object they are applied to.

Assume you had two itemtypes, http://foo.com/Category and http://foo.com/Human. Both may need a "parent" property, but the parent of a category is something quite different from the parent of a human.

In other words, the current design decision is not set in stone. Since processing in microdata is type-centric, nothing would break if that decision had to be revoked one day due to the growing number of conflicts.

Martin



>> But that cannot be taken for granted. In theory, the property "telephone" could mean something different for two itemtypes, even within the same vocabulary. So the parser must know the itemtype for the entity for parsing any properties, unless they have fully qualified URIs.
>> 
>> Martin
> All the best,
> Adrian
>> 
>> On Jun 19, 2012, at 10:39 AM, Adrian Giurca wrote:
>> 
>>> Dear Ivan,
>>> Thank you for the reply.
>>> On 6/19/2012 10:24 AM, Ivan Herman wrote:
>>>> Although I am not Martin:-)
>>>> On Jun 19, 2012, at 09:15 , Adrian Giurca wrote:
>>>> 
>>>>> Dear Martin,
>>>>> Processing multiple types would not be so difficult. A Microdata editor  may easy support  multiple types and offer appropriate properties to the webmaster. Of course if the types comes from a vocabulary different from Schema.org then the webmaster must have knowledge of that vocabulary.
>>>>> 
>>>>> Myself I don't really understand why specifying  a "main type" is so significant. This introduce a kind of (partial) order on types or a preference on types.  Can you explain more on that?
>>>> If microdata was used on schema vocabularies only, then you would be right. But microdata is a general syntax that may be used to add information using, say, a hcard vocabulary. If you have a microdata fragment of the sort
>>>> 
>>>> <... itemscope ...>
>>>>   <... itemprop="something" ....>
>>>> </...>
>>>> 
>>>> at some point in time the reader (human or machine) has to know to what vocabulary the value of @itemprop belongs to. In the microdata world, that is defined by the value of @itemtype.
>>> Indeed the machine should know this. But this means it needs additional information than the DOM model.
>>>> Hence the current restriction in the microdata specification: if @itemtype has several values, then they all must be in the same vocabulary.
>>> This can change too.
>>>> In the use cases discussed in this thread, the various types may _not_ be in the same vocabulary. Ie, the current microdata mechanism for choosing the main vocabulary breaks.
>>> What is a "main vocabulary"? Is such vocabulary an interchange one (allowing interchanging various vocabularies)?
>>>> I hope this helps (ie, I hope that was the question:)
>>>> 
>>>> Cheers
>>>> 
>>>> Ivan
>>> Thanks again,
>>> Adrian
>>>>> Obviously, the example I did do not express that  http://schema.org/CreativeWork is sameAs http://purl.org/goodrelations/v1#Brand
>>>>> 
>>>>> I believe this relationship is different than multiple typing. If this is the goal, then Thing must provide a property @sameAs  allowing for a URI list as value. I believe sameAs is a good name as people should fast understand what the property means.
>>>>> 
>>>>> So, I see two issues here:
>>>>> 1. multiple types
>>>>> 2. sameAs mapping to different vocabularies
>>>>> 
>>>>> Regards,
>>>>> Adrian
>>>>> 
>>>>> On 6/18/2012 6:03 PM, Martin Hepp wrote:
>>>>>> To add to my argument: I think that the frame-based pattern of Microdata is ergonomically a big plus. Developers of all flavors are used to start with a class or entity type and then fill slots for available characteristics. Otherwise, finding appropriate properties for an item is very burdensome. So indicating the primary itemtype is important.
>>>>>> 
>>>>>> As for the argument of defining ontology language features in the ontology: That pattern is violated elsewhere, too, since schema.org does not use rdfs:label and rdfs:comment for naming and describing elements but provides properties for this. Clearly it is no problem for someone consuming schema.org markup in an RDF environment to map schema:name to rdfs:label and schema:description to rdfs:comment.
>>>>>> 
>>>>>> But not everyone is consuming schema.org in microdata syntax in an RDF environent. That is just one out of many choices supporting Entity-Attribute-Value structures.
>>>>>> 
>>>>>> Also note that a property additionalType would allow way more tolerant parsing of type identifiers that are not valid URIs. For instance, we could tolerate other Web-scale tokens (e.g. prefix:value strings) without breaking the microdata parsers.
>>>>>> 
>>>>>> Think of UNSPSC and eCl@ss product classes.
>>>>>> 
>>>>>> Martin
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jun 18, 2012, at 5:44 PM, Jason Douglas wrote:
>>>>>> 
>>>>>>> That's not just a token list... it's an ordered token list.  You're privileging the first token as the "frame" as Martin calls it.  In the case of a token list for itemprop there's no order dependance (and I'm guessing that's the reason itemtype is the way it is in the spec).
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jun 18, 2012 at 8:24 AM, Adrian Giurca<giurca@tu-cottbus.de>    wrote:
>>>>>>> Hi Egor,
>>>>>>> 
>>>>>>> Indeed, it would be enough to allow a list of URLs  as  value of Microdata @itemtype. This is similar with the token list value of @itemprop.
>>>>>>> Such extension will solve many of actual annotations miss-understandings and will not add more verbosity to the markup.
>>>>>>> <section itemscope itemtype="http://schema.org/CreativeWork http://purl.org/goodrelations/v1#Brand "
>>>>>>>  <h1 itemprop="name
>>>>>>> http://example.com/fn
>>>>>>> ">Hedral</h1>
>>>>>>>  <p itemprop="description
>>>>>>> http://purl.org/goodrelations/v1#description
>>>>>>> ">Hedral is a male american domestic
>>>>>>>  shorthair, with ...
>>>>>>>  </p>
>>>>>>>  </section>
>>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Adrian
>>>>>>> 
>>>>>>> 
>>>>>>> On 6/18/2012 12:11 PM, Egor Antonov wrote:
>>>>>>>> Agreed with Peter. "additionalType" is not a part of the (ontology) schema, but a hack for microdata.
>>>>>>>> We cannot save compatibility with microdata anyway, because all the parsers need to be rewritten to understand schema.org.
>>>>>>>> If so, why do we handle it as ontology schema addition and not as new markup standard?
>>>>>>>> Let's just make a microdata extension for schema.org.
>>>>>>>> 
>>>>>>>> PS
>>>>>>>> It will be strange to have "additionalType" property while "mainType" doesn't exist.
>>>>>>>> --
>>>>>>>> Egor
>>>>>>>> 
>>>>>>>> 16.06.2012, 19:28, "Peter Mika"<pmika@yahoo-inc.com>:
>>>>>>>>> Let me add my $0.02...
>>>>>>>>> 
>>>>>>>>> My main concern is that schema.org is and should be about the schema,
>>>>>>>>> not the syntax. The reason of adding this property is to patch
>>>>>>>>> microdata, but if schema.org defines this term, it will be available for
>>>>>>>>> all syntaxes (microdata, RDFa, possibly soon OData). In both microdata
>>>>>>>>> and RDFa, we would end up with two ways of defining types (using
>>>>>>>>> typeof/itemtype vs. additionalType). Standard parsers however will only
>>>>>>>>> see one type (the one expressed using the standard mechanism).
>>>>>>>>> 
>>>>>>>>> A minor concern is that the name additionalType implies that somehow one
>>>>>>>>> type is more important than the other.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 6/16/12 7:48 AM, Dan Brickley wrote:
>>>>>>>>> 
>>>>>>>>>  On 16 June 2012 06:55, Ivan Herman<ivan@w3.org>     wrote:
>>>>>>>>>  On Jun 15, 2012, at 20:26 , Dan Brickley wrote:
>>>>>>>>>  HTML5 Microdata, as defined in
>>>>>>>>>  http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#encoding-microdata
>>>>>>>>> 
>>>>>>>>>  ... has only limited support for describing multiple types that
>>>>>>>>>  something belongs to. In particular it requires they are described
>>>>>>>>>  using a single schema.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  For Good Relations integration (and other scenarios) people have asked
>>>>>>>>>  for a way of listing more types within schema.org markup.
>>>>>>>>> 
>>>>>>>>>  * One model is to use RDFa 1.1 (Lite), where this is quite natural.
>>>>>>>>>  * Another is to add (as a workaround) a new property, e.g. called
>>>>>>>>>  'type' or 'additionalType', to schema.org's vocab (Martin requests
>>>>>>>>>  this in http://www.w3.org/wiki/WebSchemas/GoodRelations )
>>>>>>>>>  * A 3rd is to stretch
>>>>>>>>>  http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
>>>>>>>>>  to allow different namespaces to be used.
>>>>>>>>>  I think that the third option is not obvious. The issue is that, in microdata, two notions, namely the typing of an item and the vocabulary used in that item, are conflated. The vocabulary information (hence the interpretation of the terms in the item) is deduced from the itemtype value(s). Hence the restriction in the current spec to restrict multiple types to be in the same vocabulary. Technically, it would be possible to declare that the order in the attribute's value counts, ie, the first type value determines the vocabulary, but that would be terribly error-prone and I hence do not believe it would be a good idea.
>>>>>>>>> 
>>>>>>>>>  It would require a more substantial change in the microdata spec (essentially introducing the equivalent of RDFa's @vocab) to solve that properly. I do not see that happening.
>>>>>>>>>  Yes. I think it is well appreciated that RDFa 1.1 handles this better.
>>>>>>>>>    I don't think anyone expects Microdata to change a lot more, and I
>>>>>>>>>  don't see anyone with the energy/interest to keep pushing for these
>>>>>>>>>  kinds of changes/improvements in Microdata. As you say, it wouldn't be
>>>>>>>>>  easy. The "main type comes first" design was all I could think of,
>>>>>>>>>  too.
>>>>>>>>>  Which leaves us with the first or the second option. I am obviously biased here, but I think the first option is clearly better in this respect...
>>>>>>>>>  The question is then, what do we say for all those publishers who are
>>>>>>>>>  on board the Microdata train? A lot of people have worked hard to get
>>>>>>>>>  colleagues/stakeholds (and tools!) adopting Microdata, over the last
>>>>>>>>>  year. While RDFa is a good thing, we want to be careful to support
>>>>>>>>>  early adopters too, and have sensible advice for them (other than
>>>>>>>>>  're-do everything with a new syntax'). Which is what makes
>>>>>>>>>  'additionalType' attractive. But the concern there is ... if we go
>>>>>>>>>  that route, validators/checkers will need to understand the attribute
>>>>>>>>>  since it is almost an extension of the underlying syntax...
>>>>>>>>> 
>>>>>>>>>  cheers,
>>>>>>>>> 
>>>>>>>>>  Dan
>>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Egor Antonov
>>>>>>>> http://staff.yandex-team.ru/elderos
>>>>>> --------------------------------------------------------
>>>>>> martin hepp
>>>>>> e-business&    web science research group
>>>>>> universitaet der bundeswehr muenchen
>>>>>> 
>>>>>> e-mail:  hepp@ebusiness-unibw.org
>>>>>> phone:   +49-(0)89-6004-4217
>>>>>> fax:     +49-(0)89-6004-4620
>>>>>> www:     http://www.unibw.de/ebusiness/ (group)
>>>>>>          http://www.heppnetz.de/ (personal)
>>>>>> skype:   mfhepp
>>>>>> twitter: mfhepp
>>>>>> 
>>>>>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>>>>>> =================================================================
>>>>>> * Project Main Page: http://purl.org/goodrelations/
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> ----
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: +31-641044153
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> --------------------------------------------------------
>> martin hepp
>> e-business&  web science research group
>> universitaet der bundeswehr muenchen
>> 
>> e-mail:  hepp@ebusiness-unibw.org
>> phone:   +49-(0)89-6004-4217
>> fax:     +49-(0)89-6004-4620
>> www:     http://www.unibw.de/ebusiness/ (group)
>>          http://www.heppnetz.de/ (personal)
>> skype:   mfhepp
>> twitter: mfhepp
>> 
>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>> =================================================================
>> * Project Main Page: http://purl.org/goodrelations/
>> 
>> 
>> 
>> 
> 

--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp@ebusiness-unibw.org
phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/
Received on Tuesday, 19 June 2012 09:33:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 09:33:11 GMT