Re: Extension syntax Was: Re: Updated Example

I think it's not just being open about values -- I think this will also 
inform what properties we define. Extent is a good example -- if we 
define only more specific properties ("duration" "number of pages") then 
those undefined extent statements won't fit in any of the available 
properties, and it makes even less sense to plot them into a random one. 
So we need to think about what data people have and provide properties 
for it, not just develop the properties that some think are "good" and 
let people succeed or fail. I really recommend looking at "read data" to 
inform our work.

kc

On 2/25/13 8:13 AM, Young,Jeff (OR) wrote:
> 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
>>
>
>
>

-- 
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 17:05:22 UTC