- From: Simon Reinhardt <simon.reinhardt@koeln.de>
- Date: Thu, 10 Sep 2009 11:59:19 +0200
- To: Bernard Vatant <bernard.vatant@mondeca.com>
- CC: "[ontolog-forum]" <ontolog-forum@ontolog.cim3.net>, "semantic-web@w3.org" <semantic-web@w3.org>
Bernard Vatant wrote: > 3. Coming back to the initial issue, I conclude that there is no more, > no less semantics nor potential usability in declaring skos:Concept to > be in the range of dcterms:subject, than to declare foaf:Person to be a > subclass of foaf:Agent. "Dont acte" Not for reasoning but as a hint to the ontology user what classes they might want to use when modelling their data with this ontology. I always wonder if the following is an alternative to modelling this or if it will lead to a contradiction or something when no such value is found in the ABox you're reasoning over: ex:Something rdfs:subClassOf [ a owl:Restriction ; owl:onProperty dcterms:subject ; owl:someValuesFrom skos:Concept ] , [ a owl:Restriction ; owl:onProperty dcterms:subject ; owl:someValuesFrom foaf:Person ] . > For example when LoC publishes later this year > the authoritative ISO 639-2 list of languages as a SKOS Concept Scheme, > the range of dcterms:language could be restricted to the values in such > a list (using e.g., a restriction on the value of skos:inScheme). This > would avoid Dublin Core to go through the painful task of defining > formally the class dcterms:Linguistic System which is the current > specified range - with the same lack of definition as foaf:Agent. > Referring to some authority is certainly the best way to deal with the > issue here. We (DC) don't know what a language is, go ask ISO 639-2 > folks, apparently they know because they are able to provide a list. Bit off-topic but: while you might do that for interoperability you would exclude lots of codes from ISO 639-3 and loads of things that can be defined through language tags, e.g. regional variants such as en-GB. > Please consider this is not a bait to start a flame war on what is and > what is not a language or linguistic system - you can start it, but > count me out :)) Why, of course a language is a dialect with an army and navy. :-) > Thanks to Dr. Sowa for the good reminder on role vs type. This is > something I have often to explain to customers, and yes, appliance is a > good candidate for role type. I put this example out of my hat with no > deep thought about it, so thanks for the lesson :) So I guess natural types you can simply model as classes independent of any properties. But a role type is actually bound to a property which defines it. You could just model this as a property without defining a class in its range. What you get from defining a class is that all individuals appearing in such triples will be inferred to have this type and can therefore be related as having something in common. But then again they can also be related by being values of the property. It's only when you re-use widely used classes such as skos:Concept for the range of a property that you get some interoperability effects because programs might know about skos:Concept and thus can relate the individuals easily - but they might not know your property so they couldn't relate the individuals through that. Am I making any sense here? :-) Regards, Simon
Received on Thursday, 10 September 2009 10:00:02 UTC