OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[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]