Michel; So a question is why not assert that :Deur is a class?  It's
used that way in your model, so it would be proper to add the type
triple (e.g. :Deur rdf:type owl:Class), and there are no problems with
doing this. It's not a metamodeling issue, as you are not making
subclasses of owl:Class, etc.

In this case it appears Protégé interprets that anywhere something is
used in a type statement, infer that it is an instance of owl:Class.
Many would have disagreements with this kind of default inference, so
I don't think it would be a good idea as an enhancement request (as
background, TBC minimizes the number of behind-the-scenes inferences
to avoid these usability issues).  But you could add the inference
with the following query:
   CONSTRUCT {?type a owl:Class}
   WHERE
   { ?s rdf:type ?type .
     NOT EXISTS {?type rdf:type ?x .}
   }

This can be added by a SPARQLMotion script or inferring after running
it in the SPARQL View.  Since the triples are inferred, you can assert
triples around these inferences an it will all work as needed.  As
near as I can tell, this is what Protégé does - it just runs the above
query by default.

But the real answer, IMO, is to define :Deur as an owl:Class.  There
are no negative implications of doing this, and it's a more accurate
model.

-- Scott

On Feb 15, 4:14 pm, "Bohms, H.M. (Michel)" <[email protected]>
wrote:
> Well, to give you one example.
>
> If you open the bim.ttl its very hard to find the Deur_1 as instance of 
> ob:Door.
>
> You would expect to find it via:
> Select in class tree: mm:Object, goto its instances and select ob:Door then I 
> would expect to find Deur_1 as backlink (incoming reference) in its resource 
> form because the Deur_1 has ob:Door as rdf:type.
>
> (before I split mm, ob and bim I am sure this worked)
>
> To compare, now use Protégé 4.1beta and browse a bit in the class view. Here 
> you see all stuff collected now: metaclasses, classes and with direct access 
> to their meta-individuals/individuals including Door_1.
>
> I guess this is caused by some assumptions in your GUI which might not suit 
> meta-modelling capabilities best, I am not sure...
>
> Hope this explains a bit the kind of issues I encounter editting our stuuf in 
> tbc and why I sometimes move to code for convenience.
>
> Michel

-- 
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

Reply via email to