From alanruttenberg at gmail.com Sat Feb 4 00:35:20 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Sat Feb 4 00:35:26 2006 Subject: [OWL] Managing patches when importing multiple ontologies Message-ID: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> For BioPAX I imagine that different providers of biological information supply ontologies and that someone who wants to work with multiple ones would owl:import each of them. The problem is, given the noisy nature of bioinformatics information, even if each of the ontologies is individually consistent, in combination there may be inconsistencies. I have recently experienced this first hand in some prototyping I am doing trying to use inverseFunctional properties to merge two databases of small molecules. The problem is that sometimes the source files I am working with have errors. These show up as inconsistencies (that's good). When I have control over the generation of the owl files, I can edit them to fix these inconsistencies. But when I get these from other sources, it is impractical to edit the source files because of the difficulty of then merging changes from a subsequent version of the ontology. In order to support repairing the inconsistency by removing some set of definitions, I want to propose a new ontology property (say owl:antiDefinitions) which points to a file with a set of definitions. The effect of this will be that any definitions in the target file will be removed from the complete ontology, if present. The granularity of an antiDefinition would be facts and axioms in the abstract syntax. Can something like this be made to work? -Alan From rector at cs.man.ac.uk Mon Feb 6 02:50:18 2006 From: rector at cs.man.ac.uk (Alan Rector) Date: Mon Feb 6 03:35:14 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> References: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> Message-ID: <78A42BC8-F395-4961-8E17-71EBF32FB243@cs.man.ac.uk> Alan (Ruttenberg) An interesting problem. My thoughts are that It really ought to be a feature of the import mechanism rather than a feature of the core language. There is a need to be able to over-ride/filter/transform information in an imported ontology in some way. I'm don't think I know enough or have enough experience to suggest a standard solution, but my instinct is to put some sort of a 'lens' between the imported ontology and the importing ontology. I am sure this will be a recurring problem. Alan (Rector) On 4 Feb 2006, at 05:35, Alan Ruttenberg wrote: > For BioPAX I imagine that different providers of biological > information supply ontologies and that someone who wants to work > with multiple ones would owl:import each of them. The problem is, > given the noisy nature of bioinformatics information, even if each > of the ontologies is individually consistent, in combination there > may be inconsistencies. I have recently experienced this first hand > in some prototyping I am doing trying to use inverseFunctional > properties to merge two databases of small molecules. The problem > is that sometimes the source files I am working with have errors. > These show up as inconsistencies (that's good). When I have control > over the generation of the owl files, I can edit them to fix these > inconsistencies. But when I get these from other sources, it is > impractical to edit the source files because of the difficulty of > then merging changes from a subsequent version of the ontology. > > In order to support repairing the inconsistency by removing some > set of definitions, I want to propose a new ontology property (say > owl:antiDefinitions) which points to a file with a set of > definitions. The effect of this will be that any definitions in the > target file will be removed from the complete ontology, if present. > The granularity of an antiDefinition would be facts and axioms in > the abstract syntax. > > Can something like this be made to work? > > -Alan > > _______________________________________________ > OWL mailing list > OWL@lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl ----------------------- Alan Rector Professor of Medical Informatics Department of Computer Science University of Manchester Manchester M13 9PL, UK TEL +44 (0) 161 275 6188/6149 FAX +44 (0) 161 275 6204 www.cs.man.ac.uk/mig www.clinical-esciences.org www.co-ode.org From ewallace at cme.nist.gov Mon Feb 6 11:49:27 2006 From: ewallace at cme.nist.gov (ewallace@cme.nist.gov) Date: Mon Feb 6 11:49:41 2006 Subject: [OWL] Managing patches when importing multiple ontologies Message-ID: <200602061649.LAA29322@clue.mel.nist.gov> Alan Rector wrote: >An interesting problem. My thoughts are that It really ought to be a >feature of the import mechanism rather than a feature of the core >language. There is a need to be able to over-ride/filter/transform >information in an imported ontology in some way. I'm don't think I >know enough or have enough experience to suggest a standard solution, >but my instinct is to put some sort of a 'lens' between the imported >ontology and the importing ontology. I agree with Alan Rector on this. We don't want to antiDefine or Retract, we just want to constrain the import to prevent including certain assertions in the documents that are being imported. Before someone says it: Yes, this would give novices lots of rope to hang themselves with and potentially further complicate managing ontology evolution. Such is life on the Semantic Web, as far as I can see. -Evan From alanruttenberg at gmail.com Mon Feb 6 12:32:58 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Mon Feb 6 12:32:52 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <200602061649.LAA29322@clue.mel.nist.gov> References: <200602061649.LAA29322@clue.mel.nist.gov> Message-ID: <33E0A893-C306-47EA-B7EF-ED7C150FD041@gmail.com> I agree with both of you. But I'm still feeling bruised by the last time I interacted with this list about imports. The message I got from that was that importing wasn't a mechanism (there could be no mention of order or time), it was simply a statement. So when I constructed this proposal I tried to avoid any mention of time. (though can't say I can understand what a restriction on owl:imports mincardinality 10 would mean in the open world). But truth be told I would rather that there was some explicit import "mechanism". Could we define one please? Frankly, I think that the existing spec is weak on this matter, at time avoiding discussing mechanism, and at other times implying it. This issue is a problem for me now, so I would appreciate some constructive suggestions on ways to move forward. Regards, -Alan On Feb 6, 2006, at 11:49 AM, ewallace@cme.nist.gov wrote: > > Alan Rector wrote: > >> An interesting problem. My thoughts are that It really ought to be a >> feature of the import mechanism rather than a feature of the core >> language. There is a need to be able to over-ride/filter/transform >> information in an imported ontology in some way. I'm don't think I >> know enough or have enough experience to suggest a standard solution, >> but my instinct is to put some sort of a 'lens' between the imported >> ontology and the importing ontology. > > I agree with Alan Rector on this. We don't want to antiDefine or > Retract, we just want to constrain the import to prevent including > certain assertions in the documents that are being imported. Before > someone says it: Yes, this would give novices lots of rope to hang > themselves with and potentially further complicate managing ontology > evolution. Such is life on the Semantic Web, as far as I can see. > > -Evan > > > From bparsia at isr.umd.edu Mon Feb 6 13:02:09 2006 From: bparsia at isr.umd.edu (Bijan Parsia) Date: Mon Feb 6 13:02:40 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <200602061649.LAA29322@clue.mel.nist.gov> References: <200602061649.LAA29322@clue.mel.nist.gov> Message-ID: <95cd11cce9c1ded83448557f14f61c74@isr.umd.edu> On Feb 6, 2006, at 11:49 AM, ewallace@cme.nist.gov wrote: > Alan Rector wrote: > >> An interesting problem. My thoughts are that It really ought to be a >> feature of the import mechanism rather than a feature of the core >> language. There is a need to be able to over-ride/filter/transform >> information in an imported ontology in some way. I'm don't think I >> know enough or have enough experience to suggest a standard solution, >> but my instinct is to put some sort of a 'lens' between the imported >> ontology and the importing ontology. > > I agree with Alan Rector on this. We don't want to antiDefine or > Retract, we just want to constrain the import to prevent including > certain assertions in the documents that are being imported. Before > someone says it: Yes, this would give novices lots of rope to hang > themselves with and potentially further complicate managing ontology > evolution. Such is life on the Semantic Web, as far as I can see. We already have the pieces in place, actually, in Swoop. We have change sets (based on OWL API change objects, but serialized in an RDF/XML format). We publish these sets into annotea stores so you can apply them to a version of the ontology. Aditya did some work to make a change set based versioning tool (see the current swoop). We've played around with using custom xpointer schemes to indicate "virtual" versions, but really all you need is a change set with a pointer to a version (or a separate document that listed the base ontologies and the patches to be applied). It's *really* scary to add non-logical things in ways that look lke logical things. So I'm against a property approach. (In Aditya's little tool it will check whether changes are still applicable. My point is that it would not be difficult at all to have a workable solution built on this infrastructure. The only reason we've not done it is time.) Cheers, Bijan. From pfps at research.bell-labs.com Mon Feb 6 16:23:12 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Mon Feb 6 16:23:28 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> References: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> Message-ID: <20060206.162312.127975558.pfps@research.bell-labs.com> From: Alan Ruttenberg Subject: [OWL] Managing patches when importing multiple ontologies Date: Sat, 4 Feb 2006 00:35:20 -0500 > For BioPAX I imagine that different providers of biological > information supply ontologies and that someone who wants to work with > multiple ones would owl:import each of them. The problem is, given > the noisy nature of bioinformatics information, even if each of the > ontologies is individually consistent, in combination there may be > inconsistencies. I have recently experienced this first hand in some > prototyping I am doing trying to use inverseFunctional properties to > merge two databases of small molecules. The problem is that sometimes > the source files I am working with have errors. These show up as > inconsistencies (that's good). When I have control over the > generation of the owl files, I can edit them to fix these > inconsistencies. But when I get these from other sources, it is > impractical to edit the source files because of the difficulty of > then merging changes from a subsequent version of the ontology. > > In order to support repairing the inconsistency by removing some set > of definitions, I want to propose a new ontology property (say > owl:antiDefinitions) which points to a file with a set of > definitions. The effect of this will be that any definitions in the > target file will be removed from the complete ontology, if present. > The granularity of an antiDefinition would be facts and axioms in the > abstract syntax. > > Can something like this be made to work? > > -Alan What you are suggesting is best done outside the level of the core KR language. Why not just have an intermediary system that handles this? peter From alanruttenberg at gmail.com Mon Feb 6 21:30:28 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Mon Feb 6 21:30:16 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <95cd11cce9c1ded83448557f14f61c74@isr.umd.edu> References: <200602061649.LAA29322@clue.mel.nist.gov> <95cd11cce9c1ded83448557f14f61c74@isr.umd.edu> Message-ID: <14D04202-DA0A-455D-B706-00D3D97A6E92@gmail.com> Thanks Bijan. I will look into this as soon as I have a chance. Any suggested reading or other tips before I head over to read the code would be appreciated. -Alan On Feb 6, 2006, at 1:02 PM, Bijan Parsia wrote: > We already have the pieces in place, actually, in Swoop. > > We have change sets (based on OWL API change objects, but > serialized in an RDF/XML format). We publish these sets into > annotea stores so you can apply them to a version of the ontology. > Aditya did some work to make a change set based versioning tool > (see the current swoop). We've played around with using custom > xpointer schemes to indicate "virtual" versions, but really all you > need is a change set with a pointer to a version (or a separate > document that listed the base ontologies and the patches to be > applied). > > It's *really* scary to add non-logical things in ways that look lke > logical things. So I'm against a property approach. > > (In Aditya's little tool it will check whether changes are still > applicable. My point is that it would not be difficult at all to > have a workable solution built on this infrastructure. The only > reason we've not done it is time.) > > Cheers, > Bijan. > From bernardo at mindswap.org Tue Feb 7 13:42:02 2006 From: bernardo at mindswap.org (Bernardo Cuenca Grau) Date: Tue Feb 7 13:42:03 2006 Subject: [OWL] [ALL] New OWL 1.1 Document Message-ID: Hi all, I have put together a document entitled: ``Tractable Fragments of the OWL 1.1 Web Ontology Language'' The idea of the document is to identify and present many of the logics that: 1) Can be regarded as fragments of OWL 1.1 2) Can handle at least some interesting inference service in polynomial time with respect to either the number of facts in the ontology or the size of the ontology as a whole The document provides an abstract syntax for each of the logics and explains their computational properties. The goal is to provide a useful guideline for developers and users. The link to de document is the following: http://owl-workshop.man.ac.uk/Tractable.html Comments are welcome and discussion is encouraged. Cheers Bernardo From alanruttenberg at gmail.com Tue Feb 7 18:59:43 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Tue Feb 7 19:00:03 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <20060206.162312.127975558.pfps@research.bell-labs.com> References: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> <20060206.162312.127975558.pfps@research.bell-labs.com> Message-ID: <24FB5B37-0221-45F6-B97A-5FDA4BE98929@gmail.com> On Feb 6, 2006, at 4:23 PM, Peter F. Patel-Schneider wrote: > What you are suggesting is best done outside the level of the core KR > language. Why not just have an intermediary system that handles > this? My general instinct is to try to handle those cases which will come up in the normal, practical use of the technology. In the cases I've raised, I'm suggesting that everyone using the language will bump up against these issues. If they are not dealt with in the spec, one of two things will happen. 1) Some particular tool will handle one or another of them that are essential for applications, locking you into using the tool even though the rest of it isn't appropriate. For example, Protege doesn't currently scale well to large ontologies, but does handle imports rather well. 2) People will waste effort writing redundant compatibility layers so that these common tasks can appear to operate the same in a variety of tools such as reasoners so that they can preserve their ability to use the tool they need. It's my sense that the kind of thing I am suggesting is relatively easy and could contribute to wider adoption of the language, something I want to see happen. -Alan From pfps at research.bell-labs.com Tue Feb 7 19:12:44 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Tue Feb 7 19:12:50 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <24FB5B37-0221-45F6-B97A-5FDA4BE98929@gmail.com> References: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> <20060206.162312.127975558.pfps@research.bell-labs.com> <24FB5B37-0221-45F6-B97A-5FDA4BE98929@gmail.com> Message-ID: <20060207.191244.44231465.pfps@research.bell-labs.com> From: Alan Ruttenberg Subject: Re: [OWL] Managing patches when importing multiple ontologies Date: Tue, 7 Feb 2006 18:59:43 -0500 > > On Feb 6, 2006, at 4:23 PM, Peter F. Patel-Schneider wrote: > > > What you are suggesting is best done outside the level of the core KR > > language. Why not just have an intermediary system that handles > > this? > > My general instinct is to try to handle those cases which will come > up in the normal, practical use of the technology. In the cases I've > raised, I'm suggesting that everyone using the language will bump up > against these issues. If they are not dealt with in the spec, one of > two things will happen. > > 1) Some particular tool will handle one or another of them that are > essential for applications, locking you into using the tool even > though the rest of it isn't appropriate. For example, Protege doesn't > currently scale well to large ontologies, but does handle imports > rather well. > > 2) People will waste effort writing redundant compatibility layers so > that these common tasks can appear to operate the same in a variety > of tools such as reasoners so that they can preserve their ability to > use the tool they need. > > It's my sense that the kind of thing I am suggesting is relatively > easy and could contribute to wider adoption of the language, > something I want to see happen. > > -Alan Well, I disagree that the thing that you are suggesting is relatively easy to do correctly in its full generality in the language. There are a number of issues to be dealt with, including how to identify the pieces of a document that are to be excluded and whether the exclusion directives are part of the logic itself. Yes I agree that what you are suggesting is important, just as imports itself is important. However, I strongly feel that it is important to do this "right", or at least "right enough", and I am very uncomfortable about just what is "right enough" here, at least if the feature is to be part of the language itself. Peter F. Patel-Schneider Bell Labs Research From alanruttenberg at gmail.com Tue Feb 7 22:05:56 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Tue Feb 7 22:06:00 2006 Subject: [OWL] Managing patches when importing multiple ontologies In-Reply-To: <20060207.191244.44231465.pfps@research.bell-labs.com> References: <14E8FE0A-2CE3-4EF0-8B2B-0B33E2A3F33A@gmail.com> <20060206.162312.127975558.pfps@research.bell-labs.com> <24FB5B37-0221-45F6-B97A-5FDA4BE98929@gmail.com> <20060207.191244.44231465.pfps@research.bell-labs.com> Message-ID: I am generally sympathetic to the point of view that it's important to sweat the details. But there are two things, at least, worth mentioning. It's hard for me, and probably some others, to understand what the "full generality of the language is". So for something like imports, it's particularly difficult to discern what exactly was intended by the construct, what can possibly go wrong, etc. Where I keep coming up short is when one goes past description logics to OWL Full. The best I can make out is that there is an attempt to align with RDF semantics, something that is achieved with great pain, but to uncertain benefit. So though I've tried, i find it hard to figure out exactly what the "rules of the game are" for anything that falls outside the DL realm, at least in this forum. I also think that there are places where perfection is good, and other places where it can impede a process. In this setting, I think that perfection works well in delineating, very carefully, what can and can not be tractably computed with, and exactly what those computations do. I don't think it is as harmful to make mistakes in other areas, such as import management. There are future versions, and mistakes can and will be fixed. I think that one of the areas on the border is imports. From previous messages you've suggested that imports is a logical statement, rather than an processing step. I'm not convinced that is a good choice. If I understand Bijan's comment: > "It's *really* scary to add non-logical things in ways that look lke > logical things. So I'm against a property approach", it would seem that imports is just such a place. I think it would be better, for the moment, to make a split between things like imports vs logical statements. We could spell out that there are two phases to processing an OWL-DL document: 1) Gathering the definitions 2) Evaluating and doing logic on the definitions - satisfiability, query, subsumption etc. Imports and patch management would work at the first stage, and is outside the realm of logic. All remnants of directives associated with this process are removed and are not present in the definitions which are manipulated in stage 2. As I mentioned in the earlier message, change management would operate at the level of statements in the abstract syntax. That might be an issue if a set of source documents could be (lexically) parsed into more than one set of abstract syntax statements. If that's the case, that's an issue that might cause some problem. My assessment of whether this would be right enough would be based on some assessment of actual damage that this could have on the future progression of the language. On the face of it what I see is Pros already stated. Cons: - Some work to define the two phases - probably define in terms of existing standards. - Loss of ability to reason about imports. a) for now b) probably a pro c) but I may be missing some really important use case for reasoning about imports. - Some possibility that the mechanism will have to be changed later (but at least the logical core is not disrupted) Of course, I could be wrong. Regards, -Alan On Feb 7, 2006, at 7:12 PM, Peter F. Patel-Schneider wrote: > Well, I disagree that the thing that you are suggesting is relatively > easy to > do correctly in its full generality in the language. There are a > number of > issues to be dealt with, including how to identify the pieces of a > document > that are to be excluded and whether the exclusion directives are part > of the > logic itself. > > Yes I agree that what you are suggesting is important, just as imports > itself > is important. However, I strongly feel that it is important to do this > "right", or at least "right enough", and I am very uncomfortable about > just > what is "right enough" here, at least if the feature is to be part of > the > language itself. > > Peter F. Patel-Schneider > Bell Labs Research -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4013 bytes Desc: not available Url : http://lists.mindswap.org/pipermail/owl/attachments/20060207/2b7ce381/attachment.bin From rector at cs.man.ac.uk Fri Feb 10 13:15:29 2006 From: rector at cs.man.ac.uk (Alan Rector) Date: Fri Feb 10 13:12:05 2006 Subject: [OWL] Named Graphs and Annotations in OWL Message-ID: <77F1BEF9-FE52-4E43-85AE-47DFFA14998F@cs.man.ac.uk> Jeremy I don't know if you have been following the OWL 1.1 discussions. Much of the issue is about fine grained annotations, which I raised because in modularising ontologies we need to know not only where each class and property come from, but also where each axiom/triple comes from. For example I may define Diabetes in a disease ontology, Insulin in a physiology ontology, and the link between them in a third ontology. I need to know where that link is to maintain it. I might also add superclass axioms. etc. There are other things that I might need to say about individual triples, but these are less critical. RDF reification doesn't do this, as you have pointed out in arguing for named graphs. A question about named graphs was raised early in the thread, and I asked if they were standard. Some folk seem to have thought that was meant as a brush off. It was simply a genuine question. So to the source... What is the status of named graphs? Do they even seem a potential answer to this problem? How will you cope with them, or will you, with respect to the various triple stores? particularly Oracle's new triple store? Is there any consensus growing around them in the RDF community or are they a JENA/HP only extension? Regards Alan ----------------------- Alan Rector Professor of Medical Informatics Department of Computer Science University of Manchester Manchester M13 9PL, UK TEL +44 (0) 161 275 6188/6149 FAX +44 (0) 161 275 6204 www.cs.man.ac.uk/mig www.clinical-esciences.org www.co-ode.org From gstoil at image.ece.ntua.gr Mon Feb 13 07:07:12 2006 From: gstoil at image.ece.ntua.gr (George Stoilos) Date: Mon Feb 13 07:07:17 2006 Subject: [OWL] [ALL] New OWL 1.1 Document In-Reply-To: Message-ID: <000701c63096$062455b0$760b6693@image.ece.ntua.gr> Dear Bernardo, I have some comments regarding the Tractable Fragments document. In section 3 (DL-Lite) you have functionals and inverse-functionals both as allowed contructs as well as as intractable constructs. In Subsection 3.2.4 you allow DL-Lite properties to be symmetric; I believe that DL-Lite does not have symmetric properties, does it? In Section 4 (DLP); DLP does not have functional and inverse-functional properties Cheers, G. Stoilos > -----Original Message----- > From: owl-bounces@lists.mindswap.org > [mailto:owl-bounces@lists.mindswap.org]On Behalf Of Bernardo > Cuenca Grau > Sent: Tuesday, February 07, 2006 8:42 PM > To: OWL@lists.mindswap.org > Subject: [OWL] [ALL] New OWL 1.1 Document > > > > Hi all, > > I have put together a document entitled: ``Tractable > Fragments of the OWL > 1.1 Web Ontology Language'' > > The idea of the document is to identify and present many of the > logics that: > 1) Can be regarded as fragments of OWL 1.1 > 2) Can handle at least some interesting inference service in > polynomial > time with respect to either the number of facts in the ontology or the > size of the ontology as a whole > > The document provides an abstract syntax for each of the logics and > explains their computational properties. The goal is to > provide a useful > guideline for developers and users. > > The link to de document is the following: > > http://owl-workshop.man.ac.uk/Tractable.html > > Comments are welcome and discussion is encouraged. > > Cheers > > Bernardo > _______________________________________________ > OWL mailing list > OWL@lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl > From jjc at hpl.hp.com Mon Feb 13 04:17:56 2006 From: jjc at hpl.hp.com (Jeremy Carroll) Date: Mon Feb 13 07:44:28 2006 Subject: [OWL] Re: Named Graphs and Annotations in OWL In-Reply-To: <77F1BEF9-FE52-4E43-85AE-47DFFA14998F@cs.man.ac.uk> References: <77F1BEF9-FE52-4E43-85AE-47DFFA14998F@cs.man.ac.uk> Message-ID: <43F04EC4.4080303@hpl.hp.com> Named graphs appear in SPARQL ... I believe Nokia use named graphs but I don't know the details. Patrick Stickler may be able to help. Named graphs are not intended as proprietary, but would need some effort at the standards level. So an OWL 1.1 that depended on them, would be looking for an RDF 1.1 that included them. This would make sense since SPARQL uses them Jeremy Alan Rector wrote: > Jeremy > > I don't know if you have been following the OWL 1.1 discussions. Much > of the issue is about fine grained annotations, which I raised because > in modularising ontologies we need to know not only where each class and > property come from, but also where each axiom/triple comes from. For > example I may define Diabetes in a disease ontology, Insulin in a > physiology ontology, and the link between them in a third ontology. I > need to know where that link is to maintain it. I might also add > superclass axioms. etc. > > There are other things that I might need to say about individual > triples, but these are less critical. RDF reification doesn't do this, > as you have pointed out in arguing for named graphs. > > A question about named graphs was raised early in the thread, and I > asked if they were standard. Some folk seem to have thought that was > meant as a brush off. It was simply a genuine question. So to the > source... > > What is the status of named graphs? Do they even seem a potential > answer to this problem? How will you cope with them, or will you, with > respect to the various triple stores? particularly Oracle's new triple > store? Is there any consensus growing around them in the RDF community > or are they a JENA/HP only extension? > > > Regards > > Alan > > > ----------------------- > Alan Rector > Professor of Medical Informatics > Department of Computer Science > University of Manchester > Manchester M13 9PL, UK > TEL +44 (0) 161 275 6188/6149 > FAX +44 (0) 161 275 6204 > www.cs.man.ac.uk/mig > www.clinical-esciences.org > www.co-ode.org > From pfps at research.bell-labs.com Mon Feb 13 08:47:59 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Mon Feb 13 08:50:09 2006 Subject: [OWL] Re: Named Graphs and Annotations in OWL In-Reply-To: <43F04EC4.4080303@hpl.hp.com> References: <77F1BEF9-FE52-4E43-85AE-47DFFA14998F@cs.man.ac.uk> <43F04EC4.4080303@hpl.hp.com> Message-ID: <20060213.084759.132688554.pfps@research.bell-labs.com> From: Jeremy Carroll Subject: [OWL] Re: Named Graphs and Annotations in OWL Date: Mon, 13 Feb 2006 09:17:56 +0000 > Named graphs appear in SPARQL ... Hmm. Do named graphs really appear in SPARQL? As far as I can tell SPARQL has some sort of way of tagging certain graphs, but I don't think that this reaches the level of named graphs. [...] > Jeremy [...] peter From jjc at hpl.hp.com Mon Feb 13 11:49:02 2006 From: jjc at hpl.hp.com (Jeremy Carroll) Date: Mon Feb 13 11:49:18 2006 Subject: [OWL] Re: Named Graphs and Annotations in OWL In-Reply-To: <20060213.084759.132688554.pfps@research.bell-labs.com> References: <77F1BEF9-FE52-4E43-85AE-47DFFA14998F@cs.man.ac.uk> <43F04EC4.4080303@hpl.hp.com> <20060213.084759.132688554.pfps@research.bell-labs.com> Message-ID: <43F0B87E.8060706@hpl.hp.com> Peter F. Patel-Schneider wrote: > From: Jeremy Carroll > Subject: [OWL] Re: Named Graphs and Annotations in OWL > Date: Mon, 13 Feb 2006 09:17:56 +0000 > >> Named graphs appear in SPARQL ... > > Hmm. Do named graphs really appear in SPARQL? As far as I can tell SPARQL has > some sort of way of tagging certain graphs, but I don't think that this reaches > the level of named graphs. I would certainly agree that the semantics of named graphs in sparql is not what we were suggesting. The lack of semantics in SPARQL though is not incompatible with any proposed semantics... (although I'm sure you could find one that was!) Jeremy From bernardo at mindswap.org Tue Feb 14 13:11:00 2006 From: bernardo at mindswap.org (Bernardo Cuenca Grau) Date: Tue Feb 14 13:11:03 2006 Subject: [OWL] [ALL] New OWL 1.1 Document In-Reply-To: <000301c63095$9e838e80$760b6693@image.ece.ntua.gr> References: <000301c63095$9e838e80$760b6693@image.ece.ntua.gr> Message-ID: Hi, Thanks for the comments! > > In section 3 (DL-Lite) you have functionals and inverse-functionals both as > allowed contructs as well as as intractable constructs. Yeah, stupid mistake. > In Subsection 3.2.4 you allow DL-Lite properties to be symmetric; I believe > that DL-Lite does not have symmetric properties, does it? Yes, you are right; DL-Lite does provide inverses, but in order to be able to express inverses, you also need role hierarchies, which are definitely not provided. > > In Section 4 (DLP); DLP does not have functional and inverse-functional > properties This depends, I guess, on the flavor of Datalog we consider. If you take datalog with equality, then it does. Probably this is worth mentioning. Thanks, Bernardo > > Cheers, > G. Stoilos > > > > > -----Original Message----- > > From: owl-bounces@lists.mindswap.org > > [mailto:owl-bounces@lists.mindswap.org]On Behalf Of Bernardo > > Cuenca Grau > > Sent: Tuesday, February 07, 2006 8:42 PM > > To: OWL@lists.mindswap.org > > Subject: [OWL] [ALL] New OWL 1.1 Document > > > > > > > > Hi all, > > > > I have put together a document entitled: ``Tractable > > Fragments of the OWL > > 1.1 Web Ontology Language'' > > > > The idea of the document is to identify and present many of the > > logics that: > > 1) Can be regarded as fragments of OWL 1.1 > > 2) Can handle at least some interesting inference service in > > polynomial > > time with respect to either the number of facts in the ontology or the > > size of the ontology as a whole > > > > The document provides an abstract syntax for each of the logics and > > explains their computational properties. The goal is to > > provide a useful > > guideline for developers and users. > > > > The link to de document is the following: > > > > http://owl-workshop.man.ac.uk/Tractable.html > > > > Comments are welcome and discussion is encouraged. > > > > Cheers > > > > Bernardo > > _______________________________________________ > > OWL mailing list > > OWL@lists.mindswap.org > > http://lists.mindswap.org/mailman/listinfo/owl > > > > From bernardo at mindswap.org Tue Feb 14 13:47:45 2006 From: bernardo at mindswap.org (Bernardo Cuenca Grau) Date: Tue Feb 14 13:47:46 2006 Subject: [OWL] [ALL] New Version of Tractable Fragments document In-Reply-To: References: <000301c63095$9e838e80$760b6693@image.ece.ntua.gr> Message-ID: Hi all, As a response to some comments, I have generated a new version of the Tractable Fragments document: http://owl-workshop.man.ac.uk/Tractable.html The document includes some minor changes and corrections with respect to the previous version. The only major addition is in Section 7, in which I have added also informaton about ``query complexity'' for conjunctive query answering (i.e. how the complexity of conj. query answering varies if the size of the query is increased). Hope you will find the new version interesting. Cheers Bernardo From gstoil at image.ece.ntua.gr Wed Feb 15 03:47:19 2006 From: gstoil at image.ece.ntua.gr (George Stoilos) Date: Wed Feb 15 03:47:30 2006 Subject: [OWL] [ALL] New OWL 1.1 Document In-Reply-To: Message-ID: <003901c6320c$6e4e9d40$760b6693@image.ece.ntua.gr> > -----Original Message----- > From: owl-bounces@lists.mindswap.org > [mailto:owl-bounces@lists.mindswap.org]On Behalf Of Bernardo > Cuenca Grau > Sent: Tuesday, February 14, 2006 8:11 PM > To: George Stoilos > Cc: OWL@lists.mindswap.org > Subject: RE: [OWL] [ALL] New OWL 1.1 Document > > > > Hi, Thanks for the comments! > > > > In section 3 (DL-Lite) you have functionals and > inverse-functionals both as > > allowed contructs as well as as intractable constructs. > > Yeah, stupid mistake. > > > In Subsection 3.2.4 you allow DL-Lite properties to be > symmetric; I believe > > that DL-Lite does not have symmetric properties, does it? > > Yes, you are right; DL-Lite does provide inverses, but in order to be > able to express inverses, you also need role hierarchies, which are > definitely not provided. > > > > > > In Section 4 (DLP); DLP does not have functional and > inverse-functional > > properties > > This depends, I guess, on the flavor of Datalog we consider. > If you take > datalog with equality, then it does. Probably this is worth > mentioning. Well, yes it depends. But then you might also want to consider Disjunctive Datalog with negation and equality and cover SHIQ- (SHIQ minus) but this is not what one would expect from a DLP fragment. Maybe equality is harmless compared to disjunction and negation, I don't know. But what about considering inequality, then you can also support at-least qualified number restrictions, is inequality harmless too? Cheers, G. Stoilos > > Thanks, > > Bernardo > > > > > > Cheers, > > G. Stoilos > > > > > > > > > -----Original Message----- > > > From: owl-bounces@lists.mindswap.org > > > [mailto:owl-bounces@lists.mindswap.org]On Behalf Of Bernardo > > > Cuenca Grau > > > Sent: Tuesday, February 07, 2006 8:42 PM > > > To: OWL@lists.mindswap.org > > > Subject: [OWL] [ALL] New OWL 1.1 Document > > > > > > > > > > > > Hi all, > > > > > > I have put together a document entitled: ``Tractable > > > Fragments of the OWL > > > 1.1 Web Ontology Language'' > > > > > > The idea of the document is to identify and present many of the > > > logics that: > > > 1) Can be regarded as fragments of OWL 1.1 > > > 2) Can handle at least some interesting inference service in > > > polynomial > > > time with respect to either the number of facts in the > ontology or the > > > size of the ontology as a whole > > > > > > The document provides an abstract syntax for each of the > logics and > > > explains their computational properties. The goal is to > > > provide a useful > > > guideline for developers and users. > > > > > > The link to de document is the following: > > > > > > http://owl-workshop.man.ac.uk/Tractable.html > > > > > > Comments are welcome and discussion is encouraged. > > > > > > Cheers > > > > > > Bernardo > > > _______________________________________________ > > > OWL mailing list > > > OWL@lists.mindswap.org > > > http://lists.mindswap.org/mailman/listinfo/owl > > > > > > > > _______________________________________________ > OWL mailing list > OWL@lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl > From Ulrike.Sattler at manchester.ac.uk Wed Feb 15 07:21:19 2006 From: Ulrike.Sattler at manchester.ac.uk (Ulrike Sattler) Date: Wed Feb 15 07:21:24 2006 Subject: [OWL] [ALL] New OWL 1.1 Document In-Reply-To: <003901c6320c$6e4e9d40$760b6693@image.ece.ntua.gr> References: <003901c6320c$6e4e9d40$760b6693@image.ece.ntua.gr> Message-ID: On 15 Feb 2006, at 09:47, George Stoilos wrote: [snipp] > > Well, yes it depends. But then you might also want to consider > Disjunctive > Datalog with negation and equality and cover SHIQ- (SHIQ minus) "and cover" is a bit misleading here: the reduction* from SHIQ** to disjunctive datalog involves an *exponential* blow-up in the size of the input, and thus this is all of a completely different flavour. Cheers, Uli (*) I prefer "reduction" to translation since translation seems to imply "polynomial" (**) it now also works for SHIQ -- the SHIQminus was only the first result > but this is > not what one would expect from a DLP fragment. Maybe equality is > harmless > compared to disjunction and negation, I don't know. But what about > considering inequality, then you can also support at-least > qualified number > restrictions, is inequality harmless too? > I am afraid that inequality isn't harmless: We prove that query containment is undecidable in the case where we allow inequalities in the right-hand side query, ... is a quote from @unpublished{TOCL-2006, title = "Conjunctive Query Containment and Answering under Description Logics Constraints", year = "2005", author = "Diego Calvanese and De Giacomo, Giuseppe and Maurizio Lenzerini", note = "Submitted to an international journal", } yet we would need to check the whole context. Cheers, Uli > Cheers, > G. Stoilos [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindswap.org/pipermail/owl/attachments/20060215/ff0b868b/attachment.html From gstoil at image.ece.ntua.gr Wed Feb 15 09:19:18 2006 From: gstoil at image.ece.ntua.gr (George Stoilos) Date: Wed Feb 15 09:19:22 2006 Subject: [OWL] [ALL] New OWL 1.1 Document In-Reply-To: Message-ID: <004701c6323a$cf82b6e0$760b6693@image.ece.ntua.gr> -----Original Message----- From: owl-bounces@lists.mindswap.org [mailto:owl-bounces@lists.mindswap.org]On Behalf Of Ulrike Sattler Sent: Wednesday, February 15, 2006 2:21 PM To: OWL@lists.mindswap.org Subject: Re: [OWL] [ALL] New OWL 1.1 Document On 15 Feb 2006, at 09:47, George Stoilos wrote: [snipp] Well, yes it depends. But then you might also want to consider Disjunctive Datalog with negation and equality and cover SHIQ- (SHIQ minus) "and cover" is a bit misleading here: the reduction* from SHIQ** to disjunctive datalog involves an *exponential* blow-up in the size of the input, and thus this is all of a completely different flavour. Cheers, Uli (*) I prefer "reduction" to translation since translation seems to imply "polynomial" (**) it now also works for SHIQ -- the SHIQminus was only the first result [George Stoilos] Sorry let me clarify my point. I wasn't proposing SHIQ, here. I just wanted to say that in my view DLP is something "constant" and does not depend on the version of Datalog you use. If you want to consider an extension of the DLP(as defined in the paper) then you should probably mention it in the text. But then there is a question risen. Is DLP+Functionals tractable, and if yes are there other extensions that are also tractable? but this is not what one would expect from a DLP fragment. Maybe equality is harmless compared to disjunction and negation, I don't know. But what about considering inequality, then you can also support at-least qualified number restrictions, is inequality harmless too? I am afraid that inequality isn't harmless: We prove that query containment is undecidable in the case where we allow inequalities in the right-hand side query, ... is a quote from @unpublished{TOCL-2006, title = "Conjunctive Query Containment and Answering under Description Logics Constraints", year = "2005", author = "Diego Calvanese and De Giacomo, Giuseppe and Maurizio Lenzerini", note = "Submitted to an international journal", } yet we would need to check the whole context. [George Stoilos] I don't quite undestand your point here... Do you suggest that DLP + Functionals + axioms of the form (>=nR)<=C and/or C<=(>=nR) is undecidable? To my view the second axiom is completely harmless, but it is out of the definition of a DLP, while the first one could be harmless under some restrictions. Cheers G. Stoilos Cheers, Uli Cheers, G. Stoilos [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindswap.org/pipermail/owl/attachments/20060215/53a1dd5b/attachment-0001.html From renato.bulcao at gmail.com Mon Feb 20 08:00:39 2006 From: renato.bulcao at gmail.com (=?ISO-8859-1?Q?Renato_Bulc=E3o?=) Date: Mon Feb 20 08:00:42 2006 Subject: [OWL] OWL and computational complexity Message-ID: <59eabcd60602200500td2b1f1an3aa77af860467cef@mail.gmail.com> Hi all. I've read such interesting Bernardo's draft entitled "Tractable Fragments of the OWL 1.1 Web Ontology Language". My PhD work is the investigation of using SW ontologies in the context of ubiquitous computing. My supervisor and I have concerned about the computational complexity using OWL 1.0 ontologies in the making inference process. Bernardo's draft says OWL-DL and OWL-Lite have NEXPTIME-complete and EXP-TIME-complete combined complexities, respectively. I have some doubts about that though. 1. Is there a DL reasoner that reduces the complexity of key inference problems to polynomial time? 2. What means "taxonomic complexity is that measured w.r.t. the SIZE OF THE AXIOMS in the ontology"? 3. Which OWL (or DL) constructs raise computational complexity (e.g. allValuesFrom) w.r.t. key inference problems? Which paper (or any reference) brings a comprehensive description of the complexity behind each construct? 4. What would be the computational complexity if OWL 1.1 added a composition property for expressing mereological relations (e.g. isPartOf)? Sorry for so many questions, but I really need those answers to continue my PhD work. Regards, Renato Bulc?o Neto --------------------------------------------------------------------- PhD candidate at ICMC-USP Area: Semantic Web and Ubiquitous Computing From bparsia at isr.umd.edu Mon Feb 20 08:33:32 2006 From: bparsia at isr.umd.edu (Bijan Parsia) Date: Mon Feb 20 08:33:35 2006 Subject: [OWL] OWL and computational complexity In-Reply-To: <59eabcd60602200500td2b1f1an3aa77af860467cef@mail.gmail.com> References: <59eabcd60602200500td2b1f1an3aa77af860467cef@mail.gmail.com> Message-ID: <9650f4aec7bca436114c7426ed2e2ebb@isr.umd.edu> On Feb 20, 2006, at 8:00 AM, Renato Bulc?o wrote: > Hi all. > > I've read such interesting Bernardo's draft entitled "Tractable > Fragments of the OWL 1.1 Web Ontology Language". My PhD work is the > investigation of using SW ontologies in the context of ubiquitous > computing. My supervisor and I have concerned about the computational > complexity using OWL 1.0 ontologies in the making inference process. > > Bernardo's draft says OWL-DL and OWL-Lite have NEXPTIME-complete and > EXP-TIME-complete combined complexities, respectively. I have some > doubts about that though. Why on earth? These are well established. (Frankly, it's a little weird for you to so doubt, esp. when a simple trip to the literature would erase that doubt.) See the wonderful: > 1. Is there a DL reasoner that reduces the complexity of key inference > problems to polynomial time? Since this is impossible, no. Any one claiming to do so should be treated with extreme care. In fact, the most commonly implemented algorithms (tableau) are not worst case optimal (but are 2NEXPTIME even for SHIF/OWL Lite). You may want to read the description logic handbook, or some other survey treatment. Or e.g., the classic SHIF papers. > 2. What means "taxonomic complexity is that measured w.r.t. the SIZE > OF THE AXIOMS in the ontology"? > 3. Which OWL (or DL) constructs raise computational complexity (e.g. > allValuesFrom) w.r.t. key inference problems? Which paper (or any > reference) brings a comprehensive description of the complexity behind > each construct? Chapter 2 of the DLHB should give you a good start. > 4. What would be the computational complexity if OWL 1.1 added a > composition property for expressing mereological relations (e.g. > isPartOf)? > > Sorry for so many questions, but I really need those answers to > continue my PhD work. I doubt it, actually. :) Cheers, Bijan. From bernardo at mindswap.org Tue Feb 21 15:26:15 2006 From: bernardo at mindswap.org (Bernardo Cuenca Grau) Date: Tue, 21 Feb 2006 15:26:15 -0500 (EST) Subject: [OWL] OWL and computational complexity In-Reply-To: <59eabcd60602200500td2b1f1an3aa77af860467cef@mail.gmail.com> References: <59eabcd60602200500td2b1f1an3aa77af860467cef@mail.gmail.com> Message-ID: Hi Renato > 1. Is there a DL reasoner that reduces the complexity of key inference > problems to polynomial time? No. > 2. What means "taxonomic complexity is that measured w.r.t. the SIZE > OF THE AXIOMS in the ontology"? It is measured w.r.t. the size of the TBox (i.e. the ontology without taking the OWL facts into consideration). A Tbox can always be expressed as an ``equivalent'' concept and the size of the TBox can be expressed as the length of such a concept. Please, refer to the DL handbook or any intro to DLs for details. > 3. Which OWL (or DL) constructs raise computational complexity (e.g. > allValuesFrom) w.r.t. key inference problems? Which paper (or any > reference) brings a comprehensive description of the complexity behind > each construct? It is not that a given construct is the cause of intractability. It is most often the case that the *interaction* of several constraucts causes intractability. > 4. What would be the computational complexity if OWL 1.1 added a > composition property for expressing mereological relations (e.g. > isPartOf)? The complexity of OWL 1.1. is currently an open problem. We know it is decidable, but not the exact complexity. Cheers Bernardo > > Sorry for so many questions, but I really need those answers to > continue my PhD work. You should probably spend some time reading the DL handbook and other comprehensive surveys on DLs, as Bijan suggested. > > Regards, > > Renato Bulc?o Neto > --------------------------------------------------------------------- > PhD candidate at ICMC-USP > Area: Semantic Web and Ubiquitous Computing > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl > From alanruttenberg at gmail.com Wed Feb 22 17:48:43 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Wed, 22 Feb 2006 17:48:43 -0500 Subject: [OWL] Limitations on what's told Message-ID: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> Two cases have come up in the BioPAX ontology which look like they could be solved by some sort of syntax that limits what is "told". First is a case of "abstract classes" classes which, it is desired, not be directly instantiated. The other is an organizing superproperty that is useful for e.g. defining domain and range, and for queries, but for which it is desired that the property not be directly asserted. It occured to me that perhaps something useful can be provided in these cases in the form of an indication to the reasoner that these can not be directly asserted. e.g. ObjectProperty(controller super(participant)) ObjectProperty(participant NotTold) would mean that an OWL tool would indicate that the following fact is not allowed Individual(control01 value(participant ....)) and Class(entity NotTold) Individual(entity01 rdf:type entity) would signal a similar error. Note that this wouldn't effect the sematics because it doesn't prevent the reasoner from concluding similar statements. It's just a simple way to allow people to express something close to what they are already saying in documentation, but which can't be enforced within the language. (I'm not thrilled with "NotTold" as the keyword but couldn't come up with something better - suggestions welcome) -Alan From Phillip.Lord at newcastle.ac.uk Thu Feb 23 07:02:44 2006 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Thu, 23 Feb 2006 12:02:44 -0000 Subject: [OWL] Limitations on what's told Message-ID: <6942EE35B530F84EAD432959F5E4DAB501C4AEC8@largo.campus.ncl.ac.uk> Alan Ruttenberg wrote: > Two cases have come up in the BioPAX ontology which look like they > could be solved by some sort of syntax that limits what is "told". > > First is a case of "abstract classes" classes which, it is desired, > not be directly instantiated. This sounds like a nice idea following on from the OO paradigm, but I don't think it makes sense in the case of OWL, as "directly instantiated" doesn't have an obvious meaning. If I make the statement that Individual x (value X) all I am saying is that x is an individual of X, not that it is not also a member of a class which is a subclass of X. In the OO paradigm you can say this because you already know all of the classes which exist. With OWL there are always lots of classes. So, I can create a new class Y class {x} which I think with the statements given would be a subclass of X (since we now that little x of class X, all individuals of Y are also of X). Now, surely, x is no longer "directly instantiated". > The other is an organizing > superproperty that is useful for e.g. defining domain and range, and > for queries, but for which it is desired that the property not be > directly asserted. > > It occured to me that perhaps something useful can be provided in > these cases in the form of an indication to the reasoner that these > can not be directly asserted. e.g. > > ObjectProperty(controller super(participant)) > ObjectProperty(participant NotTold) > > would mean that an OWL tool would indicate that the following fact is > not allowed > > Individual(control01 value(participant ....)) > > and Class(entity NotTold) > > Individual(entity01 rdf:type entity) would signal a similar error. > > Note that this wouldn't effect the sematics because it doesn't > prevent the reasoner from concluding similar statements. It's just a > simple way to allow people to express something close to what they > are already saying in documentation, but which can't be enforced > within the language. > > (I'm not thrilled with "NotTold" as the keyword but couldn't come up > with something better - suggestions welcome) I think you're basic idea here is good, in terms of being able to describe enough metadata about the ontology to describe how it should be presented to the user. We have a clear use case for this as well-- we are generating an ontology which is property based, but which we wish to export for primary use as a controlled vocab. This is fine but we want to export just a subset of the terms not all of them. I used to think that the correct way to do this was to use annotation properties, but then I tried to keep up with the discussion on this list about annotation properties, and have come to the conclusion that it's a bad way which abuses the defined semantics of OWL. Of course, as we don't have many other options, we'll probably do this anyway. Phil From Ulrike.Sattler at manchester.ac.uk Thu Feb 23 07:24:39 2006 From: Ulrike.Sattler at manchester.ac.uk (Uli Sattler) Date: Thu, 23 Feb 2006 12:24:39 +0000 Subject: [OWL] Limitations on what's told In-Reply-To: <6942EE35B530F84EAD432959F5E4DAB501C4AEC8@largo.campus.ncl.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AEC8@largo.campus.ncl.ac.uk> Message-ID: <7F210301-A887-4244-A6CE-4ED78AE312C5@cs.man.ac.uk> On 23 Feb 2006, at 12:02, Phillip Lord wrote: > Alan Ruttenberg wrote: >> Two cases have come up in the BioPAX ontology which look like they >> could be solved by some sort of syntax that limits what is "told". >> >> First is a case of "abstract classes" classes which, it is desired, >> not be directly instantiated. > > This sounds like a nice idea following on from the OO paradigm, but > I don't think it makes sense in the case of OWL, as "directly > instantiated" > doesn't have an obvious meaning. > > If I make the statement that > > Individual x (value X) > > all I am saying is that x is an individual of X, not that it is not > also a member of a class which is a subclass of X. In the OO paradigm > you can say this because you already know all of the classes which > exist. With OWL there are always lots of classes. So, I can create a > new class > > Y class > {x} > > which I think with the statements given would be a subclass of > X (since we now that little x of class X, all individuals of Y > are also of X). Now, surely, x is no longer "directly instantiated". > > Hm, first there are 2 different ways of semantics for thiese "abstract classes": let A be a class, and B1,...,Bk its subclasses. (1) If something is an instance of A, then it must be an instance of one of the Bi. This can easily be achieved by adding SubClassOf(A (UnionOf B1 ... Bk)) to your ontology. (2) (more tricky) If an object x is inferred to be an instance of A, then there is some Bi such that x is inferred to be an instance of Bi. This is not possible in plain OWL or any other fragment of first order logic, but it can be expressed using the epistemic operator K, see the work by Rosati et al. We have mentioned this K operator as a possible candidate for OWL 2, but we were not yet clear of where to allow for it... Cheers, Uli From matthew.pocock at ncl.ac.uk Thu Feb 23 08:00:33 2006 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Thu, 23 Feb 2006 13:00:33 +0000 Subject: [OWL] Limitations on what's told In-Reply-To: <6942EE35B530F84EAD432959F5E4DAB501C4AEC8@largo.campus.ncl.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AEC8@largo.campus.ncl.ac.uk> Message-ID: <200602231300.33635.matthew.pocock@ncl.ac.uk> On Thursday 23 February 2006 12:02, Phillip Lord wrote: > Alan Ruttenberg wrote: > > First is a case of "abstract classes" classes which, it is desired, > > not be directly instantiated. > > This sounds like a nice idea following on from the OO paradigm, but > I don't think it makes sense in the case of OWL, as "directly > instantiated" > doesn't have an obvious meaning. Perhaps making an "abstract class" in OWL would be a restriction on the a-box such that there are no statements of the form instance(x AbstractX) allowed in the /explicitly writen down/ a-box, regardless of what is in the inferred/inferable one. I think by analogy, nottold for properties would ensure that there were no a-box statements explicitly written down using the property. This shouldn't be taken as a statement that I consider abstract classes in OWL to be a sane concept though. From Phillip.Lord at newcastle.ac.uk Thu Feb 23 11:04:32 2006 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Thu, 23 Feb 2006 16:04:32 -0000 Subject: [OWL] Limitations on what's told Message-ID: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> Uli Sattler wrote: > On 23 Feb 2006, at 12:02, Phillip Lord wrote: > >> Alan Ruttenberg wrote: >>> Two cases have come up in the BioPAX ontology which look like they >>> could be solved by some sort of syntax that limits what is "told". >>> >>> First is a case of "abstract classes" classes which, it is desired, >>> not be directly instantiated. >> >> This sounds like a nice idea following on from the OO paradigm, but >> I don't think it makes sense in the case of OWL, as "directly >> instantiated" doesn't have an obvious meaning. >> >> If I make the statement that >> > Hm, first there are 2 different ways of semantics for thiese > "abstract classes": let A be a class, and B1,...,Bk its subclasses. > > (1) If something is an instance of A, then it must be an instance of > one of the Bi. This can easily be achieved by adding > SubClassOf(A (UnionOf B1 ... Bk)) to your ontology. > > (2) (more tricky) If an object x is inferred to be an instance of A, > then there is some Bi such that x is inferred to be an instance of > Bi. This is not possible in plain OWL or any other fragment of first > order logic, but it can be expressed using the epistemic operator K, > see the work by Rosati et al. We have mentioned this K operator as a > possible candidate for OWL 2, but we were not yet clear of where to > allow for it... Uli If I may be bold enough to guess what use Alan is trying to fulfil, then I think that the first of these fails to achieve what he wants. The second one might also, but I don't really know. Using your terminology and having A cover B1...Bk, this still does not prevent me from saying a individualOf A We know that a must also be of type B1...Bk, but we don't know which one of them. I suspect that what Alan is thinking of is the typical biological scenario which biopax will have. One group of people define an ontology up front, then lots of people use it to "annotate" their data. So the T-Box is written by committee, the A-Box post-hoc. So, for example, using standard Manchester design patterns, you never want someone to generate a direct instance of "ValuePartition", or using even "Spicyness", rather you want "Hot, Medium, Mild". Far as I can see, you have to just hide this possibility from the user. Alan, do I have your use case right? Phil From alanr at mumble.net Thu Feb 23 11:51:34 2006 From: alanr at mumble.net (Alan Ruttenberg) Date: Thu, 23 Feb 2006 11:51:34 -0500 Subject: [OWL] Limitations on what's told In-Reply-To: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> Message-ID: <2D7A849E-07ED-438A-B9AF-E15E4E95ED80@mumble.net> Hi All, Yes, Phil has the use case right. I also want to clarify that I'm trying to avoid any impact to the semantics in my proposal. For example, Class(B1 NotTold) SubClassOf(A (UnionOf B1 B2)) Disjoint(B1 B2) Individual(a rdf:type intersection(A complement(B2))) From this we have that a is an instance of B1 but i *do not* propose that this signal an error. I'm proposing something which operates strictly at the lexical level. You just can't say Individual(a rdf:type B1) I don't think that semantics of "abstract classes" make a lot of sense broadly so I'm deliberately trying to avoid going there. On the other hand I worry when I see a pattern that is repeatedly used and documented but not made explicit and checked. -Alan On Feb 23, 2006, at 11:04 AM, Phillip Lord wrote: > > Uli > > If I may be bold enough to guess what use Alan is trying to fulfil, > then I think that the first of these fails to achieve what he wants. > The second one might also, but I don't really know. > > Using your terminology and having A cover B1...Bk, this still does > not prevent me from saying > > a individualOf A > > We know that a must also be of type B1...Bk, but we don't know which > one of them. > > I suspect that what Alan is thinking of is the typical biological > scenario which biopax will have. One group of people define an > ontology up front, then lots of people use it to "annotate" their > data. So the T-Box is written by committee, the A-Box post-hoc. > > So, for example, using standard Manchester design patterns, you never > want someone to generate a direct instance of "ValuePartition", > or using even "Spicyness", rather you want "Hot, Medium, Mild". > Far as I can see, you have to just hide this possibility from > the user. > > Alan, do I have your use case right? > > Phil > > > > > > > > > > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl From Ulrike.Sattler at manchester.ac.uk Thu Feb 23 12:16:03 2006 From: Ulrike.Sattler at manchester.ac.uk (Uli Sattler) Date: Thu, 23 Feb 2006 17:16:03 +0000 Subject: [OWL] Limitations on what's told In-Reply-To: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> Message-ID: <653CCEB2-0142-458C-9206-BB77F682E302@cs.man.ac.uk> On 23 Feb 2006, at 16:04, Phillip Lord wrote: > Uli Sattler wrote: >> On 23 Feb 2006, at 12:02, Phillip Lord wrote: >> >>> Alan Ruttenberg wrote: >>>> Two cases have come up in the BioPAX ontology which look like they >>>> could be solved by some sort of syntax that limits what is "told". >>>> >>>> First is a case of "abstract classes" classes which, it is desired, >>>> not be directly instantiated. >>> >>> This sounds like a nice idea following on from the OO paradigm, but >>> I don't think it makes sense in the case of OWL, as "directly >>> instantiated" doesn't have an obvious meaning. >>> >>> If I make the statement that >>> >> Hm, first there are 2 different ways of semantics for thiese >> "abstract classes": let A be a class, and B1,...,Bk its subclasses. >> >> (1) If something is an instance of A, then it must be an instance of >> one of the Bi. This can easily be achieved by adding >> SubClassOf(A (UnionOf B1 ... Bk)) to your ontology. >> >> (2) (more tricky) If an object x is inferred to be an instance of A, >> then there is some Bi such that x is inferred to be an instance of >> Bi. This is not possible in plain OWL or any other fragment of first >> order logic, but it can be expressed using the epistemic operator K, >> see the work by Rosati et al. We have mentioned this K operator as a >> possible candidate for OWL 2, but we were not yet clear of where to >> allow for it... > > > > Uli > > If I may be bold enough to guess what use Alan is trying to fulfil, > then I think that the first of these fails to achieve what he wants. > The second one might also, but I don't really know. > > Using your terminology and having A cover B1...Bk, this still does > not prevent me from saying > > a individualOf A > > We know that a must also be of type B1...Bk, but we don't know which > one of them. I am afraid you misunderstood my second reading: If an object x is inferred to be an instance of A, then there is some Bi such that x is inferred to be an instance of Bi -- that means that you also know which one it is! Yet, this is still different from what Alan had in mind -- Alan would be happy (Alan?) if we could check, for each ontology and for each abstract class A and each instance x of A, whether our knowledge base implies that x is also an instance of B, for B a subclass of A. In case this is not the case, Alan would want to see a "warning" being raised. This can clearly be solved with a little "syntactic sugar" and a tool asking/querying the ontology. Cheers, Uli > > I suspect that what Alan is thinking of is the typical biological > scenario which biopax will have. One group of people define an > ontology up front, then lots of people use it to "annotate" their > data. So the T-Box is written by committee, the A-Box post-hoc. > > So, for example, using standard Manchester design patterns, you never > want someone to generate a direct instance of "ValuePartition", > or using even "Spicyness", rather you want "Hot, Medium, Mild". > Far as I can see, you have to just hide this possibility from > the user. > > Alan, do I have your use case right? > > Phil > > > > > > > > > > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl From Phillip.Lord at newcastle.ac.uk Thu Feb 23 12:34:37 2006 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Thu, 23 Feb 2006 17:34:37 -0000 Subject: [OWL] Limitations on what's told Message-ID: <6942EE35B530F84EAD432959F5E4DAB501C4AFBA@largo.campus.ncl.ac.uk> Uli Sattler wrote: > On 23 Feb 2006, at 16:04, Phillip Lord wrote: > >> Uli Sattler wrote: >>> On 23 Feb 2006, at 12:02, Phillip Lord wrote: >>> >>>> Alan Ruttenberg wrote: >>>>> Two cases have come up in the BioPAX ontology which look like they >>>>> could be solved by some sort of syntax that limits what is "told". >>>>> >>>>> First is a case of "abstract classes" classes which, it is >>>>> desired, not be directly instantiated. >>>> >>>> This sounds like a nice idea following on from the OO paradigm, but >>>> I don't think it makes sense in the case of OWL, as "directly >>>> instantiated" doesn't have an obvious meaning. >>>> >>>> If I make the statement that >>>> >>> Hm, first there are 2 different ways of semantics for thiese >>> "abstract classes": let A be a class, and B1,...,Bk its subclasses. >>> >>> (1) If something is an instance of A, then it must be an instance of >>> one of the Bi. This can easily be achieved by adding >>> SubClassOf(A (UnionOf B1 ... Bk)) to your ontology. >>> >>> (2) (more tricky) If an object x is inferred to be an instance of A, >>> then there is some Bi such that x is inferred to be an instance of >>> Bi. This is not possible in plain OWL or any other fragment of first >>> order logic, but it can be expressed using the epistemic operator K, >>> see the work by Rosati et al. We have mentioned this K operator as a >>> possible candidate for OWL 2, but we were not yet clear of where to >>> allow for it... >> >> >> >> Uli >> >> If I may be bold enough to guess what use Alan is trying to fulfil, >> then I think that the first of these fails to achieve what he wants. >> The second one might also, but I don't really know. >> >> Using your terminology and having A cover B1...Bk, this still does >> not prevent me from saying >> >> a individualOf A >> >> We know that a must also be of type B1...Bk, but we don't know which >> one of them. > > I am afraid you misunderstood my second reading: Don't be afraid! This isn't the first time I have misunderstood you and I'm sure it won't be the last! Besides, I did say I didn't really know. > If an object x is > inferred to be an instance of A, then there is some Bi such that x is > inferred to be an instance of Bi -- that means that you also know > which one it is! Okay, this is clearer. > > Yet, this is still different from what Alan had in mind -- Alan > would be happy (Alan?) if we could check, for each ontology and for > each abstract class A and each instance x of A, whether our knowledge > base implies that x is also an instance of B, for B a subclass of A. > In case this is not the case, Alan would want to see a "warning" > being raised. This can clearly be solved with a little "syntactic > sugar" and a tool asking/querying the ontology. > I think he wants less than this -- If I have an Individual b which is an instance of B1 or B2...Bk then I *think* this makes it an instance of A, but not necessarily of any of the subclasses. But this example should not be recognised. As you say, I think this needs either syntactic sugar or tools support. It would, however, be nice to be able to embed the metadata about the terms into the ontology, and to have at least best practices so this can be done in a standard way. As I say, we want to do something similar at Newcastle, and I wanted to be able to do the same thing with work from Manchester. To misquote Meatloaf, three out of three ain't bad... Phil From alanruttenberg at gmail.com Thu Feb 23 13:56:26 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Thu, 23 Feb 2006 13:56:26 -0500 Subject: [OWL] Limitations on what's told In-Reply-To: <653CCEB2-0142-458C-9206-BB77F682E302@cs.man.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> <653CCEB2-0142-458C-9206-BB77F682E302@cs.man.ac.uk> Message-ID: This would be even better than what I am proposing, since it would take into account inference. I'm only a bit worried about the implementation because it could be the case that there are classes other than the ones that the user explicitly declared which are used by the reasoner. You would want the complaint to happen only if when there was no B that the user had declared as a class(told) which x was an instance of. Don't forget the property case. But I think the same strategy could work. In this case the same problem as above holds. For instance, I think pellet implements inverse functional properties by creating an inverse property and declaring that functional. We don't want such properties to erase the warning when we are checking whether a value is asserted only on an "NotTold property". But, like I said, I am less ambitious than this. Just preventing it at the lexical level would be an advance, I think. -Alan On Feb 23, 2006, at 12:16 PM, Uli Sattler wrote: > Yet, this is still different from what Alan had in mind -- Alan > would be happy (Alan?) if we could check, for each ontology and for > each abstract class A and each instance x of A, whether our knowledge > base implies that x is also an instance of B, for B a subclass of A. > In case this is not the case, Alan would want to see a "warning" > being raised. This can clearly be solved with a little "syntactic > sugar" and a tool asking/querying the ontology. > > Cheers, Uli From pfps at research.bell-labs.com Thu Feb 23 15:41:40 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Thu, 23 Feb 2006 15:41:40 -0500 (EST) Subject: [OWL] Limitations on what's told In-Reply-To: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> References: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> Message-ID: <20060223.154140.122217017.pfps@research.bell-labs.com> I believe that all you are asking for is some way to flay inappropriate syntactic constructs, e.g., Individual(entity01 type(entity)) The key here is the "syntactic" above. I don't favour adding semantic information to flag such constructs. However, I suppose that one could use annotations for this purpose, i.e., annoint a standard "annotation" property that would signal to systems that particular syntactic constructions are errors. The annotation would not, of course, have any extra semantic force, and many systems would simply ignore its "out-of-band" meaning. peter From: Alan Ruttenberg Subject: [OWL] Limitations on what's told Date: Wed, 22 Feb 2006 17:48:43 -0500 > Two cases have come up in the BioPAX ontology which look like they > could be solved by some sort of syntax that limits what is "told". > > First is a case of "abstract classes" classes which, it is desired, > not be directly instantiated. The other is an organizing > superproperty that is useful for e.g. defining domain and range, and > for queries, but for which it is desired that the property not be > directly asserted. > > It occured to me that perhaps something useful can be provided in > these cases in the form of an indication to the reasoner that these > can not be directly asserted. e.g. > > ObjectProperty(controller super(participant)) > ObjectProperty(participant NotTold) > > would mean that an OWL tool would indicate that the following fact is > not allowed > > Individual(control01 value(participant ....)) > > and Class(entity NotTold) > > Individual(entity01 rdf:type entity) would signal a similar error. > > Note that this wouldn't effect the sematics because it doesn't > prevent the reasoner from concluding similar statements. It's just a > simple way to allow people to express something close to what they > are already saying in documentation, but which can't be enforced > within the language. > > (I'm not thrilled with "NotTold" as the keyword but couldn't come up > with something better - suggestions welcome) > > -Alan From alanruttenberg at gmail.com Fri Feb 24 00:37:01 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Fri, 24 Feb 2006 00:37:01 -0500 Subject: [OWL] Limitations on what's told In-Reply-To: <20060223.154140.122217017.pfps@research.bell-labs.com> References: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> <20060223.154140.122217017.pfps@research.bell-labs.com> Message-ID: <888a2a047e73e1e47eb0a38d22e0e89d@gmail.com> On Feb 23, 2006, at 3:41 PM, Peter F. Patel-Schneider wrote: > I believe that all you are asking for is some way to flag inappropriate > syntactic constructs, e.g., > > Individual(entity01 type(entity)) > > The key here is the "syntactic" above. I don't favour adding semantic > information to flag such constructs. Syntactic is what I think I am aiming for. But I'm not sure what you mean by "adding semantic information to flag such constructs". Do you mean adding a keyword, like InverseFunctional. or NotTold? Could you explain? > However, I suppose that one could use annotations for this purpose, > i.e., > annoint a standard "annotation" property that would signal to systems > that > particular syntactic constructions are errors. The annotation would > not, of > course, have any extra semantic force, and many systems would simply > ignore its > "out-of-band" meaning. I think the annotations would be fine. The part of what you say that worries me is the part about systems ignoring them. Either a user can count on a behavior or not. If not then the feature is useless. Or am I misunderstanding you? -Alan > > peter > > > > From: Alan Ruttenberg > Subject: [OWL] Limitations on what's told > Date: Wed, 22 Feb 2006 17:48:43 -0500 > >> Two cases have come up in the BioPAX ontology which look like they >> could be solved by some sort of syntax that limits what is "told". >> >> First is a case of "abstract classes" classes which, it is desired, >> not be directly instantiated. The other is an organizing >> superproperty that is useful for e.g. defining domain and range, and >> for queries, but for which it is desired that the property not be >> directly asserted. >> >> It occured to me that perhaps something useful can be provided in >> these cases in the form of an indication to the reasoner that these >> can not be directly asserted. e.g. >> >> ObjectProperty(controller super(participant)) >> ObjectProperty(participant NotTold) >> >> would mean that an OWL tool would indicate that the following fact is >> not allowed >> >> Individual(control01 value(participant ....)) >> >> and Class(entity NotTold) >> >> Individual(entity01 rdf:type entity) would signal a similar error. >> >> Note that this wouldn't effect the sematics because it doesn't >> prevent the reasoner from concluding similar statements. It's just a >> simple way to allow people to express something close to what they >> are already saying in documentation, but which can't be enforced >> within the language. >> >> (I'm not thrilled with "NotTold" as the keyword but couldn't come up >> with something better - suggestions welcome) >> >> -Alan From matthew.pocock at ncl.ac.uk Fri Feb 24 06:21:37 2006 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Fri, 24 Feb 2006 11:21:37 +0000 Subject: [OWL] k and imports Message-ID: <200602241121.37850.matthew.pocock@ncl.ac.uk> Hi, There has been an ongoing discussion about import. Can I throw another import thingy into the pot? Let's say I know (or claim to know) everything about an area. For example, I have an ontology that discusses DNA and RNA nucleotides, which includes individuals representing the DNA nucleotides A, G, C, T. It would be kind of nice if I could annotate the ontology with assertions that I have provided all the information about certain individuals and relationships. For example, stating that the ontology lists every instance of the concept DNA_Nucleotide. Any individual outside of this ontology that is asserted as a DNA_Nucleotide must therefore be equivalent to one of the nucleotides introduced in this ontology. This is an example where we can trivially rig this behavior with existing axioms, but in other cases this is not easy. For example, if I had an OWL ontology that is a document exported from a database that is defined as containing all the data about particular things, then it would be a right royal pain (not to mention very verbose) to list the gazillion assertions needed to enforce these semantics on something that includes this ontology. So - the options (non-exlcusive) are: 1) within an ontology, use the 'k' operator to close-world a concept 2) as annotation on an ontology, state that this is definitive for some concept(s) 3) as part of an enritched import statement, state that the ontology being imported is definitive for some concept(s) This is one of those import thingies that impacts both on syntax and semantics, and I have no idea how this would interact with importing an ontology fragment. Matthew From pfps at research.bell-labs.com Fri Feb 24 06:40:27 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Fri, 24 Feb 2006 06:40:27 -0500 (EST) Subject: [OWL] Limitations on what's told In-Reply-To: <888a2a047e73e1e47eb0a38d22e0e89d@gmail.com> References: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> <20060223.154140.122217017.pfps@research.bell-labs.com> <888a2a047e73e1e47eb0a38d22e0e89d@gmail.com> Message-ID: <20060224.064027.20944331.pfps@research.bell-labs.com> From: Alan Ruttenberg Subject: Re: [OWL] Limitations on what's told Date: Fri, 24 Feb 2006 00:37:01 -0500 > On Feb 23, 2006, at 3:41 PM, Peter F. Patel-Schneider wrote: > > > I believe that all you are asking for is some way to flag inappropriate > > syntactic constructs, e.g., > > > > Individual(entity01 type(entity)) > > > > The key here is the "syntactic" above. I don't favour adding semantic > > information to flag such constructs. > > Syntactic is what I think I am aiming for. But I'm not sure what you > mean by "adding semantic information to flag such constructs". Do you > mean adding a keyword, like InverseFunctional. or NotTold? Could you > explain? You are asking for an addition to the language (the NotTold construct). I assumed that this would go through as some sort of assertion, i.e., a fact. I suppose, however, that it would be possible that this bit of the language has no semantic meaning. Of course this is not possible in a same-syntax semantic extension of RDF (like OWL), but we are already proposing to make OWL 1.1 not be a same-syntax semantic extension of RDF. > > However, I suppose that one could use annotations for this purpose, > > i.e., > > annoint a standard "annotation" property that would signal to systems > > that > > particular syntactic constructions are errors. The annotation would > > not, of > > course, have any extra semantic force, and many systems would simply > > ignore its > > "out-of-band" meaning. > > I think the annotations would be fine. The part of what you say that > worries me is the part about systems ignoring them. Either a user can > count on a behavior or not. If not then the feature is useless. Well, there are problems with requiring all systems to "gag" here. How should a simple reasoner "gag" if it sees the forbidden situation? > Or am I misunderstanding you? > > -Alan peter From Phillip.Lord at newcastle.ac.uk Fri Feb 24 07:02:47 2006 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 24 Feb 2006 12:02:47 -0000 Subject: [OWL] Limitations on what's told Message-ID: <6942EE35B530F84EAD432959F5E4DAB501C4B081@largo.campus.ncl.ac.uk> Alan Ruttenberg wrote: > > I think the annotations would be fine. The part of what you say that > worries me is the part about systems ignoring them. Either a user can > count on a behavior or not. If not then the feature is useless. > > Or am I misunderstanding you? > I think the difficulty here is that we have two meanings for "semantic". The logicians always interpret this as meaning "having logical import". On the other hand, I would claim that that there is a clear implied semantic associated with 'rdf:label lang="en"' which says "present this to the user if they are in an English locale". My own feeling is that extra-logical features which is, I think, the best way of implementing what you are asking for, have a clear place in OWL as a language and should be there. Having said that, it's currently relatively unclear what extra-logical features we need, and exactly how they should work. In the first instance, I think that we have to go for best practice use of annotations, which from what Peter's last email said should be possible under 1.1. Best practice means that, no users can't "rely" on it totally. But it should make it possible to change more freely, until we are sure what extra-logical features we really need and which could perhaps be a feature of OWL 2. Cheers Phil From pfps at research.bell-labs.com Fri Feb 24 07:39:55 2006 From: pfps at research.bell-labs.com (Peter F. Patel-Schneider) Date: Fri, 24 Feb 2006 07:39:55 -0500 (EST) Subject: [OWL] Limitations on what's told In-Reply-To: <6942EE35B530F84EAD432959F5E4DAB501C4B081@largo.campus.ncl.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4B081@largo.campus.ncl.ac.uk> Message-ID: <20060224.073955.130588858.pfps@research.bell-labs.com> From: "Phillip Lord" Subject: Re: [OWL] Limitations on what's told Date: Fri, 24 Feb 2006 12:02:47 -0000 > > Alan Ruttenberg wrote: > > > > I think the annotations would be fine. The part of what you say that > > worries me is the part about systems ignoring them. Either a user can > > count on a behavior or not. If not then the feature is useless. > > > > Or am I misunderstanding you? > > > > I think the difficulty here is that we have two meanings for "semantic". > > The logicians always interpret this as meaning "having logical import". > On the other hand, I would claim that that there is a clear implied > semantic associated with 'rdf:label lang="en"' which says "present this > to the user if they are in an English locale". > > My own feeling is that extra-logical features which is, I think, the > best > way of implementing what you are asking for, have a clear place in OWL > as a language and should be there. Us battle-scarred veterans of the WebOnt WG worry about again getting into a situation where every bit of OWL 1.1 syntax has to have a model-theoretic "shadow" via the same-syntax extension of RDF route. This makes us leery of adding syntactic stuff to the language that should not have such a semantic shadow. > Having said that, it's currently relatively unclear what extra-logical > features we need, and exactly how they should work. In the first > instance, > I think that we have to go for best practice use of annotations, which > from what Peter's last email said should be possible under 1.1. > > Best practice means that, no users can't "rely" on it totally. But > it should make it possible to change more freely, until we are sure what > extra-logical features we really need and which could perhaps be a > feature > of OWL 2. > > Cheers > > Phil peter From alanruttenberg at gmail.com Fri Feb 24 18:29:31 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Fri, 24 Feb 2006 18:29:31 -0500 Subject: [OWL] Limitations on what's told In-Reply-To: <20060224.064027.20944331.pfps@research.bell-labs.com> References: <8323F082-3B1E-40FA-AF32-48162AE6DC50@gmail.com> <20060223.154140.122217017.pfps@research.bell-labs.com> <888a2a047e73e1e47eb0a38d22e0e89d@gmail.com> <20060224.064027.20944331.pfps@research.bell-labs.com> Message-ID: Ok. Practically speaking, here is what could be done. NotTold looks like InverseFunctional in the abstract syntax, but really is syntactic sugar for an annotation property - the translation rules to rdf would state that. That way there is no semantic shadow. The annotation property specifically used would be in the owl namespace (is it stated anywhere that the owl namespace is reserved for future extensions to OWL?). Implementations would be expected to gag by stating that there was an inconsistency - the syntactic form was stated to be disallowed, but was used. This is analogous to any other consistency failure. Does this cause any problems? -Alan On Feb 24, 2006, at 6:40 AM, Peter F. Patel-Schneider wrote: > From: Alan Ruttenberg > Subject: Re: [OWL] Limitations on what's told > Date: Fri, 24 Feb 2006 00:37:01 -0500 > >> On Feb 23, 2006, at 3:41 PM, Peter F. Patel-Schneider wrote: >> >>> I believe that all you are asking for is some way to flag >>> inappropriate >>> syntactic constructs, e.g., >>> >>> Individual(entity01 type(entity)) >>> >>> The key here is the "syntactic" above. I don't favour adding >>> semantic >>> information to flag such constructs. >> >> Syntactic is what I think I am aiming for. But I'm not sure what you >> mean by "adding semantic information to flag such constructs". Do you >> mean adding a keyword, like InverseFunctional. or NotTold? Could you >> explain? > > You are asking for an addition to the language (the NotTold > construct). I > assumed that this would go through as some sort of assertion, i.e., > a fact. I > suppose, however, that it would be possible that this bit of the > language has > no semantic meaning. Of course this is not possible in a same- > syntax semantic > extension of RDF (like OWL), but we are already proposing to make > OWL 1.1 not > be a same-syntax semantic extension of RDF. > >>> However, I suppose that one could use annotations for this purpose, >>> i.e., >>> annoint a standard "annotation" property that would signal to >>> systems >>> that >>> particular syntactic constructions are errors. The annotation would >>> not, of >>> course, have any extra semantic force, and many systems would simply >>> ignore its >>> "out-of-band" meaning. >> >> I think the annotations would be fine. The part of what you say that >> worries me is the part about systems ignoring them. Either a user can >> count on a behavior or not. If not then the feature is useless. > > Well, there are problems with requiring all systems to "gag" here. > How should > a simple reasoner "gag" if it sees the forbidden situation? > >> Or am I misunderstanding you? >> >> -Alan > > peter From rector at cs.man.ac.uk Sun Feb 26 04:59:15 2006 From: rector at cs.man.ac.uk (Alan Rector) Date: Sun, 26 Feb 2006 10:59:15 +0100 Subject: [OWL] Limitations on what's told In-Reply-To: <653CCEB2-0142-458C-9206-BB77F682E302@cs.man.ac.uk> References: <6942EE35B530F84EAD432959F5E4DAB501C4AF8B@largo.campus.ncl.ac.uk> <653CCEB2-0142-458C-9206-BB77F682E302@cs.man.ac.uk> Message-ID: Uli, Alan I think this is a matter of the "View' of the ontology. As such it is a sensible thing for a metadata vocabulary to be recognised by various tools. The information is clearly about the ontology artefact, not about the domain it represents, hence it does not belong with the first order semantics. However, it is a very important part of the semantics of use of the artefact. I would argue that a reference knowledge base is much more than can be captured in the first order representation and includes much metadata, including that on the authors intention and user-oriented views, that refer the logical representation artefacts rather than the domain concepts represented. Regards Alan On 23 Feb 2006, at 18:16, Uli Sattler wrote: > > On 23 Feb 2006, at 16:04, Phillip Lord wrote: > >> Uli Sattler wrote: >>> On 23 Feb 2006, at 12:02, Phillip Lord wrote: >>> >>>> Alan Ruttenberg wrote: >>>>> Two cases have come up in the BioPAX ontology which look like they >>>>> could be solved by some sort of syntax that limits what is "told". >>>>> >>>>> First is a case of "abstract classes" classes which, it is >>>>> desired, >>>>> not be directly instantiated. >>>> >>>> This sounds like a nice idea following on from the OO paradigm, but >>>> I don't think it makes sense in the case of OWL, as "directly >>>> instantiated" doesn't have an obvious meaning. >>>> >>>> If I make the statement that >>>> >>> Hm, first there are 2 different ways of semantics for thiese >>> "abstract classes": let A be a class, and B1,...,Bk its subclasses. >>> >>> (1) If something is an instance of A, then it must be an instance of >>> one of the Bi. This can easily be achieved by adding >>> SubClassOf(A (UnionOf B1 ... Bk)) to your ontology. >>> >>> (2) (more tricky) If an object x is inferred to be an instance of A, >>> then there is some Bi such that x is inferred to be an instance of >>> Bi. This is not possible in plain OWL or any other fragment of first >>> order logic, but it can be expressed using the epistemic operator K, >>> see the work by Rosati et al. We have mentioned this K operator as a >>> possible candidate for OWL 2, but we were not yet clear of where to >>> allow for it... >> >> >> >> Uli >> >> If I may be bold enough to guess what use Alan is trying to fulfil, >> then I think that the first of these fails to achieve what he wants. >> The second one might also, but I don't really know. >> >> Using your terminology and having A cover B1...Bk, this still does >> not prevent me from saying >> >> a individualOf A >> >> We know that a must also be of type B1...Bk, but we don't know which >> one of them. > > I am afraid you misunderstood my second reading: If an object x is > inferred to be an instance of A, then there is some Bi such that x is > inferred to be an instance of Bi -- that means that you also know > which one it is! > > Yet, this is still different from what Alan had in mind -- Alan > would be happy (Alan?) if we could check, for each ontology and for > each abstract class A and each instance x of A, whether our knowledge > base implies that x is also an instance of B, for B a subclass of A. > In case this is not the case, Alan would want to see a "warning" > being raised. This can clearly be solved with a little "syntactic > sugar" and a tool asking/querying the ontology. > > Cheers, Uli > >> >> I suspect that what Alan is thinking of is the typical biological >> scenario which biopax will have. One group of people define an >> ontology up front, then lots of people use it to "annotate" their >> data. So the T-Box is written by committee, the A-Box post-hoc. >> >> So, for example, using standard Manchester design patterns, you never >> want someone to generate a direct instance of "ValuePartition", >> or using even "Spicyness", rather you want "Hot, Medium, Mild". >> Far as I can see, you have to just hide this possibility from >> the user. >> >> Alan, do I have your use case right? >> >> Phil >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> OWL mailing list >> OWL at lists.mindswap.org >> http://lists.mindswap.org/mailman/listinfo/owl > > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl ----------------------- Alan Rector Professor of Medical Informatics Department of Computer Science University of Manchester Manchester M13 9PL, UK TEL +44 (0) 161 275 6188/6149 FAX +44 (0) 161 275 6204 www.cs.man.ac.uk/mig www.clinical-esciences.org www.co-ode.org From dvr at aifb.uni-karlsruhe.de Sun Feb 26 08:09:56 2006 From: dvr at aifb.uni-karlsruhe.de (Denny Vrandecic) Date: Sun, 26 Feb 2006 14:09:56 +0100 Subject: [OWL] Last CfP and Deadline Extension: EON 2006 -- Evaluating Ontologies for the Semantic Web Message-ID: <4401A8A4.7000401@aifb.uni-karlsruhe.de> Due to a number of requests, we extend the deadline for the EON2006 Workshop for a week until Friday, March 3rd 2006. Apologies for cross-posting. Please forward this mail to anyone interested. *********************************************************************** FINAL CALL FOR PAPERS 4th International EON Workshop Workshop on Evaluation of Ontologies for the Web (EON2006) http://km.aifb.uni-karlsruhe.de/ws/eon2006 Held in conjunction with the 15th International World Wide Web Conference Edinburgh International Conference Center, Edinburgh, UK May 22nd, 2006 *********************************************************************** OBJECTIVES AND TOPICS ===================== In the successful series of EON workshops we intend to bring together researchers and practitioners from the quickly developing research areas Ontologies and Semantic Web. Former EON workshops aimed at evaluating ontology-based tools, this year?s workshop focuses on the Evaluation of Ontologies (content, usability, etc.) themselves. Whereas some effort already was invested in reusing work from related research areas towards the end of Ontology Evaluation, often the basic premises of the web-like environment are forgotten or disregarded. Thus the main goal of this workshop is to lay the foundations for Web Ontology Evaluation. Ontologies now play an important role for many knowledge-intensive applications for which they provide a source of formally defined terms. They aim at capturing domain knowledge in a generic way and provide a commonly agreed understanding of a domain, which may be reused, shared, and operationalized across applications and groups. Numerous ontologies are already available and the number is growing rapidly. Still a well understood definition or even intuition about qualities that apply to ontologies is lacking. The large visibility of the Semantic Web already attracts industrial partners. Ontology-based tools depend more and more on the explicit knowledge captured in ontologies. A well-understood notion of Ontology Evaluation might lead to a consistent level of quality and thus acceptance by industry. For the future this might lead to certification efforts for such ontologies. The aim of this workshop is to ground Ontology Evaluation firmly on the needs of the Semantic Web, especially regarding its web-like characteristics like high interconnectivity, constant change and incompleteness. We will focus on the Semantic Web languages as standardized or proposed by the W3C: RDF(S), OWL and the rule language. We want to encourage and stimulate discussion about the current state of the art in Ontology Evaluation and its future direction. Currently, ontologies and the Semantic Web attract researchers from all around the world and from various disciplines, sometimes forgetful of the new needs and conditions arising from the Semantic Web?s requirements. Main topics of interest include but are not limited to: * Web Ontology Evaluation * Ontology Evaluation Methodologies * Tools for Ontology Evaluation * Ontology Content Evaluation * Task-oriented Evaluation / Task-independent Evaluation * Criteria for Ontology Content Evaluation * Formal/Informal Ontology Evaluation * Evaluation of Heavily Interconnected Ontologies / Networks of Ontologies * Ontology Metrics-based Evaluation * Evaluation-guided revision of Ontologies * Certification of Ontologies PROGRAMM AND EVALUATION ======================= To ensure a creative atmosphere during the workshop, the participants will be selected based on their submitted papers, posing important issues to be presented and discussed at the workshop. The workshop will consist of short presentations followed by discussions about the goals of the workshop: the state of the art in Ontology Evaluation with regards to the needs of the Semantic Web and outlining a plan for future research. Also there will be a practical session, where three ontologies are to be evaluated by the participants beforehand and the results being discussed at the workshop. In order to obtain an intensive exchange of ideas between the participants, there will be left extensive time for discussion. The previous workshops (EON2002, EON2003 and EON2004) proposed a series of experiments for evaluating different aspects of ontology tools, e.g. their expressiveness and interoperability capabilities. The aim of the EON series is to attract attention to a number of evaluation topics since we believe this to be a highly relevant issue for the adaptation of Semantic Web technologies by partners outside the Semantic Web community. This year we focus on ontologies themselves. Taking into account the success of the former workshops in this series, we will not only expect regular contributions on any of the topics addressed in this CFP, but we will also look forward to receiving submissions based on experimental results, surveys and tools for Ontology Evaluation. The EON2006 workshop is intended to be a platform to discuss results and further steps with interested parties. Along with these experimental contributions, we explicitly encourage people to make demos of their tools. We will reserve time slots for demos in the workshop. Prior the workshop all participants will be asked to evaluate three ontologies according to their approaches. The workshop will facilitate discussion by comparing the results of the participants. This is not meant as a test or as homework, as we don?t know the correct results ourselves yet ? it is the goal of this workshop to answer this very question. The ontologies will be downloadable at the workshop?s website. A final panel will discuss the research agenda for the coming years, based on the presentations and results from the demos, evaluations and discussions. IMPORTANT DATES =============== Deadline paper submissions: ** March 3rd, 2006 ** extension ** Notification of acceptance: March 20th, 2006 Camera ready deadline: March 31st, 2006 Workshop: May 22nd, 2006 SUBMISSIONS =========== Interested authors should submit an electronic PDF and source version of their papers to eon2006 at aifb.uni-karlsruhe.de prior to the paper submission deadline. The first page of submitted papers should include: title, author names, affiliations, postal addresses, electronic mail addresses, telephone and fax numbers for all authors, and a brief abstract. All correspondence will be sent to the author mentioned as contact person in the electronic title page (by default, the first author). Submissions should not exceed 8 pages and should be formatted according to the guidelines of the WWW conference (see http://www2006.org/cfp/submissions.php ). We also welcome position papers no longer than 4 pages. ORGANIZERS ========== * Denny Vrandecic, Institute AIFB, University of Karlsruhe, Germany * Mari Carmen Suarez-Figueroa, Facultad de Informatica, Universidad Politecnica de Madrid, Spain * Aldo Gangemi, Laboratory for Applied Ontology, Institute for Cognitive Sciences and Technology, Rome, Italy * York Sure, Institute AIFB, University of Karlsruhe, Germany PROGRAM COMMITTEE ================= * Sean Bechhofer, University of Manchester (UK) * Christopher Brewster, University of Sheffield (UK) * Dan Brickley, Semantic Web Vapourware Ltd and ILRT, University of Bristol (UK) * Oscar Corcho, University of Manchester (UK) * Roberta Cuel, University of Trento (IT) * Mariano Fernandez-Lopez, Universidad Politecnica de Madrid (ES) * Asuncion Gomez-Perez, Universidad Politecnica de Madrid (ES) * Marko Grobelnik, Jozef Stefan Institute (SI) * Nicola Guarino, Laboratory for Applied Ontology (IT) * Kouji Kozaki, Osaka University (JP) * Deborah McGuinness, Stanford University (US) * Libby Miller, Asemantics (IT) * Enrico Motta, Open University (UK) * Elena Paslaru Bontas, Freie Universitaet Berlin (DE) * Sofia Pinto, Technical University of Lisbon (PT) * Robert Porzel, European Media Laboratory (DE) * Steffen Staab, Universit?t Koblenz (DE) * Rudi Studer, University of Karlsruhe (DE) * Chris Welty, IBM (US) CONTACT ======= You may enquire all further information from Denny Vrandecic, denny at aifb.uni-karlsruhe.de WORKSHOP HOMEPAGE ================= http://km.aifb.uni-karlsruhe.de/ws/eon2006 -- Denny Vrandecic Institute AIFB, University of Karlsruhe (TH) http://www.aifb.uni-karlsruhe.de/WBS/ Blog: http://semantic.nodix.net From matthew.pocock at ncl.ac.uk Mon Feb 27 12:58:22 2006 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon, 27 Feb 2006 17:58:22 +0000 Subject: [OWL] inverse datatype properties Message-ID: <200602271758.23062.matthew.pocock@ncl.ac.uk> Hi, When representing actual data in OWL (rather than individual-graphs), I keep needing datatype properties to be more expressive. Our application is data-mining and data-visualisation, where much of the actual information is encoded in concrete data types. In particular, it would be helpful to have: inverseFunctional: the value of the datatype uniquely identifies the individual inverseDatatypeProperty: a property from datatype to individual, allowing us to say things like: give me all the values of the hasAge property datatypeProperty( ... hasInverse inverseDatatypePropertyID) inverseDatatypeProperty( ... hasInverse datypePropertyID ) Assuming that you could only invert datatypeProperties that refer to concrete datatypes with an equivalence relation, would this make the reasoners choke? Matthew From evren at cs.umd.edu Mon Feb 27 13:44:27 2006 From: evren at cs.umd.edu (Evren Sirin) Date: Mon, 27 Feb 2006 13:44:27 -0500 Subject: [OWL] inverse datatype properties In-Reply-To: <200602271758.23062.matthew.pocock@ncl.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> Message-ID: <4403488B.8030109@cs.umd.edu> Matthew Pocock wrote: >Hi, > >When representing actual data in OWL (rather than individual-graphs), I keep >needing datatype properties to be more expressive. Our application is >data-mining and data-visualisation, where much of the actual information is >encoded in concrete data types. In particular, it would be helpful to have: > > inverseFunctional: the value of the datatype uniquely identifies the >individual > > I agree this is very helpful. There are already algorithms proposed to handle inverse functional datatype properties, a.k.a. keys, in DLs. For example, see [1] that describes a tableau algorithm for SHOQK(D). Actually [1] considers much more expressive ways of describing keys and IFDP is just a special case. Howeer, even for this special case, there are some problems that need to be solved in order to have an efficient implementation. I have implemented a preliminary version of IFDP support in Pellet but this is still work in progress. > inverseDatatypeProperty: a property from datatype to individual, allowing us >to say things like: give me all the values of the hasAge property > > I'm not sure if inverse datatype properties are needed for this purpose. I would argue it is enough just to have a feature in the query language. If you want to get the values of hasAge property you can write a query in your (or your reasoner's) favorite query language (SPARQL, DIG or nRQL). Each of these languages have features to ask for the values of datatype properties. For example, in SPARQL you would simply write {?person hasAge ?age}. > datatypeProperty( ... hasInverse inverseDatatypePropertyID) > inverseDatatypeProperty( ... hasInverse datypePropertyID ) > > >Assuming that you could only invert datatypeProperties that refer to concrete >datatypes with an equivalence relation, > I'm probably missing the use case here. Is there something that the query language would not let you to do? >would this make the reasoners choke? > > > I can talk about my experience about implementing IFDP support. For most of the cases, e.g. FOAF data that heavily uses IFDP, reasoning is not affected much because the ontology itself is not very expressive. But it is easy to come up with use cases that will use IFDP in complex ways and that can kill the performance. But I believe it is possible (and we are working on) to devise more sophisticated optimizations for such cases Regards, Evren [1] Carsten Lutz, Carlos Areces, Ian Horrocks, and Ulrike Sattler. Keys, nominals, and concrete domains. /J. of Artificial Intelligence Research/, 23:667-726, 2004. (http://www.cs.man.ac.uk/~horrocks/Publications/#LAHS04a) >Matthew >_______________________________________________ >OWL mailing list >OWL at lists.mindswap.org >http://lists.mindswap.org/mailman/listinfo/owl > > > > -- Evren Sirin evren at cs.umd.edu Graduate Research Assistant Computer Science Department Univ of Maryland, College Park, MD 20742 Phone: (301) 405-7027, Fax: (301) 405-6707 From horrocks at cs.man.ac.uk Mon Feb 27 16:46:46 2006 From: horrocks at cs.man.ac.uk (Ian Horrocks) Date: Mon, 27 Feb 2006 21:46:46 +0000 Subject: [OWL] inverse datatype properties In-Reply-To: <4403488B.8030109@cs.umd.edu> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> Message-ID: <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> On 27 Feb 2006, at 18:44, Evren Sirin wrote: > Matthew Pocock wrote: > >> Hi, >> >> When representing actual data in OWL (rather than individual-graphs), >> I keep >> needing datatype properties to be more expressive. Our application is >> data-mining and data-visualisation, where much of the actual >> information is >> encoded in concrete data types. In particular, it would be helpful to >> have: >> >> inverseFunctional: the value of the datatype uniquely identifies the >> individual >> >> > I agree this is very helpful. There are already algorithms proposed to > handle inverse functional datatype properties, a.k.a. keys, in DLs. For > example, see [1] that describes a tableau algorithm for SHOQK(D). Just to explicate what is implicit in Evren's reply: it is easy to show (see [1]) that, in the general case, allowing inverse functional datatype properties would lead to undecidability (of OWL). Ian > Actually [1] considers much more expressive ways of describing keys and > IFDP is just a special case. Howeer, even for this special case, there > are some problems that need to be solved in order to have an efficient > implementation. I have implemented a preliminary version of IFDP > support > in Pellet but this is still work in progress. > >> inverseDatatypeProperty: a property from datatype to individual, >> allowing us >> to say things like: give me all the values of the hasAge property >> >> > I'm not sure if inverse datatype properties are needed for this > purpose. > I would argue it is enough just to have a feature in the query > language. > If you want to get the values of hasAge property you can write a query > in your (or your reasoner's) favorite query language (SPARQL, DIG or > nRQL). Each of these languages have features to ask for the values of > datatype properties. For example, in SPARQL you would simply write > {?person hasAge ?age}. > >> datatypeProperty( ... hasInverse inverseDatatypePropertyID) >> inverseDatatypeProperty( ... hasInverse datypePropertyID ) >> >> >> Assuming that you could only invert datatypeProperties that refer to >> concrete >> datatypes with an equivalence relation, >> > I'm probably missing the use case here. Is there something that the > query language would not let you to do? > >> would this make the reasoners choke? >> >> >> > I can talk about my experience about implementing IFDP support. For > most > of the cases, e.g. FOAF data that heavily uses IFDP, reasoning is not > affected much because the ontology itself is not very expressive. But > it is easy to come up with use cases that will use IFDP in complex ways > and that can kill the performance. But I believe it is possible (and we > are working on) to devise more sophisticated optimizations for such > cases > > Regards, > Evren > > [1] Carsten Lutz, Carlos Areces, Ian Horrocks, and Ulrike Sattler. > Keys, > nominals, and concrete domains. /J. of Artificial Intelligence > Research/, 23:667-726, 2004. > (http://www.cs.man.ac.uk/~horrocks/Publications/#LAHS04a) > >> Matthew >> _______________________________________________ >> OWL mailing list >> OWL at lists.mindswap.org >> http://lists.mindswap.org/mailman/listinfo/owl >> >> >> >> > > > -- > Evren Sirin evren at cs.umd.edu > Graduate Research Assistant > Computer Science Department > Univ of Maryland, College Park, MD 20742 > Phone: (301) 405-7027, Fax: (301) 405-6707 > > > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl From bparsia at isr.umd.edu Mon Feb 27 22:33:28 2006 From: bparsia at isr.umd.edu (Bijan Parsia) Date: Mon, 27 Feb 2006 22:33:28 -0500 Subject: [OWL] More fragments Message-ID: <3111d9fd0afc011e6cf8aefebf294249@isr.umd.edu> I realize that we don't have the ter Horst fragments (which mostly aren't directly fragments of OWL DL, but might be worth including for completeness in their DLized form). See: http://www.ontotext.com/inference/rdfs_rules_owl.html Cheers, Bijan. From alanr at mumble.net Tue Feb 28 00:18:46 2006 From: alanr at mumble.net (Alan Ruttenberg) Date: Tue, 28 Feb 2006 00:18:46 -0500 Subject: [OWL] inverse datatype properties In-Reply-To: <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> Message-ID: <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> Hi Ian, I wonder if you could answer a question about this? I've looked at the paper, but understanding it will take more time than I can devote to it now. And despite some earlier conversations with some others, I still can't get my head around this result. I'm trying to understand the definitions at least. Would allowing a datatypeProperty with range xsd:string in the current OWL to be inverseFunctional, correspond to - path free (no role composition in OWL 1.0) - unary (no way to express composite key) - only predicate is =x corresponding to hasValue And would this cause undecidability or drastic worsening of complexity? Something seemingly equivalent can be accomplished by - a trivial translation of all the strings to an owl:Thing with URI constructed from the string, - an assertion of allDifferent on the resultant set of URIs, - a recasting of the property as an objectProperty with the values being the transformed URI. In the transformation above, the only thing which seems to differ from OWL is the allDifferent, so if I have the inverseFunctional on xsd:string with restrictions stated correctly above, and it does lead to undecidability, then it would have to be due to the allDifferent. And if so, is there some intuitive example that would make that result easier to understand (than fully understanding the cited paper?) Thanks, Alan On Feb 27, 2006, at 4:46 PM, Ian Horrocks wrote: > Just to explicate what is implicit in Evren's reply: it is easy to > show > (see [1]) that, in the general case, allowing inverse functional > datatype properties would lead to undecidability (of OWL). > > Ian From horrocks at cs.man.ac.uk Tue Feb 28 01:47:15 2006 From: horrocks at cs.man.ac.uk (Ian Horrocks) Date: Tue, 28 Feb 2006 06:47:15 +0000 Subject: [OWL] inverse datatype properties In-Reply-To: <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> Message-ID: <6ccd652460ecdecfea821424457b4fbb@cs.man.ac.uk> On 27 Feb 2006, at 21:46, Ian Horrocks wrote: > On 27 Feb 2006, at 18:44, Evren Sirin wrote: > >> Matthew Pocock wrote: >> >>> Hi, >>> >>> When representing actual data in OWL (rather than >>> individual-graphs), I keep >>> needing datatype properties to be more expressive. Our application is >>> data-mining and data-visualisation, where much of the actual >>> information is >>> encoded in concrete data types. In particular, it would be helpful >>> to have: >>> >>> inverseFunctional: the value of the datatype uniquely identifies the >>> individual >>> >>> >> I agree this is very helpful. There are already algorithms proposed to >> handle inverse functional datatype properties, a.k.a. keys, in DLs. >> For >> example, see [1] that describes a tableau algorithm for SHOQK(D). > > Just to explicate what is implicit in Evren's reply: it is easy to > show (see [1]) that, in the general case, allowing inverse functional > datatype properties would lead to undecidability (of OWL). Oops - I just realised that the above statement is not correct. Of course the undecidability results in [1] depend on the use of concrete domains, which are more expressive than the very simple datatypes provided by OWL. In fact OWL's datatypes can be simulated using nominals, so allowing inverse functional datatype properties would be harmless from a theoretical perspective. The argument for not supporting inverse functional datatype properties in OWL was a pragmatic one based on the difficulty of providing "practical" reasoning services (see http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.1-Uniform- treatment-of-literal-data-values). Sorry for the confusion. Ian > > Ian > > >> Actually [1] considers much more expressive ways of describing keys >> and >> IFDP is just a special case. Howeer, even for this special case, there >> are some problems that need to be solved in order to have an efficient >> implementation. I have implemented a preliminary version of IFDP >> support >> in Pellet but this is still work in progress. >> >>> inverseDatatypeProperty: a property from datatype to individual, >>> allowing us >>> to say things like: give me all the values of the hasAge property >>> >>> >> I'm not sure if inverse datatype properties are needed for this >> purpose. >> I would argue it is enough just to have a feature in the query >> language. >> If you want to get the values of hasAge property you can write a query >> in your (or your reasoner's) favorite query language (SPARQL, DIG or >> nRQL). Each of these languages have features to ask for the values of >> datatype properties. For example, in SPARQL you would simply write >> {?person hasAge ?age}. >> >>> datatypeProperty( ... hasInverse inverseDatatypePropertyID) >>> inverseDatatypeProperty( ... hasInverse datypePropertyID ) >>> >>> >>> Assuming that you could only invert datatypeProperties that refer to >>> concrete >>> datatypes with an equivalence relation, >>> >> I'm probably missing the use case here. Is there something that the >> query language would not let you to do? >> >>> would this make the reasoners choke? >>> >>> >>> >> I can talk about my experience about implementing IFDP support. For >> most >> of the cases, e.g. FOAF data that heavily uses IFDP, reasoning is not >> affected much because the ontology itself is not very expressive. But >> it is easy to come up with use cases that will use IFDP in complex >> ways >> and that can kill the performance. But I believe it is possible (and >> we >> are working on) to devise more sophisticated optimizations for such >> cases >> >> Regards, >> Evren >> >> [1] Carsten Lutz, Carlos Areces, Ian Horrocks, and Ulrike Sattler. >> Keys, >> nominals, and concrete domains. /J. of Artificial Intelligence >> Research/, 23:667-726, 2004. >> (http://www.cs.man.ac.uk/~horrocks/Publications/#LAHS04a) >> >>> Matthew >>> _______________________________________________ >>> OWL mailing list >>> OWL at lists.mindswap.org >>> http://lists.mindswap.org/mailman/listinfo/owl >>> >>> >>> >>> >> >> >> -- >> Evren Sirin evren at cs.umd.edu >> Graduate Research Assistant >> Computer Science Department >> Univ of Maryland, College Park, MD 20742 >> Phone: (301) 405-7027, Fax: (301) 405-6707 >> >> >> _______________________________________________ >> OWL mailing list >> OWL at lists.mindswap.org >> http://lists.mindswap.org/mailman/listinfo/owl > From alanruttenberg at gmail.com Tue Feb 28 02:13:54 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Tue, 28 Feb 2006 02:13:54 -0500 Subject: [OWL] inverse datatype properties In-Reply-To: <6ccd652460ecdecfea821424457b4fbb@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> <6ccd652460ecdecfea821424457b4fbb@cs.man.ac.uk> Message-ID: <349A5727-ADAC-4F28-848D-954AC5CD06A7@gmail.com> In the context of the current OWL, does the problem only occur for datatypes with finite cardinality? If so, could we not unproblematically permit inversefunctional for datatypes whose values are countably infinite? -Alan On Feb 28, 2006, at 1:47 AM, Ian Horrocks wrote: > The argument for not > supporting inverse functional datatype properties in OWL was a > pragmatic one based on the difficulty of providing "practical" > reasoning services (see > http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.1-Uniform- > treatment-of-literal-data-values). From Ulrike.Sattler at manchester.ac.uk Tue Feb 28 03:29:11 2006 From: Ulrike.Sattler at manchester.ac.uk (Ulrike Sattler) Date: Tue, 28 Feb 2006 09:29:11 +0100 Subject: [OWL] inverse datatype properties In-Reply-To: <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> Message-ID: <29C0C99F-43A7-4DF4-9786-52EF777D0008@cs.man.ac.uk> On 28 Feb 2006, at 06:18, Alan Ruttenberg wrote: > Hi Ian, > > I wonder if you could answer a question about this? I've looked at > the paper, but understanding it will take more time than I can devote > to it now. And despite some earlier conversations with some others, I > still can't get my head around this result. > > I'm trying to understand the definitions at least. Would allowing a > datatypeProperty with range xsd:string in the current OWL to be > inverseFunctional, correspond to > > - path free (no role composition in OWL 1.0) > - unary (no way to express composite key) > - only predicate is =x corresponding to hasValue > > And would this cause undecidability or drastic worsening of > complexity? > the only thing we know is that - declaring a single datatype property as a key (ie, saying that it is inverse functional) and with n-ary datatype predicates might lead to a harsh complexity blow-up. I also believe that, for inverse functional datatype properties, we would need to re-engineer our whole approach to reasoning with datatypes, and that it might take a while before somebody comes up with a neat way of doing this. > Something seemingly equivalent can be accomplished by > > - a trivial translation of all the strings to an owl:Thing with URI > constructed from the string, > - an assertion of allDifferent on the resultant set of URIs, > - a recasting of the property as an objectProperty with the values > being the transformed URI. > > In the transformation above, the only thing which seems to differ > from OWL is the allDifferent, so if I have the inverseFunctional on > xsd:string with restrictions stated correctly above, and it does lead > to undecidability, then it would have to be due to the allDifferent. > > And if so, is there some intuitive example that would make that > result easier to understand (than fully understanding the cited > paper?) ok, so imagine you have a datatype property "hasSocialSecurity", hss, with range MyInteger, and domain Citizen. Now, you can make Citizen a subclass of Human, and can enforce an infinite "chain" of humans using standard OWL constructs, ie, a human and all its ancestors---and you can make sure that this chain is infinite. Now it depends on the size of MyInteger whether the resulting ontology is consistent or not....if it's infinite, then it's consistent, other inconsistent. This is the easy case -- imagine, if only adult Citizen need to have a social security number...or when they are employed/have a permanent job, etc. ...all sorts of things that mean that only some Citizens need to have a social security number...I can't think of a "practicable" way of reasoning in this case, and I wouldn't be surprised* if it turned out that, for certain (surprisingly simple) datatypes, such an extension is undecidable. The "way out" using "we use a datatype with an infinite domain" doesn't help, either (or perhaps only with severest syntactic restrictions): you might use comparisons (such as "Humans of kind C have a social security number above/below x) to make it finite, and this might be quite tricky to spot. If I remember your use case for this correctly, then you might want to consider using DL-safe rules for this: x \neq y :- hss(x,n), hss(y,n) This will make sure that all individuals in your ABox have different social security numbers.... Sorry that I can't be more precise here, cheers, Uli PS: please note the careful phrasing! > > Thanks, > Alan > > On Feb 27, 2006, at 4:46 PM, Ian Horrocks wrote: > >> Just to explicate what is implicit in Evren's reply: it is easy to >> show >> (see [1]) that, in the general case, allowing inverse functional >> datatype properties would lead to undecidability (of OWL). >> >> Ian > > _______________________________________________ > OWL mailing list > OWL at lists.mindswap.org > http://lists.mindswap.org/mailman/listinfo/owl From matthew.pocock at ncl.ac.uk Tue Feb 28 03:59:57 2006 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Tue, 28 Feb 2006 08:59:57 +0000 Subject: [OWL] inverse datatype properties In-Reply-To: <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> Message-ID: <200602280859.57870.matthew.pocock@ncl.ac.uk> > > I agree this is very helpful. There are already algorithms proposed to > > handle inverse functional datatype properties, a.k.a. keys, in DLs. For > > example, see [1] that describes a tableau algorithm for SHOQK(D). > > Just to explicate what is implicit in Evren's reply: it is easy to show > (see [1]) that, in the general case, allowing inverse functional > datatype properties would lead to undecidability (of OWL). > > Ian Thanks. Still a bit new to all this owl stuff. Matthew From Ulrike.Sattler at manchester.ac.uk Tue Feb 28 05:03:07 2006 From: Ulrike.Sattler at manchester.ac.uk (Ulrike Sattler) Date: Tue, 28 Feb 2006 11:03:07 +0100 Subject: [OWL] inverse datatype properties In-Reply-To: <8677e2ccc971462804f8da1299f973d7@isr.umd.edu> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> <29C0C99F-43A7-4DF4-9786-52EF777D0008@cs.man.ac.uk> <8677e2ccc971462804f8da1299f973d7@isr.umd.edu> Message-ID: <1963044C-1B62-4DBD-8C96-9D81A9582980@cs.man.ac.uk> > >> If I remember your use case for this correctly, then you might >> want to >> consider using DL-safe rules for this: >> >> x \neq y :- hss(x,n), hss(y,n) >> ououops --- this happens when you try to write rules before noon...it should be x=y :- hss(x,n), hss(y,n) Sorry for the confusion! >> This will make sure that all individuals in your ABox have >> different social security numbers.... From hitzler at aifb.uni-karlsruhe.de Tue Feb 28 05:23:17 2006 From: hitzler at aifb.uni-karlsruhe.de (Pascal Hitzler) Date: Tue, 28 Feb 2006 11:23:17 +0100 Subject: [OWL] OWLED06 preliminary CfP In-Reply-To: <1963044C-1B62-4DBD-8C96-9D81A9582980@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> <29C0C99F-43A7-4DF4-9786-52EF777D0008@cs.man.ac.uk> <8677e2ccc971462804f8da1299f973d7@isr.umd.edu> <1963044C-1B62-4DBD-8C96-9D81A9582980@cs.man.ac.uk> Message-ID: <44042495.3020603@aifb.uni-karlsruhe.de> OWL: EXPERIENCES AND DIRECTIONS Second International Workshop Athens, GA, USA, 10-11 November 2006 Co-located with ISWC06 and RuleML06. http://owl-workshop.man.ac.uk/OWLWorkshop06.html Summary ------- Submissions due: 31st of July, 2006 Notification of acceptance: 11th of September, 2006 Final versions due: 9th of October, 2006 Workshop: 10-11th of November, 2006 Workshop proceedings will be published online. Preliminary Call for Papers --------------------------- The W3C OWL Web Ontology Language has been a W3C recommendation since 2004. OWL is playing an important role in an increasing number and range of applications, and is the focus of research into tools, reasoning techniques, formal foundations, language extensions etc. This level of experience with OWL means that the community is now in a good position to discuss how OWL be applied, adapted and extended to fulfill current and future application demands. The aim of the OWLED workshop series is to establish a forum for practitioners in industry and academia, tool developers, and others interested in OWL to describe real and potential applications, to share experience, and to discuss requirements for language extensions/modifications. The workshop will bring users, implementors and researchers together to measure the state of need against the state of the art, and to set an agenda for research and deployment in order to incorporate OWL-based technologies into new applications. Topics of interest include, but are not limited to the following: - Applications of and experience with OWL - Application-driven requirements for OWL - Performance and scalability issues - Extensions to OWL, including - non-monotonic extensions - rules extensions - extensions for representing temporal and spatial information - extended property constructors - keys - extended class constructors - extended datatype constructors - probabilistic and fuzzy Extensions - Implementation techniques for OWL and related languages - Reasoning-related tasks for OWL, including explanation - Security and Trust for OWL-based information - Tools for OWL, including - editors - visualisation tools - parsers and syntax checkers - versioning frameworks - OWL based Semantic Web Service frameworks Characteristics of OWLED06 -------------------------- The 2006 OWLED workshop shall in particular - further the interaction between theoreticians, tool builders, and implementors; - help consolidating OWL 1.1; - initiate the development of OWL 2.0; and - aid in clarifying the relationships between OWL and rules. For OWLED06, we particularly encourage submissions on any of the following topics: - Experiences with OWL 1.1 - Implementation issues with OWL 1.1 - Demos of OWL 1.1 implementations - Requirements for a potential OWL 2.0 revision - Modeling and reasoning with OWL and rules - Survey papers - System descriptions Submissions can be either technical papers or short "position" papers. Submissions that base their conclusions on application experience are especially encouraged. Workshop Format --------------- The goal of the workshop will be to maximise discussion. The technical sessions will therefore consist of short presentations of papers (grouped by topic area) followed by directed discussion. Further presentations and system demonstrations will be made as part of a poster session. The workshop may also have one session in common with the Second International Conference on Rules and Rule Markup Languages for the Semantic Web (RuleML06) in which the integration of OWL with rules languages will be discussed. Submission details ------------------ Technical paper submissions must be no longer than 10 pages, and shorter submissions are welcome. Position paper submissions must be no longer than 4 pages. Submission will be via the workshop web site. Submissions must be formatted in the style of the Springer Publications format for Lecture Notes in Computer Science (LNCS). For details see the OWLED06 workshop website. Submissions must be in PDF, and will not be accepted in any other format. It is the responsibility of the authors to ensure that their submission displays and prints correctly on common PDF viewers. All relevant submissions will be made available from the workshop web site; these may be updated with final versions after the reviewing process. Presentation materials from the workshop will also be placed on the web site. Reviewing and Participation --------------------------- All submissions will be reviewed by the programme committee. Authors of accepted papers plus programme committee members will be invited to participate in the workshop. Authors who need invitations before the notification date should send a message to the workshop committee at owl-ws-organizers at mindswap.org indicating why they need an advance invitation and provide their qualifications to receive an invitation. Applications from other interested parties will be considered after submission-based invitations have been extended, but numbers will be strictly limited. Steering Committee ------------------ Ian Horrocks, University of Manchester (UK) Bijan Parsia, University of Maryland (USA) Peter Patel-Schneider, Bell Labs (USA) Workshop Organising Committee ----------------------------- Bernardo Cuenca Grau, University of Manchester (UK) Pascal Hitzler, AIFB, University of Karlsruhe (Germany) Conor Shankey, Visual Knowledge Software Inc. (USA) Evan Wallace, NIST (USA) Programme Committee ------------------- Dean Allemang, TopQuadrant (USA) Michael Champion, Microsoft (USA) Kendall Clark, University of Maryland (USA) Giuseppe DeGiacomo, Universita di Roma ``La Sapienza'' (Italy) Nick Gibbins, University of Southampton (UK) Jennifer Golbeck, University of Maryland (USA) Christine Golbreich, University Rennes 2 (France) Volker Haarslev, Concordia University (Canada) Joanne Luciano, Harvard Medical School (USA) Carsten Lutz, TU Dresden (Germany) Ashok Malhotra, Oracle (USA) Massimo Marchiori, W3C at MIT (USA) Boris Motik, University of Manchester (UK) Enrico Motta, Open University (UK) Ryusuke Masuoka, Fujitsu Laboratories of America (USA) Gary Ng, Cerebra (USA) Natasha Noy, Stanford University (USA) Bijan Parsia, University of Maryland (USA) Terry Payne, University of Southampton (UK) Alan Ruttenberg, Millennium Pharmaceuticals, (USA) Riccardo Rosati, Universita di Roma ``La Sapienza'' (Italy) Ulrike Sattler, University of Manchester (UK) Andrew Schain, NASA (USA) Guus Schreiber, Vrije Universitat Amsterdam (Netherlands) Valentina Tamma, University of Liverpool (UK) Sergio Tessaris, Free University of Bolzano (Italy) -- Dr. habil. Pascal Hitzler Institute AIFB, University of Karlsruhe, 76128 Karlsruhe email: hitzler at aifb.uni-karlsruhe.de fax: +49 721 608 6580 web: http://www.pascal-hitzler.de phone: +49 721 608 4751 http://www.neural-symbolic.org From alanruttenberg at gmail.com Tue Feb 28 21:16:28 2006 From: alanruttenberg at gmail.com (Alan Ruttenberg) Date: Tue, 28 Feb 2006 21:16:28 -0500 Subject: [OWL] inverse datatype properties In-Reply-To: <29C0C99F-43A7-4DF4-9786-52EF777D0008@cs.man.ac.uk> References: <200602271758.23062.matthew.pocock@ncl.ac.uk> <4403488B.8030109@cs.umd.edu> <7785df8913fa9d4d6b6d9c359caf48c4@cs.man.ac.uk> <6A3DECE7-6C0A-4649-BABE-35588EDB4C34@mumble.net> <29C0C99F-43A7-4DF4-9786-52EF777D0008@cs.man.ac.uk> Message-ID: Hi Uli (aka "others") Thanks, this is helpful. To make sure I understand, the answer is that it's unknown whether adding inverseFunctional datatype properties, even in there are no predicates other than = and if the datatype has an infinite domain, is decidable. On Feb 28, 2006, at 3:29 AM, Ulrike Sattler wrote: > ok, so imagine you have a datatype property "hasSocialSecurity", hss, > with range MyInteger, and domain Citizen. > > Now, you can make Citizen a subclass of Human, and can enforce > an infinite "chain" of humans using standard OWL constructs, ie, a > human > and all its ancestors---and you can make sure that this chain is > infinite. How does make sure the chain is infinite? I started to write this up; human, subclass of restriction parent some human then got stuck trying to figure out how to force (parent of x) not equal x. > Now it depends on the size of MyInteger whether the resulting ontology > is consistent or not....if it's infinite, then it's consistent, > other inconsistent. Nice. > This is the easy case -- imagine, if only adult Citizen need to have a > social security number...or when they are employed/have a permanent > job, etc. ...all sorts of things that mean that only some Citizens > need to have a social security number...I can't think of a > "practicable" way of > reasoning in this case, and I wouldn't be surprised* if it turned > out that, for > certain (surprisingly simple) datatypes, such an extension is > undecidable. Ok, I understand the problem when the range is finite, at least. > The "way out" using "we use a datatype with an infinite domain" > doesn't > help, either (or perhaps only with severest syntactic > restrictions): you > might use comparisons (such as "Humans of kind C have a social > security > number above/below x) to make it finite, and this might be quite > tricky to spot. Not an issue in OWL 1.0, since no way to say above/below. But I can see the problem in 1.1+ > If I remember your use case for this correctly, then you might want to > consider using DL-safe rules for this: > > x = y :- hss(x,n), hss(y,n) > > This will make sure that all individuals in your ABox have > different social security numbers.... Working on it. In Pellet, where I've been working, the rules don't yet support SameIndividual as consequent. Just downloaded KAON2 and will have a look at that. Other suggestions for rule engine are welcome. -Alan