A couple important and relevant references: http://www.w3.org/DesignIssues/Axioms.html#opaque http://tools.ietf.org/html/draft-gregorio-uritemplate-03
Cheers, Sean Vladimir Ivanov wrote: > Dear Martin, > > I think the question of URI schema > is about implementation: (developer's) purposes, decisions etc. > > Are we intend to help developers to create such a schema (or rules)? > >> The question is, if we have >> cataloguing rules, that could allow a larger group to come up with the same >> URI, >> without creating one identifier for two things. > > Very good question! > > I hope, every museum has such set of cataloguing rules. > And we have to share their view of the domain. > (maybe, we can find a common subset of rules or "one-right-rule"). > > Another question: > One of the most specific classes in the CRM is E19.Phisycal Object > (not necessary a "museum item"). > > How to find common rules to biuld unique identifiers for all instances of > E19.Phisycal Object (which are "...items of a material nature that are > units for documentation...")? > Are those rules should be aquisited from documentation? > > 2008/11/30 martin <[email protected]>: >> Dear Vladimir, >> >> The point is not if the URIs are human readable. The question is, if we have >> cataloguing rules, that could allow a larger group to come up with the same >> URI, >> without creating one identifier for two things. If I call you >> xxx578o900yybnn, >> I have to reconcile every reference to you. We cannot avoid that in general, >> but we could create some reasonable rules to reduce the number of >> negotiations. >> AACR2 is a good example from library science. >> >> Since a museum object is at one place at a time, its current location is >> unique, as is >> its current inventory number. These numbers are publicly known. Why should I >> call the >> object xjdisugfvisg, once we could find a more reasonable URI? > > Does "more reasonable URI" means reducing number of negotiations? > What kind of negotiations? > > Best regards > Vladimir > >> We could at least reduce some complexity of the co-reference problem. >> The same holds for people registered in authority files, as long as we are >> sure >> whom we talk about. >> >> Best, >> >> Martin >> >> Vladimir Ivanov wrote: >>> ---------- Forwarded message ---------- >>> From: Vladimir Ivanov <[email protected]> >>> Date: 2008/11/29 >>> Subject: Re: [Crm-sig] URI policies >>> To: Guenther Goerz <[email protected]> >>> >>> >>> Dear Guenther , >>> >>> 2008/11/29 Guenther Goerz <[email protected]>: >>>> Dear all, >>>> >>>> just a brief remark and a recommendation >>>> >>>> On Fri, Nov 28, 2008 at 12:46 PM, Vladimir Ivanov <[email protected]> >>>> wrote: >>>>> Dear all, >>>>> >>>>> Why do we need human-readable URIs? >>>> Well, because occasionally humans read code and this case a label such >>>> as "reply-to-vladimir" has some advantage over "wrzlpfrmpft", although >>>> my machine doesn't care. >>> ;) >>> I mean, why do we need human-readable URIs (for machine processing >>> resources, tasks, etc.)? >>> >>> It's clear to me, that the first label ("reply-to-vladimir") is ambiguous, >>> according to multiple senses of "vladimir". >>> The second one ("wrzlpfrmpft") means nothing at all. >>> >>> In both cases, we need additional information >>> to understand that meaning (if we want to). >>> >>> It's good for CRM classes and properties to have readable labels. >>> Martin's question was also about instances (e.g. museum objects). >>> >>> Best, >>> Vladimir >>>> But, jokes aside: The "Cool URIs" paper >>>> http://www.w3.org/TR/2007/WD-cooluris-20071217/ >>>> may provide a constructive answer to Martin's original request. >>>> >>>> Regards, >>>> -- Guenther >>>> >>>>> Any row in a certain database table could be identified by unique >>>>> (surrogate) key. >>>>> An algorithm should only generate different URI for different resources. >>>>> So, we need to define a difference between resources (or their >>>>> representations). >>>>> >>>>> If identifier should not have any additional inner structure (and >>>>> meaning), >>>>> then we could use GUID. >>>>> >>>>> For example, "http://url.de/E19_ZZZ";, where ZZZ is GUID. >>>>> Add name or content of resource into URI is not a very good idea. >>>>> >>>>> Alternatively, we could use hashing and add any desirable structure into >>>>> URI. >>>>> For example, "http://url.de/cityname_streetname_HASHCODE";. >>>>> >>>>> How to make a URI out of DNA? >>>>> >>>> Best regards, >>>>> Vladimir >>>>> >>>>> >>>>> 2008/11/27 martin <[email protected]>: >>>>>> Dear All, >>>>>> >>>>>> I suggest to discuss in more details policies to use URIs in RDF or OWL >>>>>> instances. >>>>>> >>>>>> For instance, how to describe a museum: >>>>>> >>>>>> How to distinguish the Website from the Actor, if we refer to the >>>>>> museums domain name: >>>>>> MUSEUM/http://www.gnm.de/ ? >>>>>> >>>>>> http://www.gnm.de/MUSEUM ? >>>>>> http://www.gnm.de/ACTOR? >>>>>> >>>>>> If we have a museum URI, we could generate all object IDs by inventory >>>>>> number + museum URL: >>>>>> >>>>>> http://www.gnm.de/OBJECT/AB_45678900_1870 ? >>>>>> http://www.gnm.de/PHYSICAL_OBJECT/... ? >>>>>> http://www.gnm.de/CRM_E19/... ? >>>>>> >>>>>> Does anyone know, if the Getty ULAN suggests a good practice for URIs >>>>>> for ULAN entries? >>>>>> >>>>>> I believe these are issues that should be easy to resolve, and should >>>>>> be quickly resolved. >>>>>> >>>>>> More complicated: How to you make a URI out of an postal address. Any >>>>>> idea, examples??? >>>>>> Best, >>>>>> >>>>>> Martin
