View unanswered posts | View active topics It is currently Thu Feb 21, 2019 11:58 am

Reply to topic  [ 5 posts ] 
 Do we really need The Globally Unique IDs? 
Author Message

Joined: Tue May 15, 2012 7:06 am
Posts: 12
Collegues, it seems that we have a problem!

1. We (Rosatom RDS developers) really don't understand what profit in usage of Globally Unique IDs?

Because old-style URIs = namespace + LocalID (no matter human-readable or not) will be globally Unique by definition (even if local ID is just a sequence number). So what we need in Globally Unique IDs anyway? What problems they are solving?

2. Moreover, R-UUID things using without namespaces brings a really serious performance issues:

When we are walking throught the graph that consist of nodes from different RDLs we must to poll all available RDLs just to understand from what namespace this R-UUID from for every (!) single node. Some ideas of usage of "master look-up table" in core RDL is a performance penalty too. So a word from technical guy: we don't use an own network protocol or stack. Its all about HTTP. So we don't need a MAC-like R-UUIDs and DNS-like "master look-up tables". We are already have DNS, thank you.

So we really want to understand for sake of what technological advantages we are sacrifying technical consistency. All ideas will be highly appreciated!.

Nice example: try to imagine that all names of towns, streets, houses were abolished and invented a global registry of persons, so if you want to know where exact person lives try to call to information desk of all available towns until desired person will be founded. Some sort of bizzare isn't it?

Tue Jan 29, 2013 7:22 am

Joined: Sun Jan 22, 2012 9:14 pm
Posts: 189
The identifier consists of
I.e. there is always a namespace.

The GUID suggestion is about changing the namespace. If the namespace changes, we don't want the fraction identifier to change as well, just to be unique under the new namespace. Logical solution is to use fraction identifiers that are guaranteed to be unique already.

The namespace should normally not change. For example, contractor Abc is building a plant for client Def. The contractor asks for a namespace to use, just like she asks for Unit and Area numbers, and a tag / document naming convention. The contractor then uses that namespace and hands-over the data at some point in time, where the data is moved from one database to the other, now with a meaningful (but same) namespace.

However we cannot give out a rule that a namespace shall never change.
It can, so it will. Murphy's law.
For that purpose we have suggested to use fraction identifiers that don't have to change.

Tue Jan 29, 2013 10:24 am

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
Onno, this is why Pavel's point 2 is completely on the mark! If iRING people want to preserve R#s - they have to use them as GIUD's, but move them to new namespace(s).

Some of R#s are now really in a special correspondence graph at JORD endpoint, some remain at iRING sandbox. But all remain in the namespace. Nightmare, and not documented anywhere.

I've tried to describe it to iRING people in private correspondence. They think that any further changes will be a danger to their functioning business environment. Without specific knowledge about this environment I can not confirm or deny that. But I hope at some point community will help them identify acceptable solutions.

Tue Jan 29, 2013 10:52 am
Profile WWW

Joined: Sun Jan 22, 2012 9:14 pm
Posts: 189
Victor, agreed with that.

We had the problem of installed base (programs/databases already using the data) already a couple of times.
The solution we came up with was to allow an object to have multiple namespaces and IDs.
But not to have no namespace; that is always wrong.

So an object can have a namespace + R-number. We won't change it. We will add a new namespace-fraction identifier. To not break the installed base.

Do you have a better solution?

Tue Jan 29, 2013 11:46 am

Joined: Sun Jan 06, 2013 12:03 am
Posts: 5
It is worth to note that no one is forcing you to use the GUID. If you are happy with using the URI of a class as an ID, you may. As long as you keep track over ontologies not under your control, and are prepared to update URIs as classes move from one repository to the next, you'll have no problems.

I think it is a fair assumption that if you don't see the point in the GUID, you won't have any trouble just ignoring it for the most part. If nothing else, this solution saves us from <namespace>+R+<guid> URIs.

At least this is how I understand it. Corrections welcome.

Morten R. Strand
Det Norske Veritas (DNV)

Tue Feb 12, 2013 1:30 pm
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
eXTReMe Tracker
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.