Re: Multiple types from different vocabularies (ACTION-7)

On 30 October 2011 18:13, Jeni Tennison <jeni@jenitennison.com> wrote:
> Dan,
>
> On 30 Oct 2011, at 10:55, Dan Brickley wrote:
>> IMHO it's fine to say "If you want to mention another type, we expect
>> the property <http://schema.org/type> to be available long term, and
>> always to be defined as meaning the same thing as RDF's rdf:type
>> property". What concerned me was the hint/suggestion that a mapping
>> might reference that property more deeply, as an integral part of
>> Microdata-as-RDF syntax.
>
> We (as in this Task Force) need to create a microdata-to-RDF mapping and guidelines for publishers and consumers of microdata that will help it to fit into the wider ecosystem. If special-casing http://schema.org/type is out of the question, I see three possibilities around these rdf:type equivalent properties.

Can you give an example draft paragraph for how that special-casing
would look? I don't want to mistakenly close the door on something
useful. Meanwhile...

> 1. We can treat http://schema.org/type and other type-equivalent properties like any other property, not say anything special about it or recommend its use, and leave it to consumers to do any post-processing on the results of the generic microdata->RDF conversion. I have a feeling that (as Ivan says) some processors will try to be helpful and automatically do some post-processing, while others will stick with the letter of the conversion algorithm and not do so. That leads to a confusing situation for people using those processors, who will only see the variant behaviour and probably won't understand its cause. It also means we can't give any guidelines to consumers about understanding microdata additional types are provided through a separate property.

Yup

> 2. We can say in the generic microdata->RDF conversion that individual vocabularies may define their own equivalents to rdf:type, and that these can be provided in the (growing) registry entry for the particular vocabulary, with schema.org's being http://schema.org/type. This will mean processors (or at least those that pick up the vocabulary information from the registry) will behave more regularly for those using them, and we can recommend both that vocabulary authors define an equivalent to rdf:type and that consumers that understand those vocabularies pick up on those properties when working out the type of an item. But it makes it a bit less regular for publishers, because instead of the advice "use the property http://schema.org/type" we will have to say, "use whatever type property has been specified for the vocabulary you're using, or rdf:type if there isn't one".

(...or schema.org if you want one with a short URL ?)

Ok, would it be useful then if FOAF also had 'type'? I can easily add
that. Should we declare domains and ranges? It would help to have a
standard package of triples to add to a schema.

Dublin Core btw already seems to have it: the dcterms:type property is
close enough? Maybe more a subproperty... ie. every ?X dcterm:type ?Y
implies the same with rdf:type, but perhaps not vice-versa.

See http://dublincore.org/documents/dcmi-terms/#terms-type ... it even
has range rdfs:Class (maybe that also is bad for OWL DL? :)



> 3. We can define http://www.w3.org/ns/type as having special handling in the microdata to RDF conversion and recommend its use for publishers. This has clarity and eases the burden on vocabulary authors and consumers as they only have to recognise a single type. But if there is also a http://schema.org/type, publishers who are using schema.org (the vast majority) will probably use it (or the short-form "type") instead of http://www.w3.org/ns/type or will have to use itemprop="type http://www.w3.org/ns/type" all the time.
>
> I think 2 or 3 are preferable, and which route we go really depends on whether schema.org defines a http://schema.org/type property or not. If you/they do, we will need to do 2. It would be helpful to know which is going to happen sooner rather than later so that we can create appropriate advice.

I don't see any opposition to adding http://schema.org/type ... could
you write up a Wiki page entry somewhere that encapsulates in a single
read the entire proposal so we can get it reviewed and OK'd by these
two TFs and by the Schema.org partners? Or maybe I should try that, as
an exercise to make sure I've gotten the point this time :)

>>> This is really down to how schema.org is pitched and the role it wants to play. If it's an external project that might at any moment disappear or be led off in a different direction by a collection of self-interested vendors, then I agree with you. If it's a web-community-based project that is being developed through a light-weight but defined and open process with W3C support and backing then it's much less clear cut; my inclination is to encourage it in that direction.
>>
>> It has elements of the former, but leans towards the latter. However,
>> it isn't a democracy, so a lot depends on what people mean by 'open
>> process' here. I've tried to outline a process for how the Schema.org
>> project and the Web Schemas TF are related here:
>> http://www.w3.org/wiki/SchemaDotOrgProcess ... maybe you could have  a
>> glance and see how that style fits with the needs here.
>
> OK, I don't think so based on that.

So it's my responsibility to open things up as much as possible, but
I'm wary of over-promising. Ultimately the vocabulary is under the
sole control of the three partner companies, at least for now. So
treating it as a pseudo-W3C vocab could confuse things. I've
periodically been told by W3C staffers that W3C specs can't depend on
FOAF, for example, in case Libby and I turn evil. All that said, I
think Schema.org is a well-intentioned and responsibly managed effort
(or I wouldn't be involved:) and if there are simple practical things
that Schema.org can do to help improve things, they'll happen.

>>>> Yup. Has anyone talked to Hixie about this lately?
>>>
>>> Yes we did, here. [1] He's not going to add support for multiple types from different vocabularies to microdata syntax unless and until they have common use (both being published and consumed). None of the evidence that we are able to provide of that happening at the moment is widespread enough to be persuasive to him.
>>
>> Thanks. Does that conversation have an URL?
>
> The thread started at the reference I gave:
>
>  http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0064.html
>
> and can be followed through the 'Next message in thread' links. Or you can see the thread on the thread-centric page at:
>
>  http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/thread.html
>
> But you know how W3C mailing lists work so I guess that's not what you're asking for?

I'd missed the connection, sorry for not reading more carefully.
That's great re URL.

>>> There are other workarounds to support multiple types, such as just using RDFa, mixing microdata with other syntaxes to supply the extra information, or using hidden sections of the document. We're going to have to present the full range of options, but the extra type property is the easiest to use in simple circumstances.
>>
>> Great. I'll investigate whether I can find some use cases for
>> producing/consuming...
>
>
> That would be great. I've been using some of the recent blekko.com searches to identify pages that contain microdata and microformats that we might use as a starting point to explore these issues. Martin Hepp also has a bunch of examples around GoodRelations use.

Haven't looked at blekko yet...

cheers,

Dan

ps. I know *nothing* of this site other than having stumbled across
it, but http://commoncrawl.org seems to promise availability of a big
chunk of crawl data --- maybe useful here?

> Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>

Received on Sunday, 30 October 2011 19:52:12 UTC