- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 05 Dec 2012 07:40:44 -0800
- To: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
On 12/5/12 7:26 AM, Jodi Schneider wrote: > +1 : A design pattern seems more appropriate to me. We seem to have covered this (or maybe it's just me)[1] -- We either need a structure, but that complicates things for display, or we need to use a "meta" tag, if we are going to deal with this as a pattern. Otherwise we need to create a property for each identifier type. As Ed points out, a pattern is needed for identifiers that do not have a standard URI form. Ironically, one of the few that does have such a form is the ISBN, yet that's already one of the properties in schema.org. I just think that ISBN is so common that people automatically add it to any bibliographic metadata schema. Note that this issue of needing a design pattern will come back when we talk about subject headings. Most thesauri do not yet use URIs, and the list of potential thesauri is huge. [2] kc [1] http://lists.w3.org/Archives/Public/public-schemabibex/2012Dec/0019.html [2] http://www.loc.gov/standards/sourcelist/ > -Jodi > > >> >> I'm not sure I have a preference at this point, but I just wanted to >> point out that relying entirely on itemid for expressing identifiers >> is not going to work. Perhaps it would be useful to document some of >> the design choices on the wiki for further discussion? >> >> //Ed >> >> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-December/038256.html >> [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-December/038257.html >> >> PS. Sorry for sending this to you twice Karen :-) >> >> On Tue, Dec 4, 2012 at 8:42 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: >>> I did check these fields on what I can find of the Moen statistics (a large >>> study of MARC field frequency), so there may be some we can defer. >>> Unfortunately, what I have of those stats only covers books, not, for >>> example, serials or music, so I am making a guess here, but these fields >>> seem to be used less in less than 80% of the relevant records: >>> >>> >>> 013 - Patent Control Information (R) Full | Concise >>> 017 - Copyright or Legal Deposit Number (R) Full | Concise >>> 024 - Other Standard Identifier (R) Full | Concise >>> 025 - Overseas Acquisition Number (R) Full | Concise >>> 026 - Fingerprint Identifier (R) Full | Concise >>> 027 - Standard Technical Report Number (R) Full | Concise >>> 031 - Musical Incipits Information (R) Full | Concise >>> 035 - System Control Number (R) Full | Concise >>> >>> I rather expected the GPO item number (074) to be higher, but it is not. >>> However, I've lost access to the full set of stats so I don't know its >>> actual frequency. (Some files are on the original site are giving me 404) >>> I'll see if I can rectify this. >>> >>> kc >>> >>> >>> On 12/4/12 11:45 AM, Karen Coyle wrote: >>>> >>>> It kind of depends on what you consider a bibliographic identifier. So >>>> maybe our first step should be to define that. >>>> >>>> Here are the ones that I find in the MARC21 format: >>>> >>>> 010 - Library of Congress Control Number (NR) Full | Concise >>>> 013 - Patent Control Information (R) Full | Concise >>>> 015 - National Bibliography Number (R) Full | Concise >>>> 016 - National Bibliographic Agency Control Number (R) Full | Concise >>>> 017 - Copyright or Legal Deposit Number (R) Full | Concise >>>> 020 - International Standard Book Number (R) Full | Concise >>>> 022 - International Standard Serial Number (R) Full | Concise >>>> 024 - Other Standard Identifier (R) Full | Concise >>>> 025 - Overseas Acquisition Number (R) Full | Concise >>>> 026 - Fingerprint Identifier (R) Full | Concise >>>> 027 - Standard Technical Report Number (R) Full | Concise >>>> 028 - Publisher Number (R) Full | Concise >>>> 030 - CODEN Designation (R) Full | Concise >>>> 031 - Musical Incipits Information (R) Full | Concise >>>> 032 - Postal Registration Number (R) Full | Concise >>>> 035 - System Control Number (R) Full | Concise >>>> ?036 - Original Study Number for Computer Data Files (NR) Full | Concise >>>> 074 - GPO Item Number (R) Full | Concise >>>> >>>> I think this is all of them.... Then we go on to the classification codes: >>>> >>>> >>>> 050 - Library of Congress Call Number (R) Full | Concise >>>> 052 - Geographic Classification (R) Full | Concise >>>> 055 - Classification Numbers Assigned in Canada (R) Full | Concise >>>> 060 - National Library of Medicine Call Number (R) Full | Concise >>>> 070 - National Agricultural Library Call Number (R) Full | Concise >>>> ?072 - Subject Category Code (R) Full | Concise >>>> >>>> And that doesn't cover thesauri. However, we may want to ignore any >>>> thesauri that cannot provide URIs? >>>> >>>> kc >>>> >>>> >>>> >>>> On 12/4/12 11:28 AM, Ross Singer wrote: >>>>> >>>>> >>>>> On Dec 4, 2012, at 2:23 PM, Ed Summers <ehs@pobox.com >>>>> <mailto:ehs@pobox.com>> wrote: >>>>> >>>>>> Call me naive, but I contend that most bibliographic identifiers are >>>>>> expressable as URIs (URNs, info-uris, URLs) and that as such they can >>>>>> use microdata's itemid [1]. Is there really a problem here? >>>>> >>>>> >>>>> +1 >>>>> >>>>> I was hoping to suggest something along these lines, but had lacked the >>>>> cycles to actually do the research to back it up. >>>>> >>>>> -Ross. >>>>>> >>>>>> >>>>>> //Ed >>>>>> >>>>>> [1] >>>>>> >>>>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#global-identifiers-for-items >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 4, 2012 at 9:00 AM, Karen Coyle <kcoyle@kcoyle.net >>>>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 12/4/12 5:01 AM, Shlomo Sanders wrote: >>>>>> >>>>>> For what it is worth, I prefer: >>>>>> >>>>>> ISBN-10<span property=" identifier" >>>>>> typeof="ISBN">0316769487</__span> >>>>>> >>>>>> >>>>>> I don't think this is correct -- unless you have a property that >>>>>> is "ISBN". The "typeof" takes a property, not a value. >>>>>> >>>>>> Any values have to be outside of the <> unless you use a meta tag. >>>>>> see: >>>>>> http://schema.org/docs/gs.__html#advanced_missing >>>>>> <http://schema.org/docs/gs.html#advanced_missing> >>>>>> >>>>>> Maybe that's how we'll have to go - with meta. >>>>>> >>>>>> kc >>>>>> >>>>>> >>>>>> >>>>>> Or >>>>>> ISBN-10: <span itemprop="isbn">0316769487</__span> >>>>>> >>>>>> These are short and clean. >>>>>> The itemprop="isbn" is not generic since the valid values for >>>>>> itemprop is enumerated? >>>>>> Is that the same issue for typeof? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net >>>>>> <mailto:kcoyle@kcoyle.net>] >>>>>> Sent: Tuesday, December 04, 2012 14:58 >>>>>> To: public-schemabibex@w3.org <mailto:public-schemabibex@w3.org> >>>>>> Subject: Re: Missing Schema.Org <http://Schema.Org> properties >>>>>> >>>>>> Do we need to consider how this might be displayed, since >>>>>> schema.org <http://schema.org/> generally wraps around a >>>>>> display? These two options would result in different displays: >>>>>> >>>>>> On 12/4/12 3:33 AM, Shlomo Sanders wrote: >>>>>> >>>>>> How is this as a schema.org <http://schema.org/> >>>>>> "friendly" version of the ONIX structure: >>>>>> >>>>>> <div typeof="identifier"> >>>>>> <span property=" identifierValue >>>>>> ">0316769487</span> >>>>>> <span property=" identifierType ">ISBN</span> >>>>>> </div> >>>>>> >>>>>> >>>>>> 0316769487 ISBN >>>>>> >>>>>> >>>>>> >>>>>> Seems too long to me, perhaps: <span property=" >>>>>> identifier" typeof="ISBN">0316769487</__span> >>>>>> >>>>>> >>>>>> 0316769487 >>>>>> >>>>>> The schema.org <http://schema.org/> documentation shows a >>>>>> similar example to this latter approach using price: >>>>>> >>>>>> Price: <span itemprop="price">$6.99</span> >>>>>> <meta itemprop="priceCurrency" content="USD" /> >>>>>> >>>>>> This gets the "$6.99" display for the human reader, plus the >>>>>> currency type for processing. >>>>>> >>>>>> The current use of ISBN is illustrated as: >>>>>> >>>>>> ISBN-10: <span itemprop="isbn">0316769487</__span> >>>>>> >>>>>> If we go with id type and value, then display is limited by >>>>>> the defined types, unless we leave type very loose. To get the >>>>>> same display as the ISBN immediately above, we'd need: >>>>>> >>>>>> <div itemprop="identifier" >>>>>> itemscope="http://schema.org/__Identifier >>>>>> <http://schema.org/Identifier>"> >>>>>> <span itemprop="idType">ISBN-10: </span> >>>>>> <span itemprop="idValue">0316769487<__/span> >>>>>> </div> >>>>>> >>>>>> Does identifier type do what we want if it's not a controlled >>>>>> value? Or would we need a <meta> with a controlled value? >>>>>> >>>>>> kc >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net >>>>>> <mailto:kcoyle@kcoyle.net>] >>>>>> Sent: Monday, December 03, 2012 20:28 >>>>>> To: Graham Bell >>>>>> Cc: public-schemabibex@w3.org >>>>>> <mailto:public-schemabibex@w3.org> >>>>>> Subject: Re: Missing Schema.Org <http://Schema.Org> >>>>>> properties >>>>>> >>>>>> I do, however, see a significant difference between >>>>>> schema.org <http://schema.org/> and the XML structure of >>>>>> ONIX (or any other XML-based metadata): schema.org >>>>>> <http://schema.org/> allows the data to be flattened to a >>>>>> single horizon of data. This is for the sake of >>>>>> simplicity, if I understand correctly. There seems to be a >>>>>> philosophy in schema.org <http://schema.org/> that avoids >>>>>> a strict division of descriptions into "right" and >>>>>> "wrong." XML, instead, is really an enforcement mechanism. >>>>>> >>>>>> I'm leery of adding much structure to schema.org >>>>>> <http://schema.org/>. Or at least, of either requiring it >>>>>> or relying on it. That makes the identifier "problem" >>>>>> particularly difficult. It is for this reason that I >>>>>> asked, in response to Shlomo's post, whether one can make >>>>>> use of the self-identifying nature of URIs. That doesn't >>>>>> help us with non-URI identifiers, but it seems that we are >>>>>> moving increasingly in the direction of "fully formed" >>>>>> identifiers. >>>>>> >>>>>> kc >>>>>> >>>>>> On 12/3/12 8:41 AM, Graham Bell wrote: >>>>>> >>>>>> Worth saying at this point that this is EXACTLY how >>>>>> ONIX is structured: >>>>>> >>>>>> <entityIdentifier> >>>>>> <entityIDType> >>>>>> <IDTypeName> >>>>>> <IDValue> >>>>>> </entityIdentifier> >>>>>> >>>>>> >>>>>> where 'entity' might be 'product', 'work', 'name', or >>>>>> whatever. There >>>>>> is a controlled vocabulary for common IDTypes, and if >>>>>> you have some >>>>>> proprietary identifier not in the list, you must >>>>>> include a 'likely to >>>>>> be unique' name for it in <IDTypeName> instead. >>>>>> >>>>>> A point of history -- ONIX started (in 1999) with a >>>>>> property per >>>>>> identifier type: there were tags called <ISBN> and >>>>>> <UPC>, but as >>>>>> pointed out below, that isn't really practical, so the >>>>>> above XML >>>>>> structure is used extensively now. It's easy to add to >>>>>> the controlled >>>>>> vocabulary when a new identifier comes along, without >>>>>> having to >>>>>> change the schema. In UML, it looks like the attached, >>>>>> and I leave >>>>>> the RDF as an exercise for the reader... >>>>>> >>>>>> Graham >>>>>> >>>>>> >>>>>> >>>>>> Graham Bell >>>>>> EDItEUR >>>>>> >>>>>> Tel: +44 20 7503 6418 <tel:%2B44%2020%207503%206418> >>>>>> Mob: +44 7887 754958 <tel:%2B44%207887%20754958> >>>>>> >>>>>> EDItEUR Limited is a company limited by guarantee, >>>>>> registered in >>>>>> England no 2994705. Registered Office: United House, >>>>>> North Road, >>>>>> London N7 9DP, UK. Website: http://www.editeur.org >>>>>> <http://www.editeur.org/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3 Dec 2012, at 16:18, Laura Dawson wrote: >>>>>> >>>>>> That might work, actually. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Dec 3, 2012, at 4:05 PM, Karen Coyle >>>>>> <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> >>>>>> <mailto:kcoyle@kcoyle.net >>>>>> <mailto:kcoyle@kcoyle.net>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 12/3/12 7:19 AM, Richard Wallis wrote: >>>>>> >>>>>> >>>>>> Hi Shlomo, >>>>>> >>>>>> Couple of points. >>>>>> >>>>>> >>>>>> *Identifiers: *This is a particular >>>>>> concern of mine. >>>>>> >>>>>> >>>>>> Me, too! >>>>>> >>>>>> The approach of >>>>>> >>>>>> having a named property for each possible >>>>>> identifier that a >>>>>> CreativeWork or a Person could have, just >>>>>> does not scale. However >>>>>> to handle this you will always be >>>>>> disenfranchising some identifier >>>>>> backing group. Isbn seems to of got in >>>>>> because it is know by everyone, oclcnum is >>>>>> obvious >>>>>> from where I sit (but that does not make >>>>>> it right). I think we (in all >>>>>> of Schema, not just the bib domain) need >>>>>> an identifier Type with >>>>>> properties of 'identifierValue' and >>>>>> 'identifierType' - which could >>>>>> handle either an enumerated list or at >>>>>> least well known identifier >>>>>> names. >>>>>> >>>>>> >>>>>> I believe that this means that "Identifier" >>>>>> becomes a "schema" in >>>>>> schema.org <http://schema.org/> >>>>>> <http://schema.org <http://schema.org/>>. >>>>>> >>>>>> kc >>>>>> >>>>>> >>>>>> ~Richard. >>>>>> >>>>>> >>>>>> -- >>>>>> Karen Coyle >>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> >>>>>> http://kcoyle.net <http://kcoyle.net/> >>>>>> ph: 1-510-540-7596 <tel:1-510-540-7596> >>>>>> m: 1-510-435-8234 <tel:1-510-435-8234> >>>>>> skype: kcoylenet >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Karen Coyle >>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>> <http://kcoyle.net/> >>>>>> ph: 1-510-540-7596 <tel:1-510-540-7596> >>>>>> m: 1-510-435-8234 <tel:1-510-435-8234> >>>>>> skype: kcoylenet >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Karen Coyle >>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>> <http://kcoyle.net/> >>>>>> ph: 1-510-540-7596 <tel:1-510-540-7596> >>>>>> m: 1-510-435-8234 <tel: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 Wednesday, 5 December 2012 15:41:18 UTC