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

On Mon, Jun 18, 2012 at 2:01 PM, Dan Brickley <danbri@danbri.org> wrote:
> On 18 June 2012 22:51, Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote:
>> My addition 2 cents:
>>
>> We can specify in the schema.org vocabulary that a client MAY safely ignore the additional type information. It is just an additional hint that a client may follow or may not.
>>
>> For correct markup, it is safe to assume the property to be equivalent to rdf:type, but whether or not a parser handles it that way is up to the client.
>>
>> And for the ergonomics: I find a space-separated list of itemtypes like
>>
>> <section itemscope itemtype="http://schema.org/CreativeWork http://purl.org/goodrelations/v1#Brand ">
>> ...
>>
>> very error-prone, and, to be frank, ugly, from a coder's perspective.
>>
>> And if special role of the first itemtype to set the scope for the properties is hidden in the first position in the list, things get even worse.
>>
>> A brief summary of the current situation from my perspective:
>>
>> 1. We need the ability to indicate additional type information to schema.org in Microdata syntax, for GoodRelations and many other scenarios.
>> 2. The pattern must preserve the special role of the primary itemtype for setting the context for Microdata properties.
>> 3. We need the solution quickly, i.e. within a few weeks or so, the faster the better.
>> 4. Any changes to the Microdata spec are unlikely to happen within a reasonable time-frame.
>> 5. The proposal does not break any parsers and is fully compliant with the current Microdata spec and, afaiks, typical Microdata implementations.

I think there is a question of whether this breaks consumers of
microdata extracted data. I suspect the answer is no, they'll just
miss-out on the <?s http://schema.org/additionalTypes ?o> triple and
any triples that have ?o as the expected type of their subject, but
the data about the primary type should still be accessible.

My biggest fear with additionalTypes is people mixing vocabularies and
not using schema.org as the primary type, resulting in a meaningless
additionalType triple.

>> 6. The proposal is upwards-compatible to a future mechanism in a future Microdata spec.
>> 7. The proposal can be easily handled in an RDF environment for consuming respective data.
>
> I'm with you until here...
>
>> 8. Developers may use a broader range of lexical forms for identifiers of secondary types, e.g. Wikipedia URIs instead of www.productontology.org IDs, prefixed identifiers ("unspsc:11001123"),private URN schemes etc., which means we may need additional cleansing before translating respective markup into additional rdf:type statements.
>
> Not sure I buy this bit. Well, in general schema.org tolerates mess in
> lots of places, but I don't see a particular need to invite it here...
>  Private URN schemes can still be legitimate URIs/IRIs here, and
> someone could make a unspsc scheme....
>
> cheers,
>
> Dan
>

Received on Monday, 18 June 2012 21:08:27 UTC