[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Issue Re: [tag] A tighter RDFS/OWL-DL representation
Also I found that a predicate can conveniently be a choice between prose and a named-property/value pair (where property could be a class - the instance of which could identify the value in its name or ID unless typing is required in the value in which case a separate entity would reqresent it optionally too) i.e. Assertion (precondition): target: Widget ID: widget001 prose: is medium sized or Assertion target: Widget ID: widget001 Size (sub-class or Property class): medium or Assertion target: Widget ID: widget001 MediumSized (instance of Size subclass of Property class) or Assertion target: Widget ID: widget001 Property: Size value (datatype=string): medium [the concept of property/value and its several uses is what I'm suggesting as additional structure to the anatomy rather than these actual example representation(s)] I've represented it as: >> <owl:Class rdf:ID="Property"/> ... >> <owl:FunctionalProperty rdf:ID="property"> >> <rdfs:domain rdf:resource="#Target"/> >> <rdfs:range rdf:resource="#Property"/> >> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/> >> </owl:FunctionalProperty> >> <owl:FunctionalProperty rdf:ID="value"> >> <rdfs:domain rdf:resource="#Property"/> >> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> >> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> >> </owl:FunctionalProperty> > > There is an issue to note, I think, with the use of a 'precondition' > - it is a bit of a modeling problem in that the precondition actually > functions as a restricted subclass of the test assertion or its predicate. > > * If the precondition is itself a predicate it needs everything > a test assertion needs except the spec ref. I.e. maybe it needs > its own ID so one precondition can be used in multiple predicates. > > * This then leads to some issues: > > * Why not then just use an assertion? > > * What then is the difference between precondition and prerequisite? > > * Doesn't this logic mean that a test assertion actually amounts > an extension of a superclass which is an assertion (extended by > adding spec ref)? > * Then a prerequisite could be the equivalent of a precondition > in that both reference both assertions and test assertions (or > instantiate, rather than reference the assertion and test > assertion classes). > > * So having a new superclass of test assertion called 'assertion' > could answer three problems: > 1. no need for both prerequisites and preconditions > 2. distinction between > a. test assertions and > b. assertions/predicates which aren't test assertions as such > 3. a different target can be associated with the assertion/predicate > of the precondition/prerequisite - a different target to the TA's > > Another issue arose while trying to implement the model: > > Does a TA have a target or does a target have a TA? > > The latter proves to be most useful in my example (to allow grouping > of TAs under the category of a shared target or target class). > > Best regards > - Steve > >>> -- >>> Stephen D. Green >>> >>> Partner >>> SystML, http://www.systml.co.uk >>> Tel: +44 (0) 117 9541606 >>> >>> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]