(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 http://www.iringsandbox.org/SandboxService/sparql.

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 tpl.rdlfacade.org 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: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT * WHERE {
  ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://tpl.rdlfacade.org/data#R16376066707>  . ?s <http://www.w3.org/2000/01/rdf-schema#label> ?l
}

At http://www.iringsandbox.org/SandboxService/

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

https://www.posccaesar.org/wiki/SigMmt/Templates

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

xmlns:p7tpl=http://standards.tc184-sc4.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl#

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

xmlns:iringtpl=http://tpl.iring.org/data#

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 http://tpl.rdlfacade.org/data# to http://tpl.iring.org/data# and http://standards.tc184-sc4.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl# ?

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 rdlfacade.org, and there have been changes to these classes that are not in rdlfacade.org. In today's modeling meeting we briefly discussed using the existing set of dm.rdlfacade.org 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 tpl.iring.org because there is nothing iRING-specific about these templates. That is why we have used the http://tpl.rdlfacade.org/data# namespace.

2) The p7tpl namespace (http://standards.tc184-sc4.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl#) 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
PCA ID http://rds.posccaesar.org/2008/06/OWL/RDL#RDS14070385
SC4 ID http://standards.tc184-sc4.org/iso/15926/tech/reference-data#RDL3691
RDS/WIP ID http://rdl.rdlfacade.org/data#R10041856346
and probably others. We will have the same situation with templates. A proto or initial set template will have
an SC4 ID like http://standards.tc184-sc4.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl#??????
and a RDS/WIP ID like http://tpl.rdlfacade.org/data#R65141162308

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 “http://tpl.rdlfacade.org/initial/data#R123456" and "http://tpl.rdlfacade.org/proposed/data#R123456" or "http://tpl.initial.rdlfacade.org/data#R123456" and "http://tpl.proposed.rdlfacade.org/data#". 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.

Robin


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 http://tpl.rdlfacade.org/data# (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.

Namespace:

While particular project specializes / extends initial set templates it is quite possible and valid to use a different namespace than http://tpl.rdlfacade.org/data# 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 http://tpl.rdlfacade.org/data# endpoint, we are planning on adding them to http://www.iringsandbox.org/SandboxService/. 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 to shield 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).

thanks,
rahul


Hi Rahul,

I think the flaw with URI's is that they are not pure identifiers. They have an address in them and I think we are abusing the purpose of that address.

What is most important about a URI is that it provides truly global unique identifiers. The reason why an address is included is that it is the address of the identifier issuing authority or endpoint – and nothing more. The address included in the URI should never be interpreted as the status, state, or location of the thing that is being identified. That is what is messing us up.

I fully agree in federation of RDL content. There is no need to put RDL content in one place. And separating RDL content at various endpoints based on any reason including ownership, status, etc is fine by me. So I think we are aligned there. However, I do not think the identifier issuing authority must be at the endpoint where the RDL thing is being accessed. It could be the same but there should never be a requirement that it is the same.

If we bind interpretation of status, state, access location, etc of RDL content into the identifier then I think we are in big trouble. The reason is that the identifier must be forever but its status, state, location, etc in time and space will not be forever.

When http://rdlfacade.org was created its sole purpose was to be an identifier issuing authority. We never intend initial content of whatever status, state, or location to be originated there or even end up there.

So if you use URI’s in a pure KISS (Keep It Simple Stupid) manner, then we can continue to generate identifiers free of its status, state, location, etc and have the most reliable identifiers at the lowest cost possible.

Robin


[Copied Robin's last post and added inline comments from Rahul]

Hi Rahul,

I think the flaw with URI's is that they are not pure identifiers. They have an address in them and I think we are abusing the purpose of that address.

[rahul] - Actually, I did not mean this (the abusing of the address part). I think you are talking about resolvable ids, if yes then that is slightly different from what I am saying. First statement could be difference between URN and URL.

What is most important about a URI is that it provides truly global unique identifiers. The reason why an address is included is that it is the address of the identifier issuing authority or endpoint – and nothing more. The address included in the URI should never be interpreted as the status, state, or location of the thing that is being identified.

[rahul] - Agree.

That is what is messing us up.

[rahul] - it could be, but certainly not the focus of this thread (unless, i am misunderstanding your point, are you referring to resolvable URLs?).

I fully agree in federation of RDL content. There is no need to put RDL content in one place. And separating RDL content at various endpoints based on any reason including ownership, status, etc is fine by me. So I think we are aligned there.

[rahul] - Great! I think that was almost 90% of focus of this thread.

However, I do not think the identifier issuing authority must be at the endpoint where the RDL thing is being accessed. It could be the same but there should never be a requirement that it is the same.

[rahul] - couldn't agree more. Can I put it like : "URIs used for ids need not be resolvable".

If we bind interpretation of status, state, access location, etc of RDL content into the identifier then I think we are in big trouble. The reason is that the identifier must be forever but its status, state, location, etc in time and space will not be forever.

[rahul] - Agreed.

When http://rdlfacade.org was created its sole purpose was to be an identifier issuing authority. We never intend initial content of whatever status, state, or location to be originated there or even end up there. So if you use URI’s in a pure KISS (Keep It Simple Stupid) manner, then we can continue to generate identifiers free of its status, state, location, etc and have the most reliable identifiers at the lowest cost possible.

[rahul] - completely agree.

Home
About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std
Projects
Search