RE: Extension syntax Was: Re: Updated Example

We should try to set the range on properties to be Things the way
Schema.org does and then every time someone says "But I only have a
string", we remind them as many times as necessary that:

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.

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Monday, February 25, 2013 11:04 AM
> To: public-schemabibex@w3.org
> Subject: Re: Extension syntax Was: Re: Updated Example
> 
> 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:14:45 UTC