[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Published Subject Identifiers and Indicators for UBL 2.x
At 2007-12-11 00:06 -0800, jon.bosak@sun.com wrote: >MINUTES OF PACIFIC UBL TC MEETING >TUESDAY 11 DECEMBER 2007 >... >OTHER BUSINESS > > GKH: Request that we include ISO Public Subject Indicators > (PSIs) for all UBL constructs as a deliverable for UBL 2.1. > Background: a PSI is a URI that resolves to a human-readable > document describing a particular semantic, thus enabling the > subject to be unambiguously referenced in a Topic Map (ISO > 13250). JB committed to providing PSIs for UBL 1.0 a couple of > years ago but didn't find the resources to do it. Assuming > that the semantics of UBL 2 will not change during the 2.x life > cycle (modulo minor corrections to the definitions), we propose > to create official PSIs for every UBL construct. > > AGREED to add this item to the list of deliverables with GKH as > the person who will synthesize about 2000 XHTML pages from > spreadsheets, each page keyed to a unique Dictionary Entry Name > (DEN) and representing the columns of each entry as bullets on > its PSI page, the pages to eventually be archived at > psi.oasis-open.org/ubl2/ (see psi.oasis-open.org for the > beginnings of the OASIS PSI repository). I don't think we have to wait until either 2.0 update or 2.1 ... I'm of the opinion that these resources can be published at any time (including the current incorrectly-documented semantics as initial placeholders), because the semantics never *change*, only their documentation can be improved. We are never removing any construct from UBL 2.x, and the semantic of an information item in UBL 2.0 is going to be the same as in UBL 2.x, just the documentation in 2.x for that semantic might be an improved definition. After every release I plan to push the button and recreate the /ubl2/ directory to give to the OASIS web folks to post. So, I'm thinking of making the identifiers along the lines of: http://psi.oasis-open.org/ubl2/Address.Details/ http://psi.oasis-open.org/ubl2/Address.Identifier/ http://psi.oasis-open.org/ubl2/Address.AddressTypeCode.Code/ http://psi.oasis-open.org/ubl2/Address.AddressFormatCode.Code/ http://psi.oasis-open.org/ubl2/Address.Postbox.Text/ http://psi.oasis-open.org/ubl2/Address.Floor.Text/ http://psi.oasis-open.org/ubl2/Address.Room.Text/ http://psi.oasis-open.org/ubl2/Address.StreetName.Name/ http://psi.oasis-open.org/ubl2/Address.Additional_StreetName.Name/ http://psi.oasis-open.org/ubl2/Address.BlockName.Name/ The indicators would then be the files: http://psi.oasis-open.org/ubl2/Address.Details/index.html http://psi.oasis-open.org/ubl2/Address.Identifier/index.html http://psi.oasis-open.org/ubl2/Address.AddressTypeCode.Code/index.html http://psi.oasis-open.org/ubl2/Address.AddressFormatCode.Code/index.html http://psi.oasis-open.org/ubl2/Address.Postbox.Text/index.html http://psi.oasis-open.org/ubl2/Address.Floor.Text/index.html http://psi.oasis-open.org/ubl2/Address.Room.Text/index.html http://psi.oasis-open.org/ubl2/Address.StreetName.Name/index.html http://psi.oasis-open.org/ubl2/Address.Additional_StreetName.Name/index.html http://psi.oasis-open.org/ubl2/Address.BlockName.Name/index.html As I see it there are no versioning issues ... any old replaced version need not be preserved because it is being replaced because it is wrong. When a 2.x set of files is created, definitions from earlier releases may get replaced, but the old objects retain their old semantics as intended by the group. The first version of the indicators will merely be a dump of the spreadsheet columns associated with the item. If users want more information in the indicator, we can look at changing that in the future. The identifiers will not change, nor will they be versioned ... which is critically important in Topic Map applications ... these have to be stable. The content can change, and I see no reason to keep old content around. In parallel I'm working with Robin Cover to ensure no OASIS policies or practices are being hurt by the making of this proposal. The details of the above may have to change, and if they do so, I'll make a record in this mail list. Thanks! . . . . . . . . . . Ken p.s. thanks, Jon, for putting into the Atlantic minutes the excerpted definitions of terminology -- Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008 World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]