15926.org

Hi Victor,

You are right about the typed node elements, you are applying an abbreviation for describing the typed nodes, but in this case we do not use the rdf:type property. (http://www.w3.org/TR/rdf-primer/)

We can not use OWL reasoner/verifier software now. However, we aim to achieve this strategic stage.
We want to apply this knowledge representation using OWL 2.0 and DL to validate and to check the consistency of the models and a databasis, and we believe that
it can be the more sustainable path to control the growth and the dissemination of reference data.

This is our implementation point of view, that is followed and will be documented as a work methodology for ISO15926.

Regards
Geiza

Hi Geiza.

you are applying an abbreviation for describing the typed nodes, but in this case we do not use the rdf:type property.

Sorry, I don't understand this point. Of course we don't repeat rdf:type property if typed node is used.

ok so my reading of Part 7 ontologies ....... the hasTemplate Roles refer to something of type p7tm:Template
but currently the template definition is only subclassed from #BaseTemplateStatement. While this is 'ok' it is not ideal since it doesn't let me in a tool quickly find items of type template without inferring type from the hasTemplate triples. The reason I can't just list all subclasses of #BaseTemplateStatement is because other subclasses exist that are not Template definitions. I also don't want to rely on the presence of a Template description to interpret a template definition. Can we please declare template definitions as being of type #Template so that this doesn't have to be derived.

thanks

The reason I can't just list all subclasses of #BaseTemplateStatement is because other subclasses exist that are not Template definitions.

I hope there will be none! But I agree that OWL part of the definition should be more rigorous to allow automated reasoning and verification.

From the practical tool development approach we've decided to rely on meta-template statements for identification. I wonder - whether it was an idea for the double description from the very beginning.

In the template definitions provided with Part 8 there are defined subclasses of BaseTemplateStatement that are not Template definitions, hence my request to type the template definitions.

I'm surprised you haven't added identities to the meta definitions since your stating you are relying heavily on these. I understand how you access the definitions but i'd like to be able to query for the definitions without starting with the meta information. My tool implementation would prefer not to start with the meta entries

Lady and gentlemen,

I get so sad when I watch these discussions, because these have as a starting point that the template model of the Part 8 TS is correct, which isn't so.

Why is it that nobody wants to spend a minute on my proposal for an improved template model as set forth in http://www.15926.org/publications/templ ... /index.htm ?

I'm surprised you haven't added identities to the meta definitions since your stating you are relying heavily on these.

Sorry, don't understand this. All metatemplate instances in the example above are identified:

<p7tm:TemplateDescription rdf:about="#Classification__desc">
<p7tm:TemplateRoleDescription rdf:about="#Classification__rdesc2">
ets.

Or do you mean something else?

Metatemplates are not metainformation in the common sense of the word. Definition of template via metatemplates is an alternative almost fully functional way to define a template. For iRINGTools another similar format was developed, they had not even tried to make it OWL.

OWL template definition is not full also, role order is not well defined as well as I understand semantics of rdf:parseType="Collection". OWL representation is not full in another sense also. You can reason on signature (role restrictions), but template axiom is not represented, although OWL(DL) is essentially the same FOL of P7.

I'm implementing my own verification for relationships, templates, patterns - universal reasoning engine. I do not believe in standard OWL reasoning. And I'm not alone - JORD is developing verification rules in SPARQL. We are all waiting for someone to show us use of generic OWL tools for ISO 15926 data.

by identities I was referring to the lack of the defaultRdsId predicates on the meta instances. I would expect all items of significance in an endpoint to have a defaultRdsId defined, including the meta instances.

I'm aware Victor your not a fan of OWL reasoning. My request is simple, to avoid the need for OWL reasoning based on predicate definitions please explicitly type the template definitions as Templates instead of only subclassing them from BaseTemplateStatement. This will make it easier for me to implement template recognition as was done in the initial set.

Hans, I know you are pushing your revised model hard for acceptance. I do not assume that the P8 spec is correct, but when trying to implement a Part 8 tool must work to the specification that is published. I can consider current work and opinion in that implementation to consider user/maintenance implications but must bear in mind the time, effort and costs of doing so.

Andy,

The question of defaultRdsId for metatemplate instances was discussed on one email thread in September 2013. I've provided the following reasons for my implementation:

Yes, no separate identification of the Description and RoleDescription instances. I've always thought about ID Spec in this way. RdsIDs are required for RD entities, only templates and roles are entities in this case.

We had one most important business case for RdsIDs - it should help to preserve identity of an entity through change of stewardship, namespace, probable through change of a label. But changes in names or URIs of meta-template instances doesn't affect template definitions.

For example, someone can keep template signatures in a table and generate P8 representations at request. At each request he can generate URIs and names of meta-template instances in a random way, it will not affect reconstruction of a signature itself.

Håvard,Keith, Manoj and Lillian were participating and there were no objections to my reasoning. If you have a different opinion - let's return to this problem.

I can support your request for additional typing of template classes. What I can do: I can reissue IIP template set and Geometry set with new typing added, I can publish small script to add type to any P8 compliant OWL definition file in my Editor environment, and I can include the default typing in the next release of the said Editor. Will start doing it this weekend.