Hi Thomas,

That sounds exactly as what we would suggest. Why don't you send us your 
specifications
in detail? Do you think this is only your local problem?

How do you select/disambiguate the category identifiers "object","collection" 
etc.?

Best,

Martin

Thomas Wikman wrote:
Not sure i'm getting all of this either. But since we are using XMPP
more than HTTP we will probably abandon the URI approach used until now
since URI:s in some sense are HTTP-"oriented".

The other problem for us with URI:s are speed. I want GUID:s to be safe
and as abstract as possible but Jacob wants integers to be able to get
max speed while searching in the "XMPP-Cloud".

For these reasons we will probably use something like this in the next
project:

Always local:
urn:grm.se:object:<local identifier> (pref integer) urn:grm.se:collection:<local identifier>


Local until matched with global/persistent id:s
urn:grm.se:actor:<local identifier>
urn:grm.se:place:<local identifier>
urn:grm.se:schema:<local identifier>
urn:grm.se:concept:<local identifier>
urn:grm.se:event:<local identifier>
etc

"global/persistent id:s"
urn:some_actor_authority.se:actor:<local identifier>
urn:some_place_authority.se:place:<local identifier>
urn:some_class_authority.se:schema:<local identifier>
urn:some_class_authority.se:concept:<local identifier>
urn:some_event_authority.se:event:<local identifier>
etc

Hopefully this means that we could resolve the "where" part very quickly
and then use the integer <local identifier> part for searching or look
up.

In an controlled environment resolving these urn:s in to look ups may be
rule based:
* urn:grm.se:object:42 -> http://www.grm.se/objects/html/42 ,
http://www.grm.se/objects/rdf/42 etc or
and some other rule based resolver for XMPP


Otherwise we might use something like:
...
<resource identity=urn:grm.se:object:42>
        <resourceinfo http-html=.......>
        <resourceinfo http-rdf= .......>
        <resourceinfo xmpp-crm= .......>
        <resourceinfo xmpp-museumdat= .......>
        <resourceinfo xmpp-spectrum= .......>
</ident>


As I said, maybe out of topic but since we are planning for this right
now suggestions for better solutions would be nice...

/ tw

On Wed, 2008-12-03 at 12:53 +0100, Øyvind Eide wrote:
Dear Vladimir and Martin,

Just to see if I understand the discussion correctly: Are you talking
about URNs? If not, what is the difference?

http://en.wikipedia.org/wiki/Uniform_Resource_Name


--

/ Kind regards,
/ Øyvind Eide, Unit for Digital Documentation, University of Oslo
| Postal adr.: P.O. Box 1123 Blindern, N-0317 OSLO, Norway
\ Phone: + 47 22 85 49 88   Fax: + 47 22 85 49 83
\ http://www.edd.uio.no/


On Mon, Dec 01, 2008 at 10:24:17AM -0500, Vadim Soshkin wrote:
Dear Martin,

You are right museum object could be identified by museum local identifiers and 
global identifier of the museum itself. But I do not know any registry to 
provide unique identification of museum. Do you have suggestions how to 
uniquely identify museum?

Thanks and best regards

Vadim

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of martin
Sent: Sunday, November 30, 2008 1:50 PM
To: Vladimir Ivanov
Cc: crm-sig; [email protected]
Subject: Re: [Crm-sig] Fwd: URI policies


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?

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
--

--------------------------------------------------------------
 Dr. Martin Doerr              |  Vox:+30(2810)391625        |
 Principle Researcher          |  Fax:+30(2810)391638        |
                               |  Email: [email protected] |
                                                             |
               Center for Cultural Informatics               |
               Information Systems Laboratory                |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
                                                             |
 Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                             |
         Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig


--

--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Principle Researcher          |  Fax:+30(2810)391638        |
                                |  Email: [email protected] |
                                                              |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                                                              |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                              |
          Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig






--

--------------------------------------------------------------
 Dr. Martin Doerr              |  Vox:+30(2810)391625        |
 Principle Researcher          |  Fax:+30(2810)391638        |
                               |  Email: [email protected] |
                                                             |
               Center for Cultural Informatics               |
               Information Systems Laboratory                |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
                                                             |
 Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                             |
         Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------

Reply via email to