- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Fri, 30 Nov 2007 12:56:04 -0500 (EST)
- To: conrad.bock@nist.gov
- Cc: alanruttenberg@gmail.com, ekendall@sandsoft.com, public-owl-wg@w3.org, cawelty@gmail.com
From: "Conrad Bock" <conrad.bock@nist.gov> Subject: RE: UFDTF Metamodeling Document Date: Fri, 30 Nov 2007 12:12:51 -0500 > > Peter, Alan, > > > > > By the way, it appears to me that the RDF metamodel allows > > > > regular (unreified) triples (RDFStatement) to be missing a > > > > subject, predicate, or object, which is not allowed in RDF. > > > > Where is this prohibition stated in RDF? > > > > > > -Alan > > > I'm quite amazed that this question was even asked. The entire > > notion of RDF is built around graphs of triples, which, as triples, > > have to have all three elements. > > > 6.1 RDF Triples > > > > An RDF triple contains three components: > > > > * the subject, which is an RDF URI reference or a blank node > > * the predicate, which is an RDF URI reference > > * the object, which is an RDF URI reference, a literal > > or a blank node > > BTW, the question above would not come up without review of the ODM > metamodel. It gives a less ambiguous description of the above, which is > just text that doesn't have the detail of "must", and "at least one", > etc. Umm, how is the text above ambiguous? To me, it clearly states that an RDF triple has to have three components, namely one subject, one predicate, and one object. I suppose that it could have been made more pedantic by adding "MUST" and "exactly", but I don't think that this change would make the situation any clearer (and I am known for being very picky about being precise in definitions). In any case there a lots of places in the RDF Semantics document where it is clearly shown that an RDF triple has to have all three components, including the places where the basic semantics of RDF is formally defined. > This is another reasong it is critical to have community-wide agreement > on the OWL and RDF metamodels, rather than multiple ones from multiple > standards bodies. We won't get to that agreement by ignoring each > other's metamodels. Issue 82 was worded specifically for harmonization, > rather than divorce. This is a perfect time to do it, before > finalization of the ODM and recommendation of OWL 1.1. Well, I'm not sure about this. OWL is already a W3C recommendation. It seems to me that the only possible stance is that any OMG metamodel for OWL has to reflect what is in the W3C recommendation. The situation with OWL 1.1 is exactly similar. OWL 1.1 exists as a member submission to W3C. If the OMG wants to have a metamodel for OWL 1.1 then it again has to submit to what is. The structural specification for OWL 1.1 is part of OWL 1.1. I don't see any reason for the OWL 1.1 stuctural specification to be changed to match errors in the OMG metamodel for OWL. I don't see any overarching reason for the OWL 1.1 structural specification to be significantly changed to align it with the OMG specification for OWL, as the structural specification is targetted towards extracting the structure of an OWL 1.1 ontology in a way that is useful for building OWL 1.1 tools. Even the situation with the OWL WG is quite similar. The OWL WG is supposed to come up with an update to the W3C OWL recommendation. Alignment with the OMG metamodel for OWL is at best a secondary concern. Certainly there is no reason to make a sub-optimal design choice for the updated OWL just to match something in the OMG metamodel for the old OWL. In any case, I certainly don't see any reason for the OWL WG to change its schedule to meet any OMG schedule. > Conrad Peter F. Patel-Schneider Bell Labs Research
Received on Friday, 30 November 2007 18:12:47 UTC