Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Public identifiers and topic maps
 Steve >I've been a bit worried about this so I've been floating trial >balloons about it in the xml-dev mailing list. There is considerable >sentiment to the effect that we're making a mistake here. I've been trying to track this work while I have been away this week. It has been very frustrating because most of the comments seem to be ill-informed in that they were unaware of the main intention of the public attribute, which you explained to me as being to allow the meaning of topic navigation maps to be documented. We must bear this foremost in our mind when considering the role of this attribute and the FPIs it references. The second thing we need to bear in mind is the definitions of FPIs. The following points need to be borne in mind: What we are referring to are basically problems related to owner identifiers, which are defined in ISO 8879 as "The portion of a public identifier that identifies the owner or originator of public text", public text being defined as "Test that is known beyond the context of a single document or system environment, and which can be accessed with a public identifier". No there are two questions that need discussion here: i) what is the difference between an owner and an originator? ii) what does "can be accessed with a public identifier mean? I will come back to these questions shortly. Eliot wrote: >3. That existing naming schemes such as SGML formal public IDs can be used >within a URN context if you're willing to escape lots of special characters >(but we're used to that with URLs anyway). > >4. That URNs cannot be generally used today because there is no >generally-available resolution service. There is a "Real Soon Now" promise >of a service, at least experimentally, but no indication from what I found >that one is available for general use. However, the existence of a trial resolution service for Digital Object Identifiers (DOIs) shows us the way to go. This service, which has been put together by CNRI, who seem to 'own' the whole process for URL identification, suggests that we should be able to use urn:fpi, urn:idn or just fpi: or, better still, idn:, to provide a resolution service for XML users. If we amend the ISO 9070 spec so that one of these is used in place of/addition to the +//IDN currently used to identify the use of internet domain names as owner identifiers we should be able to get an easily automatable service up and running soon after identifying a sponsor for the service (e.g. GCA) Paul Prescod wrote >An FPI is persistent because ISO legally constracts to not reassign them. >This may mean nothing technically, but neither does the fact that the >American government legally asserts that e-commerce transactions based on >USD have value. If either ISO or the American government goes out of >business, their promises are worthless, but by then we'll have other, >bigger problems than our links breaking (which, I guess, is the real >point). FPIs have no legal status. Registered ones must have the names of their ownders declared via the GCA, but unregistered ones have no such constraints, and there in no guarantee that they will be unique. This does not, however, stop them being useful. Eliot riposted: >SGML Formal public identifiers are not necessarily persistent names because >there is nothing in ISO 8879 or ISO 9070 that requires them to be (nor >could such a requirement be enforced or validated). All that ISO 9070 >provides is a process for registering *owner identifiers*, which are, >presumably, persistent (at least as defined by the assigning body). >However, the name owner is responsible for managing the names within their >slice of the FPI name space and can do whatever they want with them, >including reassigning them without regard for persistence at all. The FPIs used in public attributes in topic navigation maps do not need to be persistent: they do need even need to be resolvable. They do need to be "researchable": you should be able to find a copy of the original definition somewhere to be able to ensure that you are using the topic correctly. >According to the current Topic Navigation Map draft (soon to be CD >13250), this would appear as the following FPI: > >-//Sears, Roebuck & Co.//NONSGML TOPIC 1922 Farm Catalog Number : R205//EN Part of the porblem with this whole set of correspondence is the ineptness of this example FPI (sorry Steve). Let me suggest what it should have been: -//TechnoTeacher//NONSGML TOPIC Sears, Roebuck & Co 1922 Farm Catalog Number: R205//EN If this form had been used originally the discussion would never have started. The point is that the owner of the FPI is not the owner of the referenced data, but the owner of the public identifier. (See 8879 definition given above). Claiming to represent Saer Roebuck is not only morally illegal, it is illegal in terms of 8879. Steven Newcomb wrote: >> Will URNs permit pointing to things that aren't now and may never be >> on the web? I mean, things that their owners never intended to be on >> the web and either that their owners do not want to appear on the web, >> or that their owners may not (currently) see any interest in putting >> on the web? URNs may not permit pointing to thins that are not on the web, but Digital Object Identifiers will. They will even allow you to point to information resources that will exsit in the future (one of their biggest advantages from the marketeer's viewpoint). Resolving a DOI can send you to web resources that a) allow you to order a copy of the document when it becomes available b) provide you with name and address of someone who can tell you where to find the data you need or, if really necessary, c) point you to a set of electronic copies of the document and ask you which format you would like to purchase it in. They do not need to resolve to the actual data. Eliots claim that: > Public identifiers, and formal public identifiers in particular, are just >a special case of URN. seems wrong to me. URNs are designed for electronic access. Now, depending on how you interpet the 8879 definition of public text (see above) I am not certain that FPIs need to reference electronically accessible text in the way URNs (or at least URLs) are designed to do. To support this argument let me point out that a special class of FPIs was created to reference data within ISO standards, yet ISO does not allow electronic access to its standards. As the Internet did not exist in 1986 I would argue that the term "accessed" as used in 8879 should not be read as "electronically accessed via a network". At best it can be interpreted as being "electronically accessed in some local system dependent way" (e.g. via a catalog). Eliot also said > Therefore, the PUBLIC/SYSTEM distinction made by >SGML (and XML) is inappropriate as a matter of syntax. A name is a name >and there should be exactly one declared for each entity. While this may be true in an XML context, where FPIs only apply to entity declarations, it does not make sense in the sense they are being used in the topic navigation mao specification, where they are *only* being used to indirectly document the meaning of a topic. Now whether we should claim that the names of the public identifiers used for this purpose should be implicitly similar to those used for identifying entities containing markup declarations or replacement text is another question. Some form of structured name is required. Basing this structure on the existing structure for FPIs makes sense to me. Steve Newcomb wrote: >But what is the correct solution, in your mind? The only alternative >I know of is the HyTime "bibloc" architectural form. In your opinion, >John, should there be a similar architectural form (in XML jargon, >"template") in XML? Or do you have another proposal for indicating >bibliographic references? This just would not be acceptable as a methodology for documenting topic maps, which, I repeat, is what the public attribute is all about. The comment that you originally quoted (from Paul Prescod I believe, though it might have been John Cowan) was; >> # [T]he registration indicator, public text class, and language fields >> # are as specified for formal public identifiers in ISO/IEC 8879:1986. >> # The 'topic authority' [the string after the "+//" or "-//"] is >> # the owner of <em>the information resource</em> that defines the >> # concept. [Emphasis added.] Note that what is bieng complained about here is the definition of topic authority. This term is currently undefined in ISO 13250. To my mind adding the following definition to Clause 4 would solve this misunderstanding: Topic Authority The person or organization responsible for the maintenance of the topic map. The emphasised part of the definition is wrong and should be corrected in ISO 13250. It should be replaced by "the public identifier used to reference the information resource". If we make this small change then we do not need to take in Ricks suggestion at all (though it is a good one). Rick Jelliffe wrote: >Do we need a public text type of TOPIC? You most definitely do. >You could have something like this > >"+//IDN techno.com//TOPIC >Sears, Roebuck & Company:: 1922 Farm Catalog:: [catalog number] R204//EN// >www.techno.com/topics/sr1922r204" You do not need the part after the EN. As shown above, it is simply enough to identify the Topic Authority at the start: you do not need to identify where that authority has stored an electronic copy of the definition, which is all Rick's useful extension adds to what is suggested above. As Rick said: >I think it is important that I should be able to assign a topic, like >the farm catalog above, even if I cannot locate the canonical form, >and there should be a chance my systems will work. This is what the public topic references in clause 6.1.1 of ISO 13250 are designed to do. Mixing this up with other useers of FPIs has muddied the water so much that everybody seems to have missed the illumination that this vital option adds to topic navigation maps. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
