Discussion on Profile Structure Point9
Does a key definition consist of its URI and its type and value space? (see issue #1)
The definition of a key consists of its URI, and its type and value space (e.g. enumerated values, integer). (See http://myurc.org/TR/res-prop-vocab1.0/ as an example.)
A number - rather than a name is used for the unique ID although both would be provided in the URI for human reference (e.g. reg.gpii.net/core/34200(name) )
- In addition to facilitating internationalization - it also allows a preference to continue working even if the name is changed
- For internationalization the NAME and DESCRIPTION of each key is stored separately. I recommend using the ISO template we set up for Metadata for Learning Resources...
- Why using a number for the sake of internationalization? It is better to use an English term (that is still human readable) than using an arbitrary number with no reminescense to the topic. English terms are equally suited for internationalization, but easier and less error-prone for developers. Do you really like those generated URIs of the form "http://example.com/?page=1434"?
- NOTE: There may never be other language versions-- it may be that all people who do profiles will always speak english well. But i don't think we should assume that -- and should make it easy for a machine to process a profile that is in another language without having to do language translation on it.
- When presented to humans, the number (or the whole URI) can be replaced with the NAME in the language of the user
- Core and live share the same namespace. Othewise promoting something from live to core will break all past uses
- CORE would be a flag in the registry rather than a different namespace. and the example would be reg.gpii.net/common/34200(name)
- What is the needs for this if we are using namespaces and if we allow for/expect people to use local translations of property names in their wizards etc? eg a Russian version but it still refers to the original namespace?
- If we edit the name - it would break all of the existing profiles. the number would be the unique id - not the name.
- I was suggesting that the NUMBER be the Unique ID. That way, if we find that we have chosen the wrong name -- or have to add a word to it to make it more specific (e.g. "volume" is changed to "volume-main" ) we don't break all the profiles out there. BUT I have thought about this for a bit more - and i now think that we should have BOTH a NUMBER and an ENGLISH NAME for each item. People read the NAME and machines read the NUMBER. That way it is alway human readable and yet we can change the name if we have to. Our tools can always update the name to the latest form each time they touch the profile. And people from different countries can always have the name displayed in their language if the choose when they view the registry. in fact we can have parallel copies of the registry in different languages (tied together by the number). The ENGLISH language registry however would be the master. The others for convenience - since it will contain both the NAME and the DESCRIPTION in their language.
Having a number and a name is worse than just one of them. We make the URI longer, and introduce more sources for errors. If either the number or the name is changed this means a different URI and thus a different property. For example, http://reg.gpii.net/common/34200(volume) is a different property from http://reg.gpii.net/common/34200(main-volume). We don't need a number for machine readability - machines can read names just as well as numbers. But for humans words are easier to read, to remember and less error-prone. I claim that http://reg.gpii.net/common/volume is better than http://reg.gpii.net/common/34200. In any case, we will define human-readable labels for each property URI in any language - even for the English language. Thus we can change the English label even after the URI has been specified. Note that this doesn't mean that we have different registries for different countries. We have only one registry, and in there we define the property URIs and for each human-readable labels for many languages, including English. If you look at any of the standards that we have looked at so far, they are all using names in some or the other way to define properties, rather than plain numbers. Examples from Dublin Core and ETSI: http://purl.org/dc/elements/1.1/title, http://purl.org/dc/terms/conformsTo, http://uri.etsi.org/upm/interaction-preferences/interaction-timeout, http://uri.etsi.org/upm/interaction-preferences/preferred-output-modality (and i stongly suggest we just adopt their URIs into our registry).