Of Evidence and Individuals (Was Plea for competency questions)
Hi All,
I, too, am just back from an extended trip with limited internet access, and am catching up on this discussion.
I think Steve's two recent posts are extremely helpful -- for me in particular. I very-much like the way he's framed the discussion around "competency questions" (however correctly the term is applied).
I started off giving a detailed reply to the "Individual" (="BiologicalEntity") class post, but then decided to read through the "Evidence" post as well; and this lead me to deleting everything I had written and start from scratch.
In summary, I largely agree with most of what Steve says in both posts, but I'm still more than a little bit nervous about the distinction between the two new proposed classes. In particular, this passage from Steve's post about the "Evidence" (="CollectionObject") class freaks me out a little bit:
So then what IS an actual individual organism like the wildebeest calf? It is a BiologicalEntity if it has been documented as an Occurrence or assigned an Identification. It is a CollectionObject if it was collected for a zoo, or shot and mounted in a museum. Or it can be both simultaneously if it is both documented and collected. If none of these things were done, then it's neither a BiologicalEntity nor a CollectionObject - it's simply a wildebeest calf. Define the class/type of the thing by the properties that you wish to assert for it (or the competency questions that you can answer for it).
I think I get where you are coming from here, but I'm very queasy about this notion that the same "thing" (a mass of flesh & bones) can be represented as an instance of two different DwC classes, depending merely on what attributes about the "thing" are emphasized. For example, during my recent trip to South Africa, we took the opportunity of one of our non-diving days to visit a game park where we saw (among other things), numerous wildebeest (coincidentally enough). I took video images of these wildebeest with my GPS-enabled camera, and therefore documented the presence of a specific individual wildebeest at a particular date and time. Clearly there is a dwc:Occurrence record there, so it's certainly a BiologicalEntity (by your definition; i.e., documented as an Occurrence and assigned an Identification). But does a Game Park constitute the same thing as a zoo? There are electric fences around the perimeter of the park, so I'm inclined to think so. Is it also a CollectionObject? Would this be an example of something that is both?
The more I think about it, the less confident I am that we really need *both* new classes. With such potential overlap between them, should we not simply generalize them both into the same class, and provide whatever properties are known/relevant in a DwC instance of it?
You said that the CollectionObject class is fully capable of doing much of what I want to accomplish with my vision of "Individual". Could I not say the exact same thing that a broader definition of CollectionObject (i.e., one that doesn't attempt to distinguish the disposition of the same mass of flesh & bones in the context of human-mitigated captivity/preservation vs. nature) could be fully capable of accomplishing what you want to accomplish with Individual? Namely, the three competency questions you established for the "Individual" (=BiologicalEntity) class.
An actual single, live organism can serve both as a unit for resampling and "attachment" of Identifications, AND as an organizational unit that is part of and which has parts that are biological samples. Some other entities, such as cohesive pack/herds and clonal organisms can also serve both purposes. Other entities cannot: it doesn't make sense to resample dead organisms or pieces of organisms,
I guess it depends on what you mean by "resample". Surely a tissue sample can be removed from a dead organism, and used for DNA sequencing that can lead to a new Identification instance. I agree that a dead organism cannot represent the basis for future Occurrence instances, but I don't really see the relevance of that.
Personally, I would like for the third function ("inferring duplicates"; linking multiple Identifications to the same entity and being assured that all Identifications of the same Individual would apply to all artifacts associated with that Individual) to be accommodated by the definition,
I definitely support this, and on this basis, I am willing to abandon my earlier defense for what you would call taxonomic heterogeneity. I still feel the need to not limit the rank at which a taxon identification may be applied, but I am ready to abandon my original notion that a rock with multiple phyla of organism attached should ever be represented as a single instance with Identification "Animalia". In other words, I've come around to your perspective on this. I think the power of implied "taxon identification inheritance" that you advocate in your function #3 overrides my advocacy for taxonomically heterogenous organisms to be lumped together with the same instance of the class.
Thus, I now agree with you on the following:
When I used that term, I intended for it to mean that the entity is believed to be homogeneous to the lowest possible level in the way that one knows that two branches from the same tree or two parts of the same clonal organism are guaranteed to have the same taxonomic
identify at every level.
So, from my perspective, we can put that part of the debate to rest.
This email is now at or has exceeded the length of an email that many people will take the time to read. So I will draw it to a close and post a separate email on the topic of competency questions for John's proposed class "CollectionObject" which I believe address Rich's desire to track "real-world" objects (samples, re-samples, etc.).
Rather than respond separately to the other post, I've just made this single response with the new subject heading, because I think we're narrowing down the scope of the debate in such a way that we should now focus on the difference between the two proposed new classes ("Individual"/"BiologicalEntity", and "Evidence"/"CollectionObject").
For a while, I thought I saw the difference as being the "Evidence" was more like an instance of "Documentation" (e.g., an image, a label on a preserved specimen, etc.); rather than the flesh-and-bones organism itself. But with your suggestion that this class may serve the function(s) of my desires for the "Individual" class, the waters have been muddied a bit in my own mind.
I guess if there are to be two separate classes, then I would favor a more generalized "Organism" class to serve the functions of what Steve has described for both the "CollectionObject" and "BiologicalEntity" classes, but then define a separate "Documentation" class that serves as the basis of "proof" for an Occurrence.
On a semi-related topic, I don't think it's appropriate to create a DwC class simply to establish a Many-to-Many relationship between instances of other classes. That function (in my mind) is already elegantly fulfilled by the existing dwc:ResourceRelationship class (another major discussion that will need to take place on this list). While it's true that certain DwC classes do serve a M:M function (e.g., Occurrence), I think that classes should represent "things" that are unambiguously different, with very specific sets of properties.
On a final, somewhat encouraging note, I *really* like the diagram represented in the link that Cam sent earlier:
http://code.google.com/p/darwin-sw/
During one of our non-diving days in South Africa, Rob Whitton and I spent some time thinking about the BiSciCol project (BCC'd on this post), and we studied this diagram and both agreed it represents an *excellent* foundation to both this discussion on proposed new DwC classes, and the BiSciCol project in particular.
Aloha, Rich
On Tue, Jul 26, 2011 at 7:08 PM, Richard Pyle deepreef@bishopmuseum.org wrote:
Hi All,
[...]
When I used that term, I intended for it to mean that the entity is believed to be homogeneous to the lowest possible level in the way that one knows that two branches from the same tree or two parts of the same clonal organism are guaranteed to have the same taxonomic identify at every level.
So, from my perspective, we can put that part of the debate to rest.
As long as you don't invite Craig Ventner to the debate. :-)
--Bob
Robert A. Morris
Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Department of Organismal and Evolutionary Biology Harvard University
email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)
Responses inline.
Richard Pyle wrote:
So then what IS an actual individual organism like the wildebeest calf? It is a BiologicalEntity if it has been documented as an Occurrence or assigned an Identification. It is a CollectionObject if it was collected for a zoo, or shot and mounted in a museum. Or it can be both simultaneously if it is both documented and collected. If none of these things were done, then it's neither a BiologicalEntity nor a CollectionObject - it's simply a wildebeest calf. Define the class/type of the thing by the properties that you wish to assert for it (or the competency questions that you can answer for it).
I think I get where you are coming from here, but I'm very queasy about this notion that the same "thing" (a mass of flesh & bones) can be represented as an instance of two different DwC classes, depending merely on what attributes about the "thing" are emphasized.
Well, I have to say I had a problem with this at first. Because most of the existing classes in Darwin Core are disjoint with other classes (as in http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DisjointClasses), I was predisposed to thinking that it was "bad" to have two classes that were not mutually exclusive. But actually we have such classes all the time. A person can be a member of the class Father, class Teacher, and class ElectedOfficial depending on which set of properties we can appropriately apply to that person. In fact, most of the things that we could consider as "evidence" (i.e. instances of the proposed class CollectionObject) could probably be members of other classes as well, such as foaf:Image, foaf:Document, acterms:MultiMediaObject, etc. An image could be an instance of dwc:CollectionObject because it had properties such as dwc:catalogNumber and dwc:collectionCode that it shares with other types of CollectionObjects while at the same time being a acterms:MultiMediaObject because it has properties like dcterms:format, xmpRights:UsageTerms, Iptc4xmpExt:creditLine that it shares with other types of MultiMediaObjects. There isn't anything wrong with that as far as I know, other than getting used to the idea.
For example, during my recent trip to South Africa, we took the opportunity of one of our non-diving days to visit a game park where we saw (among other things), numerous wildebeest (coincidentally enough). I took video images of these wildebeest with my GPS-enabled camera, and therefore documented the presence of a specific individual wildebeest at a particular date and time. Clearly there is a dwc:Occurrence record there, so it's certainly a BiologicalEntity (by your definition; i.e., documented as an Occurrence and assigned an Identification). But does a Game Park constitute the same thing as a zoo? There are electric fences around the perimeter of the park, so I'm inclined to think so. Is it also a CollectionObject? Would this be an example of something that is both?
Well, I've thought about this question quite a bit. My opinion is that the wildebeest you photographed would not be a CollectionObject. It seems to me that implicit in the idea of a CollectionObject is an understanding that someone is "keeping track" of the object and that there is a reasonable expectation that the particular object could be produced at will (or at least accounted for if it no longer exists in the collection). That's what we are doing when we assign catalogNumbers to things, put them in particular pens, jars, or cabinets, and keep track of their dwc:disposition. If the game park were tracking that wildebeest by means of an ear tag, radio collar, unique color patterns, etc., assigned the wildebeest an identifying number, kept track of which electric fence unit the wildebeest was located in, and put this all in a database, then I would say the wildebeest was a CollectionObject that was a LivingSpecimen. If you could walk into the park office with the wildebeest's ID number and ask "what's going on with this wildebeest" and get an answer, it would be a CollectionObject. I really had to come to grips with this when thinking about the Bicentennial Oak at Vanderbilt. It is clearly a CollectionObject in the Vanderbilt Arboretum because it has an ID number, is on the arboretum's map, and has a record in the arboretum's database. But Vanderbilt didn't "do" anything physically to make it become a CollectionObject (i.e. didn't move or plant it - it was there long before the University). It became a CollectionObject of type LivingSpecimen when the arboretum started accounting for it by assigning it a catalogNumber and keeping track of its status in the collection. That's different from some other random bur oak that I happen across in the forest. Even if I assign it a GUID and record it's latitude and longitude, I'm not asserting to anybody that I will know what is going on with that tree or if it even continues to exist after I make a record of its Occurrence. It does NOT have a dwc:catalogNumber, dwc:collectionCode, or dwc:disposition because it isn't in a collection over which I assert control - it does not have properties in common with other CollectionObjects.
The more I think about it, the less confident I am that we really need *both* new classes. With such potential overlap between them, should we not simply generalize them both into the same class, and provide whatever properties are known/relevant in a DwC instance of it?
Well you could say this about any non-disjoint classes. Why not combine the classes Teacher and ElectedOfficial if a person can be an instance of both? We don't do that because there are instances where persons are Teachers and not ElectedOfficials and other instance where people are ElectedOfficials and not Teachers. Instances of the class Teacher share properties like numberOfStudents and schoolOfEmployment, while instances of ElectedOfficial share properties like votesReceived and yearElected.
You said that the CollectionObject class is fully capable of doing much of what I want to accomplish with my vision of "Individual". Could I not say the exact same thing that a broader definition of CollectionObject (i.e., one that doesn't attempt to distinguish the disposition of the same mass of flesh & bones in the context of human-mitigated captivity/preservation vs. nature) could be fully capable of accomplishing what you want to accomplish with Individual? Namely, the three competency questions you established for the "Individual" (=BiologicalEntity) class.
If we do as you have suggested here, we would limit CollectionObjects to individual organisms, their pieces, and aggregations that include them. That definition would not include all kinds of things which can serve as evidence (which I think is what John was suggesting in his proposal) because it would exclude Images, Sounds, and Documents. It actually would make sense to define a class of things for "biological material" that could include individual organisms, their pieces, and aggregations that include them. That class doesn't currently exist as far as I know. Perhaps it could be a superclass of LivingSpecimen, PreservedSpecimen, tissue sample, DNA sample, cell culture, herd, mixed flock, etc. and disjoint with other classes like Image and Document that could also serve as CollectionObjects. Whether that "biological material" class would be synonymous with BiologicalEntity would be a subject for discussion. Perhaps it does just boil down to the same thing.
An actual single, live organism can serve both as a unit for resampling and "attachment" of Identifications, AND as an organizational unit that is part of and which has parts that are biological samples. Some other entities, such as cohesive pack/herds and clonal organisms can also serve both purposes. Other entities cannot: it doesn't make sense to resample dead organisms or pieces of organisms,
I guess it depends on what you mean by "resample". Surely a tissue sample can be removed from a dead organism, and used for DNA sequencing that can lead to a new Identification instance. I agree that a dead organism cannot represent the basis for future Occurrence instances,
That's what I meant.
but I don't really see the relevance of that.
I guess it would depend on the agreed definition. If the BiologicalEntity class only needed to facilitate some of the three functions that I outlined, then it's not relevant whether the organism is dead or not (i.e. whether it could potentially be the subject of additional future Occurrence records). If it needs to always be capable of facilitating all three functions, then the entity would probably have to be alive. The most important thing to me is that we are clear about the definition.
Personally, I would like for the third function ("inferring duplicates"; linking multiple Identifications to the same entity and being assured that all Identifications of the same Individual would apply to all artifacts associated with that Individual) to be accommodated by the definition,
I definitely support this, and on this basis, I am willing to abandon my earlier defense for what you would call taxonomic heterogeneity. I still feel the need to not limit the rank at which a taxon identification may be applied, but I am ready to abandon my original notion that a rock with multiple phyla of organism attached should ever be represented as a single instance with Identification "Animalia". In other words, I've come around to your perspective on this. I think the power of implied "taxon identification inheritance" that you advocate in your function #3 overrides my advocacy for taxonomically heterogenous organisms to be lumped together with the same instance of the class.
Thus, I now agree with you on the following:
When I used that term, I intended for it to mean that the entity is believed to be homogeneous to the lowest possible level in the way that one knows that two branches from the same tree or two parts of the same clonal organism are guaranteed to have the same taxonomic
identify at every level.
So, from my perspective, we can put that part of the debate to rest.
OK, cool. I think that simplifies the matter considerably.
This email is now at or has exceeded the length of an email that many people will take the time to read. So I will draw it to a close and post a separate email on the topic of competency questions for John's proposed class "CollectionObject" which I believe address Rich's desire to track "real-world" objects (samples, re-samples, etc.).
Rather than respond separately to the other post, I've just made this single response with the new subject heading, because I think we're narrowing down the scope of the debate in such a way that we should now focus on the difference between the two proposed new classes ("Individual"/"BiologicalEntity", and "Evidence"/"CollectionObject").
For a while, I thought I saw the difference as being the "Evidence" was more like an instance of "Documentation" (e.g., an image, a label on a preserved specimen, etc.); rather than the flesh-and-bones organism itself. But with your suggestion that this class may serve the function(s) of my desires for the "Individual" class, the waters have been muddied a bit in my own mind.
I guess if there are to be two separate classes, then I would favor a more generalized "Organism" class to serve the functions of what Steve has described for both the "CollectionObject" and "BiologicalEntity" classes, but then define a separate "Documentation" class that serves as the basis of "proof" for an Occurrence.
I think there is probably more than one way of sorting this out. In my email I've suggested one method of defining the classes, which more or less corresponds to the approach Cam and I suggested with darwin-sw. This method is implemented on my website, e.g. for a particular tree in the UNC-Greensborough campus having GUID http://bioimages.vanderbilt.edu/uncg/39 Using the terminology of the current discussion, the tree is an instance of BiologicalEntity (called IndividualOrganism in darwin-sw). It's existence is documented by 17 instances of CollectionObject (called Tokens in darwin-sw): 15 that are StillImages, one that is a PreservedSpecimen in the NCU herbarium, and one that is a LivingSpecimen in the UNC-G arboretum (i.e. the tree itself). It would be painful to pick through the RDF (located in the files http://bioimages.vanderbilt.edu/uncg/39.rdf for the tree, http://bioimages.vanderbilt.edu/specimen/ncu592804.rdf for the specimen, http://bioimages.vanderbilt.edu/kirchoff/em2535.rdf and 14 other files for the 15 images) but suffice it to say that the BiologicalEntity (the tree) has the properties hasIdentification, hasOccurrence, foaf:depiction (relating it to the images), and dcterms:hasPart (relating it to the specimen) as would be expected based on the three "purposes" I outlined for BiologicalEntity. The 17 CollectionObjects have the properties dwc:institutionCode, dwc:collectionCode, dwc:catalogNumber, evidenceFor [an Occurrence], and derivedFrom [the BiologicalEntity] as would be expected based on how I described CollectionObject instances. Not all of these properties are from Darwin Core in part because DwC doesn't have any object properties relating the classes (we had to make those up). So what I would like to see is what particular properties (DwC and otherwise) would be held in common by instances of each of the two classes that Rich suggests: "Organism" and "Documentation".
On a semi-related topic, I don't think it's appropriate to create a DwC class simply to establish a Many-to-Many relationship between instances of other classes. That function (in my mind) is already elegantly fulfilled by the existing dwc:ResourceRelationship class (another major discussion that will need to take place on this list). While it's true that certain DwC classes do serve a M:M function (e.g., Occurrence), I think that classes should represent "things" that are unambiguously different, with very specific sets of properties.
Well, "many-to-many relationship" was the way Kevin described it and I liked that because it described succinctly the way that "Individual" fit into the "crow's feet" and block diagram that you included in http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001703.html and which I used as the basis for the Fully Normalized Model diagram at the bottom of http://code.google.com/p/darwin-sw/wiki/RelationshipToExistingModels . That doesn't mean that the class BiologicalEntity (a.k.a. "Individual" or dsw:IndividualOrganism) doesn't actually represent a real "thing". The BiologicalEntity instance that is the tree http://bioimages.vanderbilt.edu/uncg/39 is an actual "thing", not just an abstract database artifact. It just can have the relationships "one tree:many Occurrences" and "one tree:many Identifications". The same would be true of all BiologicalEntity instances which would have specific sets of properties that would differ from the specific properties of CollectionObjects as I outlined in the paragraph above.
On a final, somewhat encouraging note, I *really* like the diagram represented in the link that Cam sent earlier:
http://code.google.com/p/darwin-sw/
During one of our non-diving days in South Africa, Rob Whitton and I spent some time thinking about the BiSciCol project (BCC'd on this post), and we studied this diagram and both agreed it represents an *excellent* foundation to both this discussion on proposed new DwC classes, and the BiSciCol project in particular.
Cool! Go BiSciCol!
Steve
On Wed, Jul 27, 2011 at 12:52 AM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote:
[...] Well you could say this about any non-disjoint classes. Why not combine the classes Teacher and ElectedOfficial if a person can be an instance of both? We don't do that because there are instances where persons are Teachers and not ElectedOfficials and other instance where people are ElectedOfficials and not Teachers. Instances of the class Teacher share properties like numberOfStudents and schoolOfEmployment, while instances of ElectedOfficial share properties like votesReceived and yearElected.
OWL supports intersection and union. In OWL the set of things that are both a Teacher and an Elected Official would form a class. It would perhaps have fewer individuals in it than either class, but in OWL it is nevertheless a class. Similarly the set of things that are either a Teacher or an ElectedOfficial, though not necessarily both, is an OWL class. Note that http://code.google.com/p/darwin-sw/source/browse/trunk/dsw.owl is at this writing not an OWL ontology, as you will see if you try to put it into the Manchester OWL validator. Much of that failure is minor syntactic botches, but when you fix them, some issues remain about dsw's secondary goal to "(hopefully) making design choices that do not constrain full SW reasoning downstream".
RDFS does not guarantee that the intersection of two classes is a class, but allows you to avow that in particular cases if you wish, whereas OWL always requires it. More to the point, RDFS allows you to conceptually think of classes and properties as having the same kind of structure, so that you can effectively talk about intersecting properties, e.g. define a property that is true for those individuals for whom two particular properties are true. This is discussed on p. 135 of [1], though you won't like the word "infer" used there. Chapter 8 of [1] introduces a subset RDFS-Plus of OWL that is largely motivated by being content with the expressiveness of SPARQL, which I guess fits in your comfort zone, especially as to "AND". My understanding of LOD is that its community is indeed content with the expressiveness of SPARQL for now, and dsw probably corresponds to the approach of Chapter 8 in a way that meets your primary goals for dsw.
In summary, I suspect that you are struggling about modeling individuals because: a. You believe in your heart that there is a fundamental difference between properties and classes but b. RDFS does not require that of one's models and c. dsw is expressed in RDFS and not in a modeling language that requires you to abandon a.
[1] Dean Alemang and Jim Hendler "Semantic Web for the Working Ontologist", 2nd Edition 2011
Bob
I would like to clarify that although RDF files were mentioned in my previous post and although I've used some terms from the OWL world in my post, the discussion we are having is not about OWL or RDF. It's about addition of two classes to Darwin Core which is general-purpose and at the moment doesn't even have any sort of guidelines for its use in RDF. There has been a general criticism of the "Individual class" proposal that it doesn't really "do anything" that is beneficial to the community or that it cannot be defined in a way that makes it usable. The examples that I gave involved darwin-sw and my website because they aren't theoretical. They actually exist and (I believe) demonstrate that the classes CollectionObject and BiologicalEntity (or Token and IndividualOrganism) CAN actually serve a useful purpose. So at this point I would rather not let the discussion get distracted by the technical OWL and RDFS issues that Bob raises below - the discussion is about John's BiologicalEntity and CollectionObject term proposals, not technical problems with darwin-sw.
So keeping this on a general level, it is my understanding that classes in DwC do not have any formal relationship to the terms that are listed under them because DwC terms do not have ranges and domains. So what then are DwC classes for? To quote the DwC Quick Reference guide (http://rs.tdwg.org/dwc/terms/index.htm): "The terms are organized by categories (in bold) in the index. The categories correspond to Darwin Core terms that are classes (terms that have other terms to describe them). The terms that describe a given class (the class properties) appear in the list immediately below the name of the category in the index." It seems to me that our goal should be to have a DwC class for each type of basic "thing" that needs to be tracked in our community and that the terms listed under each class should truly "describe a given class" (i.e. actually be a property of instances of that class). Right now, I think there is a general consensus that there is a problem with the Occurrence class because not all of the properties under that class actually describe Occurrences the way we've been talking about them. John's proposal is one way to fix this problem. Is there a more sensible way to organize terms within classes that fit the resources we are tracking in our community? If so, then let's put it on the table.
It is my belief that if we fix some of the problems that have been discussed over the last couple years, the DwC classes could be rdfs:Class's and the terms listed under them in DwC could serve as rdf:Property's of instances of those classes. But that is not a necessity - one could just as easily say that the DwC classes are "things" that deserve their own table in a database and that the terms listed under that class are appropriate column headings in that table. Rich has made some suggestions for a different way to define the classes than what I suggested - that's great! If we had "Organism" and "Documentation" classes, what would be the column headings in database tables holding the metadata for resources in those classes? How would the page http://rs.tdwg.org/dwc/terms/index.htm change if we followed Rich's suggestions? How would we shift existing terms under the new classes?
After thrashing for two years about what the classes should be part of DwC and what those classes represent, it looks like we may be close to some kind of a consensus that could actually be incorporated into the standard. Let's not get distracted - there are ongoing efforts like BiSciCol and work to clarify how RDF can be used in our community that would only be hampered by that.
Steve
Bob Morris wrote:
On Wed, Jul 27, 2011 at 12:52 AM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote:
[...] Well you could say this about any non-disjoint classes. Why not combine the classes Teacher and ElectedOfficial if a person can be an instance of both? We don't do that because there are instances where persons are Teachers and not ElectedOfficials and other instance where people are ElectedOfficials and not Teachers. Instances of the class Teacher share properties like numberOfStudents and schoolOfEmployment, while instances of ElectedOfficial share properties like votesReceived and yearElected.
OWL supports intersection and union. In OWL the set of things that are both a Teacher and an Elected Official would form a class. It would perhaps have fewer individuals in it than either class, but in OWL it is nevertheless a class. Similarly the set of things that are either a Teacher or an ElectedOfficial, though not necessarily both, is an OWL class. Note that http://code.google.com/p/darwin-sw/source/browse/trunk/dsw.owl is at this writing not an OWL ontology, as you will see if you try to put it into the Manchester OWL validator. Much of that failure is minor syntactic botches, but when you fix them, some issues remain about dsw's secondary goal to "(hopefully) making design choices that do not constrain full SW reasoning downstream".
RDFS does not guarantee that the intersection of two classes is a class, but allows you to avow that in particular cases if you wish, whereas OWL always requires it. More to the point, RDFS allows you to conceptually think of classes and properties as having the same kind of structure, so that you can effectively talk about intersecting properties, e.g. define a property that is true for those individuals for whom two particular properties are true. This is discussed on p. 135 of [1], though you won't like the word "infer" used there. Chapter 8 of [1] introduces a subset RDFS-Plus of OWL that is largely motivated by being content with the expressiveness of SPARQL, which I guess fits in your comfort zone, especially as to "AND". My understanding of LOD is that its community is indeed content with the expressiveness of SPARQL for now, and dsw probably corresponds to the approach of Chapter 8 in a way that meets your primary goals for dsw.
In summary, I suspect that you are struggling about modeling individuals because: a. You believe in your heart that there is a fundamental difference between properties and classes but b. RDFS does not require that of one's models and c. dsw is expressed in RDFS and not in a modeling language that requires you to abandon a.
[1] Dean Alemang and Jim Hendler "Semantic Web for the Working Ontologist", 2nd Edition 2011
Bob
participants (3)
-
Bob Morris -
Richard Pyle -
Steve Baskauf