There are things that could be improved about the KBART guidelines (and you've picked on one here I definitely agree with). 

There is an interest group mailing list which can be used for discussion/feedback http://www.niso.org/lists/kbart_interest/

I suspect that for both approaches at the moment the question of uptake/compliance is the bigger issue.

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]
Telephone: 0121 288 6936

On 17 Oct 2012, at 14:48, Jonathan Rochkind <[log in to unmask]> wrote:

> I've always been a fan of ONIX for SOH, although never had the chance to use it -- but the spec is written nicely, based on my experience with this stuff, it actually accomplishes the goal of machine-readable statement of serial holdings (theoretically useful for print or online holdings) well.
> 
> KBART, I have some concerns about, when it comes to holdings. Is there a place to send feedback to KBART?  Just on a quick skim of the parts of interest to me, I am filled with alarm at how much missing the point this is:   " we recommend that the ISO 8601 date syntax should be used...  For simplicity, '365D' will always be equivalent to one year, and '30D' will always be equivalent to one month, even in leap years and months that do not have 30 days."
> 
> Totally missing the point of ISO 8601 to allow/encourage this when 1Y and 1M are available -- dealing with calendar dates is harder than one might naively think, and by trying to 'improve' on ISO 8601 like this, you just create a mess of ambiguous and difficult to deal with data.
> 
> On 10/17/2012 5:11 AM, Owen Stephens wrote:
>> Are there any examples of data in this format in the wild we can look at?
>> 
>> Also given KBART and ONIX for Serials Online Holdings have NISO involvement, is there any view on how these two activities complement each other?
>> 
>> Thanks,
>> 
>> Owen
>> 
>> Owen Stephens
>> Owen Stephens Consulting
>> Web: http://www.ostephens.com
>> Email: [log in to unmask]
>> Telephone: 0121 288 6936
>> 
>> On 17 Oct 2012, at 09:47, Michael Hopwood <[log in to unmask]> wrote:
>> 
>>> Hi Godmar,
>>> 
>>> There is also ONIX for Serials Online Holdings (http://www.editeur.org/120/ONIX-SOH/). I'm copying in Tim Devenport who might say more.
>>> 
>>> Best wishes,
>>> 
>>> Michael
>>> 
>>> -----Original Message-----
>>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Owen Stephens
>>> Sent: 16 October 2012 23:09
>>> To: [log in to unmask]
>>> Subject: Re: [CODE4LIB] Q.: software for vendor title list processing
>>> 
>>> I'm working on the JISC KB+ project that Tom mentioned.
>>> 
>>> As part of the project we've been collating journal title lists from various sources. We've been working with members of the KBART steering group and have used KBART where possible, although we've been collecting data not covered by KBART.
>>> 
>>> All the data we have at this level is published under a CC0 licence at http://www.kbplus.ac.uk/kbplus/publicExport - including a csv that uses the KBART data elements. The focus so far has been on packages negotiated by JISC in the UK - although in many cases the title lists may be the same as are made available in other markets. We also include what we call 'Master lists' which are an attempt to capture the complete list of titles and coverage offered by a content provider. We'd very much welcome any feedback on these exports, and of course be interested to know if anyone makes use of them.
>>> 
>>> So far a lot of the work on collating/coverting/standardising the data has been done by hand - which is clearly not ideal. In the next phase of the project the KB+ project is going to work with the GoKB project http://gokb.org - as part of this collaboration we are currently working on ways of streamlining the data processing from publisher files or other sources, to standardised data. While we are still working on how this is going to be implemented, we are currently investigating the possibility of using Google/Open Refine to capture and re-run sets of rules across data sets from specific sources. We should be making progress on this in the next couple of months.
>>> 
>>> Hope that's helpful
>>> 
>>> Owen
>>> 
>>> Owen Stephens
>>> Owen Stephens Consulting
>>> Web: http://www.ostephens.com
>>> Email: [log in to unmask]
>>> Telephone: 0121 288 6936
>>> 
>>> On 16 Oct 2012, at 20:23, Tom Pasley <[log in to unmask]> wrote:
>>> 
>>>> You might also be interested in the work at http://www.kbplus.ac.uk .
>>>> The site is up at the moment, but I can't reach it for some reason...
>>>> they have a public export page which you might want to know about
>>>> http://www.kbplus.ac.uk/kbplus/publicExport
>>>> 
>>>> Tom
>>>> 
>>>> On Wed, Oct 17, 2012 at 8:12 AM, Jonathan Rochkind <[log in to unmask]> wrote:
>>>> 
>>>>> I think KBART is such an effort.  As with most library standards
>>>>> groups, there may not be online documentation of their most recent
>>>>> efforts or successes, but: http://www.uksg.org/kbart
>>>>> 
>>>>> http://www.uksg.org/kbart/s5/**guidelines/data_format<http://www.uksg
>>>>> .org/kbart/s5/guidelines/data_format>
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/16/2012 2:16 PM, Godmar Back wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> at our library, there's an emerging need to process title lists from
>>>>>> vendors for various purposes, such as checking that the titles
>>>>>> purchased can be discovered via discovery system and/or OPAC. It
>>>>>> appears that the formats in which those lists are provided are
>>>>>> non-uniform, as is the process of obtaining them.
>>>>>> 
>>>>>> For example, one vendor - let's call them "Expedition Scrolls" -
>>>>>> provides title lists for download to Excel, but which upon closer
>>>>>> inspection turn out to be HTML tables. They are encoded using an odd
>>>>>> mixture of CP1250 and HTML entities. Other vendors use entirely different formats.
>>>>>> 
>>>>>> My question is whether there are efforts, software, or anything
>>>>>> related to streamlining the acquisition and processing of vendor
>>>>>> title lists in software systems that aid in the collection
>>>>>> development and maintenance process. Any pointers would be appreciated.
>>>>>> 
>>>>>> - Godmar
>>>>>> 
>>>>>> 
>>>>>> 
>> 
>>