The problem with the snippet is that it is not L2 at all.
With L2 we objectify properties so that we can ad extra information about 
the property object instance.
For instance, "observed by Paul", "has low reliability".
Tying in with this is Jesse's observation about it being desirable to add 
information about units at the same instance level, not at the class level 
(following best practices used at the Kadaster, but also in OpenPHACTS).

The snippet below says that in all cases where ex:height is used, the unit 
is meter. (Not at the class level, but at the property instance level, 
which may sound confusing ---- just note that ex:height is an instance of 
owl:DatatypeProperty).

In the original example I think someone wrote { ex:height ex:isObservedBy 
"Paul" }. This then holds for all occurrences of ex:height, which is 
obviously not what is intended. 

Thus, the example is an L1 model. -j



On Thursday, November 21, 2019 at 10:23:51 AM UTC+1, Bohms, H.M. (Michel) 
wrote:
>
>  
>
> Thx Jan
>
>  
>
> Current NTA pattern for L2 has no punning. Your alternative (option 3) 
> also hasn’t. Only alternative option 2 does I guess.
>
>  
>
> Well it has:
>
>  
>
> ex:height a owl:DatatypeProperty ;
>
>   bsc:hasQuantityKind quantitykind:Length ;
>
>   bsc:hasUnit unit:M ;
>
>   rdfs:range xsd:decimal .
>
>  
>
> which I guess has at least similar effects like punning. (?).
>
>  
>
> Still quite some people like the option 2 (since it does need less own 
> language-level things as in option 1 and also no restriction-way of 
> modelling metadata as in option 3). Just collecting good arguments why 
> option 2 is no good idea as alternative for 1.
>
>  
>
> gr michel
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E [email protected] <javascript:>
>
> Location 
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>  
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you 
> are not the addressee or if this message was sent to you by mistake, you 
> are requested to inform the sender and delete the message. TNO accepts no 
> liability for the content of this e-mail, for the manner in which you use 
> it and for damage of any kind resulting from the risks inherent to the 
> electronic transmission of messages. 
>
>  
>
>  
>
>  
>
>  
>
> *Van:* [email protected] <javascript:> <
> [email protected] <javascript:>> *Namens *Jan Voskuil
> *Verzonden:* Thursday, November 21, 2019 9:51 AM
> *Aan:* TopBraid Suite Users <[email protected] <javascript:>>
> *Onderwerp:* Re: [topbraid-users] Re: combining owl and skos
>
>  
>
> The bottom line is that you should try this in TBC. Create the classes 
> CarModel,BMW320i and TeslaModelS. Assert that the latter two instantiate 
> the first. Create instances of the BMW and the Tesla. Define some 
> properties for CarModel.
>
>  
>
> TBC will not display the properties on the instance forms. This behaviour 
> is typical of introspective tools. 
>
>  
>
> Therefore, in my opinion at least, it would be a bad idea to promote 
> metaclasses and punning as a viable pattern in proposed standards like 
> NEN8035. Level 2 and 3 property modelling (objectified and doubly 
> objectified properties) do not at all require metaclasses, they can be 
> easily modelled within DL using standard patterns that everybody 
> understands, and that are supported by generic tools. Level 2 and 3 add 
> complexity as a trade-off against expressivity. 
>
>  
>
> There is no such thing as a free lunch. The clever ways people come up 
> with to obtain L2 expressivity without the complexity invariably involve 
> punning. If anything, however, punning introduces much more complexity than 
> most people are aware of. I guess this is why the punning discussion keeps 
> coming up, and why we need to continue arguing against it. Of course while 
> keeping in mind that patterns such as those David proposes do have value in 
> the specific cases they are designed for.
>
>  
>
>  
>
>  
>
>
> On Thursday, November 21, 2019 at 9:03:08 AM UTC+1, Bohms, H.M. (Michel) 
> wrote:
>
>  
>
> Hi Irene,
>
>  
>
> Wrt your “To be clear, I would not recommend this approach to data 
> modeling. I also have to admit that I find this discussion pretty 
> esoteric and largely irrelevant.”
>
>  
>
>  
>
> We find this pattern/need very often in practice (multi-level typing). 
> Catalogue products beings instances that are instantiated again for a 
> client, properties defined with meta-data, instantiated again for actual 
> properties of things, etc. etc. People use very different ways of dealing 
> with it using punning, rdf:Property as range, objectproperties iso rdf:type 
> having similar semantic intentions etc. etc. So I guess its important to 
> know for certain variants what is actually inferred or not etc. I was glad 
> the issue was brought up (again) by Jan. The start of the issue was 
> actually a question of some clients on how to best combine say RDFS/OWL and 
> SKOS since sometimes the thing modelled then could be both an instance and 
> a class and the w3c spec sayd his would lead to owl full which might have 
> been true for owl1 but not for owl2.
>
>  
>
> Greetings Michel
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E [email protected]
>
> Location 
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>  
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you 
> are not the addressee or if this message was sent to you by mistake, you 
> are requested to inform the sender and delete the message. TNO accepts no 
> liability for the content of this e-mail, for the manner in which you use 
> it and for damage of any kind resulting from the risks inherent to the 
> electronic transmission of messages. 
>
>  
>
>  
>
>  
>
>  
>
> *Van:* [email protected] <[email protected]> *Namens 
> *Irene 
> Polikoff
> *Verzonden:* Thursday, November 21, 2019 1:25 AM
> *Aan:* [email protected]
> *Onderwerp:* Re: [topbraid-users] Re: combining owl and skos
>
>  
>
> RDFS says:
>
>  
>
> rdf:type rdfs:range rdfs:Class.
>
>  
>
> Given
>
>  
>
> :x a :Eagle.
>
> :Eagle a :Species.
>
> :Species a owl:Class.
>
>  
>
> A tool that implements RDFS inferencing will conclude
>
>  
>
> :Eagle a rdfs:Class.
>
> :Species a rdfs:Class.
>
>  
>
> If you add OWL into the mix, you may get
>
>  
>
> :Species rdfs:subClassOf owl:Thing.
>
> :Eagle a owl:Thing.
>
> owl:Nothing rdfs:subClassOf :Eagle.
>
>  
>
> Possibly, :Eagle a owl:NamedIndividual. I believe it has the same class 
> extension as owl:Thing.
>
>  
>
> I can’t think of any other inferences entailed by the 3 triples above.
>
>  
>
> To be clear, I would not recommend this approach to data modeling. I also 
> have to admit that I find this discussion pretty esoteric and largely 
> irrelevant.
>
>  
>
> On Nov 20, 2019, at 8:23 AM, dprice <[email protected]> wrote:
>
>  
>
> Because of things like “owl:Thing rdf:type owl:Class”, owl:disjointWith 
> rdfs:domain/rdfs:range owl:Class, etc. I think it's owl:Class, but I’ve 
> never looked at a specific reasoner’s behaviour in detail. May even vary 
> from reasoner to reasoner.
>
>  
>
> Cheers,
>
> David
>
>  
>
> On 20 Nov 2019, at 12:35, Irene Polikoff <[email protected]> wrote:
>
>  
>
> I would think rdfs:Class, not owl:Class.
>
>  
>
>  
>
> On Nov 20, 2019, at 4:48 AM, dprice <[email protected]> wrote:
>
>  
>
> Everything that is the rdfs:range of rdf:type is by-definition an 
> owl:Class.
>
>  
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.com
>  
> <https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.com?utm_medium=email&utm_source=footer>
> .
>
>  
>
> UK +44 (0) 7788 561308
>
> US +1 (336) 283-0808
>
>  
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.com
>  
> <https://groups.google.com/d/msgid/topbraid-users/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.com?utm_medium=email&utm_source=footer>
> .
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%40topquadrant.com
>  
> <https://groups.google.com/d/msgid/topbraid-users/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%40topquadrant.com?utm_medium=email&utm_source=footer>
> .
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/topbraid-users/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/3b12867b-fa2d-43a8-9d20-b8a1b58c70a2%40googlegroups.com.

Reply via email to