SKOS has a "hiddenLabel" property. There is also SKOS-XL to consider.
Sent from my iPad
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1Joerg,
The character '@' appears also in german WorldCat data as a filing indicator
described in german catalog code RAK-WB Â§ 822, so I assume it propagated to
other german catalogs that deliver bibliographic data on international level.
Example: al- @MathÌ£af al-MisÌ£riÌ„ <al-QaÌ„hira> in
http://www.worldcat.org/oclc/179936500RAK Â§ 822 is located in section 9. something of the rules, dealing withcollation (filing rules). In this section the words to be omitted arevisualized by enclosing them in Â¬...Â¬ (not signs), from my understandingthis is purely illustrative, these signs must never be shown on thedisplay / printed card.BTW Â§ 822 in < http://d-nb.info/986402338/34 > connects to RAK WB Â§ 203,3which actually prescribes the insertion of an artificial blank into"L'aurore" or "al-MathÌ£af al-MisÌ£riÌ„" if the articles fall under non-filingrules. [This is probably to give cataloguers better opportunity to markthe first filing character on the printed card by soft pencil as was(?)common practice]RAK never acknowledged the possibility of storing catalogue information onother media than paper, therefore any markup (e.g. using "@" or "Â¬" tosignify something) apart from ISBD punctuation and RAK-variations thereofalways is completely out of scope for this cataloging code.On the other hand the german data exchange standard MAB2 in its generalsection defines non-filing characters and declares them to enclose thestrings to be omitted, excluding trailing blanks, this yields ("Â¬...Â¬"still a visualization, actually start and end characters have two distinctcodes): "Â¬L'Â¬ aurore" or "Â¬al-Â¬ MathÌ£af al-MisÌ£riÌ„". The artificial blanksare demanded by the cataloging code and the data exchange standard doesnot stand up to remedy this.The MAB non-sort characters are quite universally valid for any field(whenever somebody has the desire to sort differently from the dataentered) and especially they occur in almost every field of the group 3XX(titles, statement of responsibility and the like). The individual fielddefinitions only mention them if some extra meaning is superimposed, forinstance for 331 (title proper) text in nonfiling charactes may be followedby space plus text for filing in brackets as in "Â¬99Â¬ [ninety-nine] redballoons".As for the "@" this is a PICA-ism, cataloguers in the ILTIS system of theDNB mark the first sort position in a field by this character. In theorythat character (and the "/" marking the last position in personal namesrelevant for sorting as in "Goethe, Johann Wolfgang /von") should neverleak out of their system, but since cataloguers on one hand actively enterthe character whenever they find it appropriate and export interfaces onthe other hand have to explictly transcode the situation into the syntaxof the target format, it was already for MAB2 data not uncommon to containsometimes @'s where non-sort characters probably were intended.
Some 15 years ago, there had been a discussion about the most preferred
mechanism for indicating non-filing zones in MARC21. This document discusses the
introduction: http://www.loc.gov/marc/marbi/1998/98-16r.html The result was,
two invisible control characters were assigned a new meaning. The invisibility
of the control characters did not disturb card printing or screen display.
Later, in MODS, a visible <nonSort> XML element was introduced. The reason was,
XML did not allow invisible control characters.Fact is, XML 1.0 (!) does not allow control characters in the range 0x00-0x1fexcept for TAB, CR, and LF (eg. subfield characters are forbidden and haveto be dealt with by other means). The control charcters for non-filing are inthe range 0x80-0x9F and perfectly legal in XML (1.0) documents.MAB-XML transforms the control charaters into an XML element <ns>. I thinkthis is completely natural since XML is all about markup and not marking upby XML means a contiguous character sequence wich has to be marked up anywaywould be quite silly (TEI does but this is since it codes the logical structureand the visual nature of a document it has to resort to kind of "markers" forthe latter in order not to conflict with XML nesting rules for elements).RDF graphs are not very well suited to reflect text with markup, althoughour prevalent case of "texts with one optional *initial* substring withone special meaning" should not be too hard to deal with. I think thesituation is analoguous to unqualified Dublin Core, anyhow it should beclear that solutions which are the "proper XML way" of encoding thingsoften are quite opposite to "proper RDF ways".Non-sort characters are used to mark instances of the concept of non-filingzones as introduced by the cataloging code in actual data. For MAB2 thesecharacters have always been part of the exchange standard's syntax, notdifferent from end-of-field or end-of-record markers. We also have caseswhere a special syntax is specifically defined by the cataloging code andthe data format acts "transparently", i.e. it just transports it. The mostprominent example for this is the use of the comma (",") in the notationof personal names: "Adams, Henry" (invert for everyday usage for most regionsoutside the Alps) or "Mao, Zedong" (simply omit the "," to obtain everydayusage). For a full-featured conversion from MAB2 or MARC21 data into MODSor RDF in these cases one has to peek into the data, extending the analysisfrom the format syntax onto the additional syntax layer specified by thecataloging code the field contents are conforming to.People who not yet have realized that non-sort characters were incorporatedinto the MARC standard in late 2000(?) might think of non-sort characters asa peculiarity of the cataloging rules reigning the record in questionand therefore should always "transparently" dumped/piped into whatever formatMARC21 is exported to. But I think they are wrong since MARC has adopted theconcept, incorporated the syntax and therefore one has to deal with it.
What can we learn? In the punchcard age, it was enough to define two invisible
control characters to assign a new notion of "non-sorting" to interpret ISO2709
streams in a new way. In the XML world, invisible data was no longer allowed,
and non-filing control became visible in markup elements.read: became explicit by markup elements, thus obliviating special controlcharacters. Since XML tags (not elements!) one does not know or does not careabout usually are silently ignored and only textual data is displayed, thiswas very elegant and kind of progress to control characters where one couldnever be certain that some kind of software wouldn't visualize them anywayas control symbols, funny block characters or whatever.
Now today, in Linked Data, a semantic context should be provided, so non-filing
can be applied (or ignored) by programs successfully under any circumstances, if
it's visible or not.Linked Data focusses on data, to some extend neglecting the convenience lyingin the ambivalence of textual data::he foaf:name "Dan Brickley" .is completely independent of:he foaf:familyName "Brickley" ; foaf:givenName "Dan" .the former does not decompose to the latter and the latter you cannot synthesizeto the former (no inherent order of statements, no universal rule with respectto inserting blanks when concatenating strings). Therefore you will always haveto supply both forms in the cases where sorting or deeper analysis /and/ kindof display is needed. With any kind of titles we are in a comparable situation.(Worse yet: Our "Brickley, Dan" with inversion and comma does not fit in eitherof these aspects nor does our "L' aurore" with the extra space since thecataloging rules mandate "normalization" upon data entry and therefore even our"transcribed" elements often are quite distorted ...)In library land we have a long tradition in entering all kind of importantinformation twice: In normalized form as for headings and transcribed fromthe source or as note for display. "XML" gave us some promise to overcomethat by augmenting transcriptions with clever markup, "RDF" defeats thatagain. The lesson to learn therefore is not to rely on RDF (a format) asa device for data entry: In our domain the concept of personal name and howto code it is common enough to expect tools which properly react on a ","typed in. And titles as transcribed elements superimposed with instructionsfor sorting are also common enough to expect tools which spare us thelabor of duplicate entry (hey: we have a computer and a mouse and a databaseand should use that, where RDF is just plain data).
I think the non-filing indicator characters are just one case that demonstrates
the importance to annotate the meaning of symbols in bibliographic strings that
serve special semantics (there are more symbols, for example "Ordnungshilfen" =
filing hints, or cataloger's comments in brackets '[' and ']'). In Linked Data
enviroments like Bibframe, there must be also some information about the context
of the interpretation of the bibliographic string, that is, what are the special
symbols in the string, and what catalog rules should be referred to for special
symbol interpretation.I strongly object. Linked Data is all about providing data /void/ of anyburied private (arcane, domain-specific) meaning introduced by characters(visible or not) which do not stand for themselves.One could define library specific RDF datatypes for those literals we knowas "titles" or "personal names" and these even could have XML embedded. Butthis is a mechanism valid for syntax (restricting arbitrary strings to thosewith a comma or <ns> Tags at certain positions) and has nothing to do withsemantic subdivision of these names or titles (there are no constructs allowingstatements like "in this kind of string the character '@' has the followingmeaning: ...") and therefore are no viable solution.viele GruesseThomas Berger-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.13 (Cygwin)Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/iJwEAQECAAYFAlEgP5QACgkQYhMlmJ6W47PCmQQAqBBHgHjNlsHrchZXdI4Gqf5oulZNokG8HnnkngUtFD9kYT6b5qj7reM3R7VhPHSjXDAt/WUtrAKCHh91u+xT/5D6bihf+ThDcIIFBZPfQF5We3mbbhIg7KLsru+5L5A4DUBc3/z2Onk0Wqs4G0VdvkLWNRJAT1EN3qiflULOWyg==IpNG-----END PGP SIGNATURE-----