- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Mon, 14 Jan 2013 17:26:05 +0100
- To: <public-vocabs@w3.org>
Dear all, Indeed the effort lead by Jean (disclaimer: I also participated) perhaps focused too much on the kind of schema.org mark-up a page dedicated to a concept may include. But a selection could be made, depending on what kind of scenarios is judged important enough to support in the core schema.org vocabulary. And it may be useful to start not from concepts, but from the objects that these concepts are supposed to allow one to find, or to explore. I also second the concern of starting from what's visible in the page. But on the other hand I've understood that schema.org is also seeking to provide better data for search engines... Let's say, if a page has a mark-up based on a visible string "Leonardo da Vinci", will it be useful that the pages "tells" a search engine that it would also do a suitable result for "Léonard de Vinci", even if this string is not visible for all users? Or if a book is about schema.org it's somehow also about search engines, mark-up, even though this may not have been part of the original description. SKOS was meant to support such cases. Now, if part (or all) of them are not deemed relevant by enough stakeholders, then of course we need to downscale the inclusion proposal. I'd be a bit surprised if non of that is relevant. Especially when search engines start delving into more semantic stuff (like the Google Knowledge Graph). Unless of course search engines decide it's better for them to produce the data they need by themselves. Best, Antoine > IDs of terms can effectively be used to instantiate classes or properties in rdfa or microdata statements but not much will happen if they can't be dereferenced (dereferenciated ?:--). > > In a schema.org paradigm, probably things undertsood by schema.org will be preferred e.g. to ingest dereferentiated triples as linked data to be added to the triple store (whatever implementation it is) . Therefore, what jean has been proposing yesterday makes sense as an appropriate way to declare SKOS in a schema-org friendly way. > > Of course this is only one option. I can see a case for a HTML documentation that contains some rdfa/microdata plus an RDF file for those who wnat to use it. > > As you say, it is for those who host vocabularies to provide these in the right (e.g. SKOS for schema.org ) format and the intention is not to have schema-org duplicate vocabularies in yet another format (also because you will never avoid others to create their own dictionary). Having a way to simply share SKOS vocabularies in a schema.org paradigm would make it benefit from a load of resources. > > I am also worried by some of the things that have been said as it reflects uncxertainties on some fundamentals. > > JP
Received on Monday, 14 January 2013 16:26:36 UTC