View unanswered posts | View active topics It is currently Sun Jan 19, 2020 5:07 am

Reply to topic  [ 12 posts ]  Go to page 1, 2  Next
 Template role IDs 
Author Message

Joined: Sun Jan 22, 2012 9:14 pm
Posts: 189
dariuskanga wrote:
I have a question about the IDs that you are creating for base templates. What is the uniqueness for the role IDs? Does every role of every template get a unique ID?

I ask because at one time there was the idea that roles of specialized templates inherit the IDs of their parent template roles. I think this was probably not a good idea. Koos ran into problems because of it. As I remember it complicates queries because you can’t find the template from a role, but Koos can explain if necessary.

..question transferred from an email

Tue May 07, 2013 8:53 am

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
There are many aspects to this question, I'll try to outline some below.

1. Part 7 aspect.

From Part 7 point of view role names are almost irrelevant. Role meaning is given by template axiom, not by role name. Part 7 template model defines ordered role list, which in theory allows template instance representation without use of role identifiers at all (this possibility was ignored in favour of Semantic Web representation).

2. Part 8 aspect.

Part 8 (Semantic Web) representation of templates doesn't cover template axioms, it is impossible to deduce their meaning from it. Therefore it is reasonable to expect that role semantics will be somehow mapped to corresponding role predicates. SW best practice suggest usage of standard and meaningful predicates wherever possible.

It will be a good practice to use standard <namespace>/hasPosessor or <namespace>/hasClassOf Posessor predicate for all roles in all templates which describe property of some entity; standard <namespace>/hasClassifier predicate for role containing class of entity; <namespace>/hasObject for a role describing object-in-focus of some complex template statement; etc. (Here <namespace> stands for some standardised namespace which should be agreed separately.)

3. Specialised templates.

All considerations above are applicable to role names in different base templates. For specialised templates situation is similar, but for other reasons.

Part 7 again doesn't require unique role names. Templates as predicates with ordered role lists can receive correctly interpretation without role names.

Part 8 representation logically requires the same role predicates for specialised templates. Instance of specialised template should be an instance of a corresponding parent template, therefore predicates connecting it to role fillers should be the same. It doesn't follow from the formal meaning of OWL "inheritance" though!

As well as I can understand, OWL reasoner will not find any contradiction if roles of a specialised template are different from roles of a parent template. I know of one type of verification which is possible only if role names are the same:

In a ClassifiedIdentification template role hasIdentificationType is restricted by ClassOfIdentification.

If template IdentificationByTag is defined as specialization of ClassifiedIdentification and role hasIdentificationType is by some mistake restricted by Class "Tag String", then the reasoner will be able to find a mistake.

If role in a specialised template is renamed - mistake of this type will come unnoticed.

Possibility of such verification at OWL level has some value, of course. But this verification can be also done via template expansion, by FOL machinery, which doesn't use role names.

4. Summary

So in my opinion the best practice is:

- to give base templates semantically meaningful role names (and use standard predicate URIs) from some restricted set;

- to define specialised templates with the same role names (predicate URIs) which were used in parent templates.

But it is not a strict requirement, and not a reason to rework all IIP templates, for example.

And no implementer should rely on template role being unique for only one template or the same for specialized and parent template.

Mon May 13, 2013 4:02 pm
Profile WWW

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
Agreed. I've overlooked this. If child roles are declared as rdfs:subPropertyOf of parent roles - the type of verification I've described will be possible.

Two remarks though:

1. This is applicable only to the roles on which restriction is changed. If the role restriction is not changed - URI should remain the same.

2. And it is again only a recommended good practice, not a requirement.

(What follows is my understanding of particular OWL constructs used, please correct me if I'm wrong.)

It will be strictly required if Part 8 template model had used direct definition of domain and range of role predicates.

For example (pseudo-RDF for my example above):

hasIdentificationType hasDomain ClassifiedIdentification
hasIdentificationType hasRange  ClassOfIdentification

hasIdentificationByTag hasDomain IdentificationByTag

hasIdentificationByTag subPropertyOf hasIdentificationType

To use the same predicate hasIdentificationType here will be a mistake.

But Part 8 really uses another OWL constructs: owl:Restriction and owl:onProperty. As well as I can understand it's semantics, the meaning of P8 OWL definition is that a single predicate (hasIdentificationType in my example) takes values from ClassOfIdentification if subject is in ClassifiedIdentification and values from TAGGED OBJECT CODE ASSIGNMENT CLASS if subject is in IdentificationByTag.

Looks like examples at confirm my interpretation? Another indirect evidence is that OWL reasoners do not flare warnings when run on template definitions where specialized and parent templates have exactly the same role predicates.

Tue May 14, 2013 12:57 pm
Profile WWW

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283

Using your example of ClassifiedIdentification, and using ClassifiedIdentificationOfIndividual with the signature:
1 hasIdentified dm:PossibleIndividual
2 valIdentifier dm:ExpressString
3 hasIdentificationType dm:ClassOfClassOfIdentification

these role names normally remain the same when you specialize the template.

What happens in OWL is that when you specialize ClassifiedIdentificationOfIndividual to IdentificationOfIndividualWithTag, you state:
- IdentificationOfIndividualWithTag is a subClassOf ClassifiedIdentificationOfIndividual
- then: hasIdentificationType owl:hasValue &rdl;RDS2064461301 (why does the RDL use such a strange designation for "tag"?)

The other roles, that do not change, are not mentioned, they are inherited.
Note that the owl:allValuesFrom in the base template has changed to owl:hasValue. That is where the bucket stops, no further specialization of this role.
Introduction of zillions of other role names for a gazillion template specializations doesn't seem to me good practice.

Sun May 19, 2013 8:06 pm

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283

There is another reason for not changing the role names of the base templates: SPARQL.
In case a template instance has to be dereferenced, what will we do?
Find the template and ask for the rdf:object of a given role.
We may write a standard script for each base template class, and use base template role names.
Of course you might ask the script not only to look for that base template role name, but also for all its subproperties, which does not help much to improve performance.

The role number cannot be used for that, because:
- they are not stored
- who guarantees that the triples in the triple store will always stay in the proper order?

Resuming, my strong advice is to stick to the base template role names.

Tue May 21, 2013 4:49 pm

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia

There are two parts in Darius question - about unique roles for different base templates and only after that - about roles for specialised templates.

Looks like you have the same opinion I have - that specialised templates better should have the same roles as parent ones.

But what is your opinion on the first part?

Tue May 21, 2013 5:15 pm
Profile WWW

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283

We define all templates in OWL, and in fact we define there the domain and range of each role in the template.
Defining it again in RDF seems redundant.

Given the fact that Johan used Protégé for Part 8, and that software did not protest, it seems to me safe to say that the role names are local names, defined in the context of a template.

Tue May 21, 2013 5:24 pm

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia

it seems to me safe to say that the role names are local names, defined in the context of a template

No, you can not make such statement. Predicate with an URI is globally unique and it is the same predicate wherever it is used. Johan's set and your set both use global template role names unique in the context of a whole set. Like hasUrClass in your set - it is a one common role for a number of templates.

Concerning the domain and range - please see my comment at viewtopic.php?f=4&t=158&p=613#p595 (it is an answer to the comment which was apparently deleted). It seems that we can define domain and range for a single predicate (role) separately for each template which is using this role.

Tue May 21, 2013 6:28 pm
Profile WWW

Joined: Sun Jan 22, 2012 10:02 pm
Posts: 283
I have raised the question on

Tue May 21, 2013 7:33 pm

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia

We've promised P8WG to continue this discussion and arrive to some decision. Are there any new opinions. Who can summarise and make suggestions?

Thu Sep 26, 2013 8:30 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
eXTReMe Tracker
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.