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] Something like RDF and Structure for TAs


Apologies for 'jumping the gun' as it were. Looking at how Dublin Core
recommends use of RDF for its own domain, it's quite compelling to think
about how RDF could similarly be used for Test Assertions

e.g. looking at http://dublincore.org/documents/dcq-rdf-xml/

I guess this might have some impact on the way the TA is modeled (even
if it ideally shouldn't if we try to keep the model technology-independent).

Already the usefulness for my own areas of special interest (UBL, and
subsets of UBL as well as profiles and business processes and rules
where TAs are needed) is apparent.

My example is an Invoice where there might be all kinds of ways in
which RDF graphs (or equivalent TA methodologies) could be used to
formally defined an invoice document or a subset of an existing
invoice document definition:

        --------> rdf:Seq
       |                                        format
ubl:Invoice ---------------> ubl:Issue Date -------------> xsd:date
     |  |                           |   ...
     |  |                            ---------> ...
     |  |
     |  |
     |  |                                    cardinality
     |   --------------------> ubl:UUID ------------------->xsd:minOccurs=1
     |
      ----------->...

which is a graph for TAs:
1.
IUT: ubl:Invoice  (=RDF's subject)
TA: aggregates, as a sequence (=RDF's predicates / sequence) a ubl:Issue Date,
a ubl:UUID, ... (=RDF's objects)
2.
IUT: ubl:IssueDate (=RDF's subject)
TA: has format (=RDF's predicate) xsd:date (=RDF's object / literal)
3.
IUT: ubl:UUID
TA: has cardinality ...
... etc.

So there are ideas here about use of just a bag or of a sequence or of
alternatives but as parts of predicates within the TA itself rather
than as properties of the TA.

* Properties of the TA are Id and Spec Ref (plus maybe a few others).

* Sequencing, say, can be deferred to being content of a TA expression:
  * Instead of saying a TA is within a sequence, maybe a TA can include as
part of its expression that its predicates are to be read in sequence.

* This means, to my mind, that provided the TA can use expressions which
can refer to other TAs then it might not even need to have its own
properties like prerequisites, apart from the basics of TA Id, etc.

I'm back to suggesting that instead of saying 'a prerequisite of TA 101.3
is TA 101.2', there can be a TA 101.1 which states that 'TA 101.2 and TA
101.3 have to be tested sequentially'. This avoids the need for extra
complexity outside of the actual TA content (as TA properties, say).
Now it means to me that the structure can be chosen by design rather
than necessity - and for this reason I like the idea of keeping to a
'triple' and modeling it on the RDF principle of Subject + Predicate +
Object (or value) or in TAG terms: IUT + predicate expression + predicate
value, which for my UBL example is 'Issue Date' + 'format' + 'xsd:date'.

- Steve


Quoting "Durand, Jacques R." <JDurand@us.fujitsu.com>:

> RDF could be one representation candidate for Tas. Something to worry
> about once we have cleared the underlying TA model we still have to
> agree on ;-)

>
> But certainly, in the spirit of appealing to various standard
> communities, several TA representations could be suggested. RDF is one
> of them (it also has an XML mapping). One of the challenges, is that its
> modeling is at such a primitive level (e.g. in any data model it can
> apply to any attribute or function as "object-property-value") that RDF
> could be used in many ways here.
>
> For example, we could also decide that RDF triples
> subject-predicate-object could map to a very generic RDF graph that will
> express our TA model, like:
> TAid-IUT-value
> TAid-test-value
> TAid-specreference-value
> ...
>
> So we would have:
>
> Subject (IUT): #101.02
> Predicate: IUT
> Object: Issue Date
> Subject (IUT): #101.02
> Predicate: Test
> Object: is of DDMMYYYY format  <-- this assertion itself could be model
> as an RDF triple, closer to what you did.
> ...
> Etc.
> ...
>
> An interesting possibility is the composability of RDF triples into
> graphs.
>
> Jacques
>
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Friday, November 09, 2007 1:46 PM
> To: TAG TC
> Subject: [tag] Something like RDF and Structure for TAs
>
> Greetings TAG TC
>
> I was just reading a posting on XML Dev and a link posted was to W3C's
> GRDDL spec which has this introduction which looks very similar to the
> way I've personally been trying TAs in recent work:
>
> http://www.w3.org/2004/01/rdxh/spec#intro
>
> It does seem to relate to my own thinking about structuring a TA.
>
> In short I'd see an idealized TA as the equivalent of what GRDDL notes
> as an RDF triple, namely:
>
> Subject (read IUT) + predicate (read TA in predicate form) + object
> (read part of the predicate which is outside of the mere logic)
>
> So for example if I have a spec which reads "The issue date is mandatory
> and must be of the format DDMMYYYY"
> I can break that down as two TAs:
>
> common to both:
> * Spec Ref: http://www.mycompany.com/spec#101
> * Subject (IUT): Issue Date
>
> TA Id: #101.01:
> Predicate: Is mandatory (or expressed with XML Schema language,
> minOccurs = 1)
> Object: cardinality
>
> TA Id: #101.02
> Predicate: Is DDMMYYYY (need an attribute, as Jacques says, for whatever
>     expression language DDMMYYYY is)
> Object: format
>
> Then these TAs can easily be expressed I would think using RDF
> (borrowing from the W3C example and adapting it to a TA model but I'm
> not sure whether Dublin Core has anything like a TA's IUT or whether
> FOAF has anything useful, mind, but you get the idea) to give something
> like:
>
> <rdf:RDF
>      xmlns:ta="http://some-tag-url.org/...";
>      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>      xmlns:core="http://purl.org/...";>
>
>    <rdf:Description rdf:about=
> "http://www.mycompany.com/spec/ta-101.01/6b050dcf-7ab1-456d-9e1b-c3c41c1
> 8eed2">
>      <core:IUT>Issue Date</core:IUT>
>      <tag:has>
>        <tag:Cardinality rdf:about=
>
> "http://www.mycompany.com/date/syntax/xsd/33b3c323-77c2-417c-a5b4-af7e6a
> 111cc9">
>          <tag:expression>minOccurs='1'</tag:expression>
>        </tag:Cardinality>
>      </tag:has>
> <rdf:Description rdf:about=
> "http://www.mycompany.com/spec/ta-101.02/6b050dcf-7ab1-456d-9e1b-c3c41c1
> 8eed2">
>      <core:IUT>Issue Date</core:IUT>
>      <tag:has>
>        <tag:Format rdf:about=
>
> "http://www.mycompany.com/date/syntax/???/33b3c323-77c2-417c-a5b4-af7e6a
> 111cc9">
>          <tag:expression>Is DDMMYYYY</tag:expression>
>        </tag:Format>
>      </tag:has>
>
>    </rdf:Description>
> </rdf:RDF>
>
> No idea if this is proper RDF but it gives an idea of what I'm thinking
> about.
> I'm not sure I'd choose RDF to express a TA but the tuple approach seems
> to me to be quite suitable for TAs and seems to back the concept of
> splitting a TA formally into 'IUT + predicate...' and perhaps I think
> '...+ Subject'.
> So I'm suggesting, I suppose (based on my own experiments for a recent
> project) splitting the predicate (whether it is called predicate or
> outcome) into a logical predicate part and an object, assuming the IUT
> is the subject.
>
> Maybe people will want to use RDF so this might help facilitate doing
> so.
>
> Best regards
>
> --
> Stephen Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]