Page 1 of 1

Templates for enties of Class Property

Posted: Wed Jan 23, 2013 12:24 pm
by KeithWillshaw
The iRING IIP work group has requested that we seek clarification of the correct method to implement the Template types for use with entties of type Property

We are familar with those that use SinglePropertyDimension but the Property Templates have caused some confusion

I have attached a document with my understanding of the situation and would welcome the groups comments and clarifications

Keith Willshaw

Re: Templates for enties of Class Property

Posted: Wed Jan 23, 2013 12:54 pm
by HansTeijgeler
Hi Keith,

Page 1 is OK.

On page 2 I found in the first table:

1 hasUrClass dm:ClassOfIndividual ID to be generated automatically

That remark "ID to be ..." is not in the template spec.

In the second table I found:

2 hasPossessorType dm:ClassOfIndividual uuid of Template Instance

That is incorrect. It shall be a random (UU)ID, that is required only to invalidate changed information about the UrClass.
See http://www.15926.org/publications/gener ... /index.htm where you can read:
The overruled classOfPart Classes are to be automatically invalidated with the DatatypeProperty valInvalidationTime. This can be done as follows:

Code: Select all

    <owl:Class rdf:about="#C2733c060-1c84-11e2-892e-0800200c9a66">
        <p7tpl:valInvalidationTime rdf:datatype="&xsd;dateTime">2011-06-15T14:38:00Z</p7tpl:valInvalidationTime>
    </owl:Class>
and also http://www.15926.org/publications/gener ... /index.htm, the first part.

Regards,
Hans

Re: Templates for enties of Class Property

Posted: Mon Jan 28, 2013 2:10 pm
by vvagr
Hans, Keith

What are we going to define with PropertyOfClassOfIndividual template?

If we are talking about "direct" measured property, it is rarely, if never, possessed by a class. As I was often told, we've to use PropertyRange for classes.

But if we are indeed talking about BOILING_TEMPERATURE, as Keith's example suggests - it is completely wrong template, as boiling temperature is an indirect property.

We know the source of problem - an incorrect typing in PCA RDL. But BOILING TEMPERATURE AT STANDARD CONDITIONS exists in the RDL as ClassOfIndirectProperty also, so we can safely use ClassOfIndirectPropertyWithReferencePropertySpace template. Probable with the same BOILING TEMPERATURE: 100 degC instance of PropertyRange, but it'll be less grave mistake in my opinion.

An one question to Hans - about both PropertyOfClassOfIndividual and ClassOfIndirectPropertyWithReferencePropertySpace:

If we've already declared a property instance to occupy template role - it is already classified by some ClassOfProperty, and additional role for this classifier in the signature is just a source of additional mistakes. Is it required?

Re: Templates for enties of Class Property

Posted: Mon Jan 28, 2013 3:15 pm
by HansTeijgeler
An one question to Hans - about both PropertyOfClassOfIndividual and ClassOfIndirectPropertyWithReferencePropertySpace:

If we've already declared a property instance to occupy template role - it is already classified by some ClassOfProperty, and additional role for this classifier in the signature is just a source of additional mistakes. Is it required?
Not really, I added those classifications to make retrieval easier, so not via the definition in the RDL. I am open for a change, if felt necessary.

Re: Templates for enties of Class Property

Posted: Mon Jan 28, 2013 3:25 pm
by vvagr
Templates are really for compactification. So I think it is really not a good practice.

From the business side I think all templates with dm:Property typed roles will be used rarely. If we are mapping to-from real business system, we usually can see values and scales in its database.

Therefore it will be much easier to use ClassOfIndirectPropertyWithBoundingValues and similar templates.

To fill properly dm:Property typed role you have to search through the RDL and if you can not find anything - construct an entity required.

Re: Templates for enties of Class Property

Posted: Tue Jan 29, 2013 11:47 am
by KeithWillshaw
HansTeijgeler wrote:Hi Keith,

Page 1 is OK.

On page 2 I found in the first table:

1 hasUrClass dm:ClassOfIndividual ID to be generated automatically

That remark "ID to be ..." is not in the template spec.

In the second table I found:

2 hasPossessorType dm:ClassOfIndividual uuid of Template Instance

That is incorrect. It shall be a random (UU)ID, that is required only to invalidate changed information about the UrClass.
See http://www.15926.org/publications/gener ... /index.htm where you can read:
The overruled classOfPart Classes are to be automatically invalidated with the DatatypeProperty valInvalidationTime. This can be done as follows:

Code: Select all

    <owl:Class rdf:about="#C2733c060-1c84-11e2-892e-0800200c9a66">
        <p7tpl:valInvalidationTime rdf:datatype="&xsd;dateTime">2011-06-15T14:38:00Z</p7tpl:valInvalidationTime>
    </owl:Class>
and also http://www.15926.org/publications/gener ... /index.htm, the first part.

Regards,
Hans

I find this very confusing

The role name is hasPossessorType, its entity type is dm:ClassOfIndividual yet you are
talking about random uuid's and datetime stamps !

Lets try and clarify things

1) What would the values in the template instance be if the data is valid
2) What would the values in the template instance be if the data is invalid
3) How do I tell the difference between a valid and invalid entry

Keith

Re: Templates for enties of Class Property

Posted: Tue Jan 29, 2013 2:44 pm
by HansTeijgeler
Hi Keith,

If I try to answer that, I will write almost the same as I already did in:
http://www.15926.org/publications/gener ... /index.htm and
http://www.15926.org/publications/gener ... /index.htm, in that order of reading.
I didn't refer to those publications casually, they contain the answer to your questions.
Please read those carefully and ask clarification if needed.

I add a copy of Matthew West's book on modelling, that explains the reason why we have the UrClass as collector of information about that UrClass. Please read chapter 15.2.3 and note the paragraph marked yellow.

Regards,
Hans

Re: Templates for enties of Class Property

Posted: Wed Jan 30, 2013 10:38 am
by KeithWillshaw
HansTeijgeler wrote:Hi Keith,

If I try to answer that, I will write almost the same as I already did in:
http://www.15926.org/publications/gener ... /index.htm and
http://www.15926.org/publications/gener ... /index.htm, in that order of reading.
I didn't refer to those publications casually, they contain the answer to your questions.
Please read those carefully and ask clarification if needed.

I add a copy of Matthew West's book on modelling, that explains the reason why we have the UrClass as collector of information about that UrClass. Please read chapter 15.2.3 and note the paragraph marked yellow.

Regards,
Hans
I have read these links - many times
They do not answer my questions which are breathtakingly simple - let me repeat them for you

1) What would the values in the template instance be if the data is valid
2) What would the values in the template instance be if the data is invalid
3) How do I tell the difference between a valid and invalid entry

We are being asked to adopt a different method to that we have spent time and money developing

Asking for simple examples of how it works seems eminently reasonable to me.

Keith

Re: Templates for enties of Class Property

Posted: Wed Jan 30, 2013 11:24 am
by vvagr
Keith,

First of all - proposed MMT system of templates for life-cycle data integration and its principles of applications are different from Part 7 sample system of proto- and initial set templates applied so far in iRING and TIPs project. Migration will require additional efforts.

Its adoption requires careful study of its ontological presuppositions, and we are still clarifying them with Hans.

Now I'll try to answer your questions, as well as I can.

Each class template in the discussed set has two roles: one named "hasUrClass", another named in a more or less traditional way: "hasPosessor", "hasIdentified", etc.

What is usually meant to be Class-in-focus - always occupies hasUrClass role. Classes to occupy traditionally-named roles are generated on the fly, each time new statement is made about UrClass. The meaning of each template statement can be described like:

"As far as we know now, UrClass has PropertyX, therefore we declare that Class1234 is subclass of UrClass and Class1234 has PropertyX."

It is this Class1234 that is deemed "valid" for now, and it will be invalidated as soon as we decide that UrClass has PropertyY instead of PropertyX. Class1234 itself will be invalidated by a special template instance about it (or by annotation property), not our initial template statement.

Examples can be downloaded from http://15926.org/publications/general-d ... /index.htm