- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 25 Feb 2013 08:03:59 -0800
- To: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
In what way does this change our recommended vocabularies? Do we need two sets: one for data and one for strings? (I hope not) In other words, is this a reason NOT to define a property for "extent", but only to define properties for specific extent data, like duration? Which would mean that unparsed extents do not get marked up because you don't always know that a duration is present. I see a tug-of-war here between "using microdata with the data we have vs. using microdata with the data we wish we had." If we propose a property for "duration" but not one for "extent" then we are determining what markup can be done. I think we will encounter this again when we approach library holdings. I think it is worthwhile marking up library holdings for rich snippet display even if much of that data will not be actionable, but will be very informative for humans if brought up to the rich snippet level. There seem to be some philosophical differences that are tripping us up here. kc On 2/25/13 7:40 AM, Wallis,Richard wrote: > On 25 Feb 2013, at 16:06, "Karen Coyle" <kcoyle@kcoyle.net> wrote: > >> So you're saying that library data can only be used with schema.org markup if the information in the records is parsed into controlled lists? > > > No I am not saying that. > > The purpose of embedding structured data markup in the HTML is to identify and describe the data entities, and their properties, to processes consuming the pages (beyond mere human reading). > > To that end data producers should be encouraged to, wherever possible, use broadly recognised (authoratitve) identifiers for those entities and concepts. > > If you know the VAIF URI for a person - use it. The same is true for subjects, places, etc., and things like format types. > > As Jeff points out - if you don't have an identifier, a string is acceptable. I would personally add "as a fallback, not as a primary approach" > > ~Richard > > > On 25 Feb 2013, at 16:11, "Young,Jeff (OR)" <jyoung@oclc.org> wrote: > >> Here's what Schema.org says about its data model: >> http://schema.org/docs/datamodel.html >> >> Conformance >> >> While we would like all the markup we get to follow the schema, in >> practice, we expect a lot of data that does not. We expect schema.org >> properties to be used with new types. We also expect that often, where >> we expect a property value of type Person, Place, Organization or some >> other subClassOf Thing, we will get a text string. In the spirit of >> "some data is better than none", we will accept this markup and do the >> best we can. >> >> I think we are supporting the spirit of this. >> >> Jeff >> >>> -----Original Message----- >>> From: Karen Coyle [mailto:kcoyle@kcoyle.net] >>> Sent: Monday, February 25, 2013 10:06 AM >>> To: public-schemabibex@w3.org >>> Subject: Re: Extension syntax Was: Re: Updated Example >>> >>> So you're saying that library data can only be used with schema.org >>> markup if the information in the records is parsed into controlled >>> lists? I think that's a pretty high barrier to entry. >>> >>> kc >>> >>> On 2/25/13 12:31 AM, Richard Wallis wrote: >>>> On 25/02/2013 02:28, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >>>> >>>> I'm not advocating lists of values, just properties with text >>> like >>>> >>>> <span itemprop="techDetails">Format: OverDrive MP3 Audiobook, >>> OverDrive >>>> WMA Audiobook</span> >>>> >>>> or >>>> >>>> <span itemprop="techDetails">Mode of access: World Wide >>> Web</span> >>>> >>>> Obviously you can't do with text what you can with controlled >>>> lists, >>>> >>>> Precisely - Google recognised this - that is one of the reasons >> they >>>> are behind Schema.org, to introduce 'structured data' into the web. >>>> Things not Strings >>>> <http://googleblog.blogspot.fr/2012/05/introducing-knowledge-graph- >>> thi >>>> ngs-not.html> puts it very well. With the variation of language and >>>> spelling on the web, how on earth could you reliably build an >>>> interface to differentiate such information trapped in a string. >>>> >>>> Do we have an example of technology struggling to extract meaning >>> from >>>> information embedded in strings? - oh yes, library records. I am a >>>> little taken aback that you are suggesting this as a way forward. >>>> >>>> >>>> but the information from which to derive a precise list member >>>> simply isn't there. >>>> >>>> >>>> So lets find a simple way to get it there - get the ONIX codes >>>> available as reliable dereferencable canonical URIs quickly for the >>>> benefit of all - or take a pragmatic way forward with Product >>>> Ontology. A few parallel solutions could coexist, so pick one until >>>> your favourite is available in a useable form. >>>> >>>> ~Richard >>> >>> -- >>> Karen Coyle >>> kcoyle@kcoyle.net http://kcoyle.net >>> ph: 1-510-540-7596 >>> m: 1-510-435-8234 >>> skype: kcoylenet >> >> >> >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Received on Monday, 25 February 2013 16:04:28 UTC