Version 9 (modified by rahul, 12 years ago)


(Moved from an email thread)

Hi Darius,

We had decided on a task to update the iRING sandbox with latest base templates. I have some questions about it. Please help me find answes.

1. Where are the current templates hosted? (end point address)
[Darius] We currently have templates loaded at

2. How are they hosted? Owl file exposed on webserver or triple store?
[Darius] Currently in a triple store.

3. Are there separate endpoints for initial set and ones created by us (iring modelers) ?
[Darius] Both are in the same endpoint, but of course the RDF can be loaded anywhere. We are using the namespace for template and role IDs for proto and initial set templates as well as for templates defined by us. As we discussed a couple of weeks ago, Part 8 has a p7tpl namespace for SC4 IDs for proto and base templates, but I don’t think this means that we have to have a separate proto/base template namespace for the “R#” IDs. I think it’s better to keep the IDs “dumb” and use classification to group the proto-templates, initial set templates, and whatever else we want.

4. How the ids should be generated for new templates?
[Darius] We use the ids-adi ID generator service. The iRINGTools spreadsheet loader and ref data editor both call the service. We may build an ID generator in iRINGTools later.

5. Whom should I coordinate with on moving this forward?
[Darius] This is a good start! We can look at writing a utility to read the proto and initial OWL files and generate R# IDs, or just paste them into a spreadsheet and run the loader since there is a fairly small number.

Thanks, rahul

Hi Darius,

Thanks for the information. I went through the list of templates at iring sand box by firing following query:

PREFIX rdf: <>
  ?s <> <>  . ?s <> ?l


and compared it with the list on the PCA wiki (which is same as part 7 initial set)

I think we should do following two things :

1. Make sure all templates listed at posccaesar wiki are added to iring sandbox.

2. Separate additional (base and speciliazed) templates at iring sandbox from the ones in item 1.

Let me know if you agree to this and suggest a way forward.

Thanks, rahul

Hi Darius,

I compared all the templates listed at PCA wiki and on iRING site. Results are attached in “compareCapture.jpg”. I have also attached the txt files separately.
As you can see only 3 templates are common in both the lists. i.e. most of the templates from part7 initial set do not have a R number yet.

So, I suggest we add all the missing templates from part 7 initial set to iring sandbox.
While doing so we use following namespace


we also change the namespace for 3 initial set templates which are already present in iring sandbox.

Later on we should change the name space for all exiting templates in iring sandbox to


let me know if it makes sense.

On a related note, I did not understand following comment from you completely.
Darius>> As we discussed a couple of weeks ago, Part 8 has a p7tpl namespace for SC4 IDs for proto and base templates, but I don’t think this means that we have to have a separate proto/base template namespace for the “R#” IDs. I think it’s better to keep the IDs “dumb” and use classification to group the proto-templates, initial set templates, and whatever else we want.

I think I am ok with the idea of keeping IDs dumb (part after #R123456). But I am not sure if we want to add extra complication by adding classifications when part 8 clearly states the namespaces is the recommended way to handle such situation. Is there any technical issue from iring tools side to change the namespace from to and ?

Thanks, rahul

Hi Rahul,

We (Devesh) have put all of the proto and intial set templates into spreadsheets for generating "R#" IDs and producing RDF for loading into a sandbox. We will preserve the R# IDs of the few templates that we loaded previously. We will generate the IDs and RDF as soon as we resolve two issues:

1) The namespace issues you raise for the template IDs (more below).

2) The IDs to use for role types that are Part 2 entity types. We were using the R# IDs for the Part 4 punned classes. For the proto and initial set templates we need IDs for many more entity types. I don't think they are all available in, and there have been changes to these classes that are not in In today's modeling meeting we briefly discussed using the existing set of IDs instead. Onno explained the controversy about the entity types of the punned classes. I would like to follow up on this idea of using the dm IDs for role types, as it seems much cleaner and sidesteps our current issues with the punned classes.

Two comments on the namespace for template IDs:

1) We don't want to use because there is nothing iRING-specific about these templates. That is why we have used the namespace.

2) The p7tpl namespace ( in Part 8 is fine, but this is the namespace for the ISO/SC4 IDs, not the RDS/WIP "R#" IDs. We have the same issue in Part 4 of different IDs that must be mapped. For example, the AIR HEATER class has
and probably others. We will have the same situation with templates. A proto or initial set template will have
an SC4 ID like
and a RDS/WIP ID like

There is a page that Julian made on RDS/WIP domains here.

As for iRINGTools, yes there is a minor technical issue, but it does not influence our thoughts on namespaces. The iRINGTools reference data editor has one (configurable) namespace it uses to generate IDs for new classes (using the IDS-ADI ID generator), and one (configurable) namespace for new template IDs. So currently a user cannot pick from a list of namespaces when creating a new class or template. But this would not be a major effort, and again it had no bearing on the discussion above.

Lastly, about my classification comment, Magne made the point in the workshop that classification (using ClassOfClass?) is used heavily in 15926 for grouping classes for various purposes. I think it's a more reliable and flexible way to group templates than relying on the ID namespace.

Hi Darius,

I am not so keen on which two namespaces we use at this point. But what I would push for is to hold initial set (reviewed and checked by part 7 modelers) and specialized (and proposed base - not completely reviewed by modelers and lifted properly) in separate namespaces. One thing is that it gives a visual indication just by looking at the namespace of id and importantly that is how part 8 suggest it to be. When all these will get moved to final ids, that’s how they are going to be separated. Then why not just maintain two separate set of namespaces from beginning? I don’t have much issue which ones we use, I am good for going with something like “" and "" or "" and "". This becomes important while mapping as mapping person can be cautioned that ones from proposed set may change (hopefully slightly).

Also, from eventual implementation point of view: In the end, 1. Base and initial templates will be located at a separate endpoint with a separate (standard) namespace and 2. Specialized templates (may be for a specific project or workflow) will be located at a separate (controlled by the participating organizations) endpoint with a separate namespace.

We have an opportunity to create this scenario today. We should build and test our applications against that otherwise things will break when everything is moved to ISO control and I don’t think we can afford doing that.

thanks, rahul

Hi Rahul,

I am not clear if you are proposing that the state of a class or template that is reflected in the URI will have to be changed once the state of a “proposed” item is elevated to a higher status. If that is the case then I am absolutely against this approach because it will undermine the primary purpose of identify which is immutability. Secondly, I am opposed to put any kind of intelligence into the identifier just on principle alone. We need non interpretable identifiers. Deriving state from the identifier goes against that principle. Violating the principle will lead to higher cost to operate and also result general confusion when the intelligence has to change.

No matter how we solved the namespace, immutability of identifiers is paramount.


Hi Robin,

I am with you on the immutability of ID principle and I am not proposing anything against it. I am not even suggesting anything like changing URI of proposed item. Probably word “proposed” might be misleading. I meant to convey “something that is not part of initial set and not certified by lifting”. May be we could use “appended”.

Let’s look at what I am suggesting in little more detail: There are two aspects to what I am trying to convey.

1. Location (end point address) of initial set vs proposed (enhanced, additional, appended) templates,

2. Namespace of initial set vs proposed templates.

Endpoint Address:

Let’s consider a hypothetical scenario, in the ideal world: Initial set templates (which are part of part 7 and certified by modelers by lifting) would reside at (or equivalent) Now, imagine a particular engineering project wants to use some specialized templates (which are not certified by modelers or lifted completely) then such templates would reside at a different endpoint (probably at an endpoint controlled by (and accessible to) particular project participants) Any application participating in such engineering project should be able to get template definitions from these different (multiple) endpoints. Applications must be developed and tested for this scenario.


While particular project specializes / extends initial set templates it is quite possible and valid to use a different namespace than for such templates (for various; good and bad reasons). We simply cannot mandate people to use same namespace. So again, applications must be developed and tested for such scenario. Since, we are not able to add ‘part 7’ initial set templates to endpoint, we are planning on adding them to We are also adding proposed templates to the same endpoint with same namespace. With this we are missing out on test cases.

Also, keeping separate endpoints will help implementers from ‘in processes modeling clutter. During mapping exercises, it’s much easier to tell an engineer to point to a specific endpoint (if he only wants to use certified templates for a particular map).


About PCA
Reference Data Services