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