This post was moved from an email thread about the scope of uniqueness of IDS-ADI ("R number") IDs for template roles.


Rahul,

We have loaded the proto and initial set templates here:
http://facade.iringsandbox.org/TemporaryInitialSetTemplates/sparql

Please give it a try and let me know if you have any problems. I have attached spreadsheets with the template and role IDs.

Darius


Hi Darius,

I am continuing to look through this, still not finished. So far I have one main question: I see that there are things like "hasClass" "hasClass1" "hasClass2"; Shouldn't there be just one "hasClass" with just one R number?

Thanks, rahul


Hi Rahul,

No, template roles with the same name are unique on their own, so if two unrelated templates both have a role called hasClass then those two roles will have different R number IDs. However specialized templates have the same role IDs as their parents. This will let us easily associate a template and other templates specialized from it, because they will share the same role IDs, but they will not share role IDs with any other templates.

Darius


Hi Darius,

No, template roles with the same name are unique on their own, so if

two unrelated templates both have a role called hasClass then those two roles will have different R number IDs.

Can you please explain the assumption behind above statement bit more. Is the assumption coming from part 7 or part 8? because I dont think this is intended in part 7 and might cause issues while moving to JORD.

thanks, rahul


Hi Rahul,

I haven't seen anything about role IDs in Part 7 or 8. The Part 8 sample OWL files use the role name as the ID. Certainly Parts 7 and 8 have nothing about ids-adi (R number) IDs.

I remember some discussions with Julian about whether role IDs should be unique or only unique in the context of a template, and the decision was that they should be unique by themselves. I think this makes sense, and it gives several advantages, such as the ability to change role metadata without affecting other templates, and the ability for specialized and non-specialized templates to interoperate as mentioned before. Do you see any problems or disadvantages with this approach?

Darius


Hi Darius,

Yes, there are issues. Let me try to explain. First of all I agree with the statement :

I remember some discussions with Julian about whether role IDs should be unique or only unique in the context of a template, and the decision was that they should be unique by themselves.

But unfortunately it is little off topic and if anything current implementation is contradicting it.

e.g.

http://tpl.rdlfacade.org/data#R73685972461	hasClass
http://tpl.rdlfacade.org/data#R92056686967	hasClass
http://tpl.rdlfacade.org/data#R75254917408	hasClass
http://tpl.rdlfacade.org/data#R68940711977	hasClass
http://tpl.rdlfacade.org/data#R16697929282	hasClass

reasons :

1. Thought part 8 examples don't use R numbers they use same id similar to "#hasClass" when referring to this role in all the templates. (Verified for examples above). Since IDs are dumb, the only important fact remains that it is same in all the templates.
2. Going back to Julian's statement above even a single id for hasClass is unique by itself. It is not dependent upon any specific template.
3. All the templates which have role name "hasClass" are trying to convey same meaning at that "thing filling that role is at the class level as compared to thing filling the other role(s)" so each "hasClass" role need not have separate id. If the meaning changes then there should be a separate role all together and then off course separate id e.g. #hasRole1.

Thanks, rahul

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