Hi Scott,
Currently I have:
In mm:
:Object
rdf:type owl:Class .
And in ob:
:Deur
rdf:type mm:Object .
Following your advice could the latter become:
:Deur
rdf:type mm:Object ;
rdf:type owl:Class .
(I would prefer not to say 'de-meta' 'Object' since I define also in the mm
specific relationships between classes based on metaclasses like that)
Thx again for your advice, Michel
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Scott Henninger
> Sent: woensdag 16 februari 2011 0:37
> To: TopBraid Suite Users
> Subject: [topbraid-users] Re:
>
> 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
>
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
--
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
