Re: Application-specific data model options

If I understand #3 (below) correctly, this would also be my preference.
Except that my approach would be the same as what I proposed for class
hierarchies: To adopt a minimalistic data model (like in F-logic, of course :-)
and translate things into it. Other models would have to add additional
axioms to the minimalistic ones, but nobody will be forced to jump through
the hoops in order to adapt to some weird and out-of-the-blue axioms that
some W3 standards impose.

The F-logic data model is quite similar to RDF except that typing of the
properties can be local to classes. For instance, you can say

Person[name=>PersonName]
Company[name=>CompanyName]

where PersonName and CompanyName could be completely different classes of
objects. In RDF, all properties are global, which is a special case of
F-logic's.

The other difference is that F-logic does not force rdf:range (and other
such things) to be in the domain (the same issue as with rdf:type). So,
everyone would be free to decide if they want such metaproperties to be in
the domain or not.


	--michael  

> As I put in a separate email in updating the Arch/DataSets page I put in 
> a placeholder section on the question of how how RIF rulesets actually 
> make use of application-specific data models.
> 
> My attempted summary (which may or may not overlap with Christian's 
> action) was:
> 
> """
> We have several possible approaches to this question under discussion at 
> the moment. These include:
> 
>     1.  Library of translators. For a given category of data model we 
> define a transformation which will convert that data to a RIF native 
> format. The rules are written to manipulate that RIF native form. In the 
> case of RDF we have proposed a translation algorithm which would apply 
> to any RDF (and thus RDFS or OWL) document, irrespective of the 
> associated ontology. For some data models such as XML then the 
> translation may be driven by a schema document. RIF itself would define 
> only a small number of such translators (perhaps just RDF (schemaless) 
> and XML (driven by XML Schema)). Other groups could define additional 
> translators and record that fact in metadata but there would be no 
> automatic way for an existing RIF implementation to discover and use 
> such extension translators.
> 
>     2.  Abstract datatypes. In this approach rather than translate data 
> into RIF facts, the data is exposed as concrete data types and data is 
> manipulated via a set of model-specific builtin predicates and 
> functions. In the case of RDF we would have types like graph, triple, 
> node and associated predicates including SPARQL queries; in the case of 
> XML would have types like Element, Document and associated predicates 
> such as XPath-like navigation.
> 
>     3.  Single meta translator. In this approach RIF adopts a single 
> meta-meta modeling language (perhaps MOF or KM3)and defines a single 
> transformation algorithm. For any data model category we define a 
> meta-model for it, expressed in our standard meta-meta modeling 
> language. The transformation algorithm can translate any instance data 
> for which there is an associated model and meta-model to RIF native 
> format. RIF would only define a small number of such meta-models but the 
> external groups could adopt additional ones. In this case the associated 
> meta-model could be referenced in the ruleset metadata and a RIF 
> implementation could apply the meta-translator without further modification.
> """
> 
> I didn't feel it appropriate to put personal commentary on the Wiki 
> page, email seems better for that. So here it is.
> 
> In some ways I rather like what Hassan was proposing which I've 
> attempted to capture in option 3 "meta translator". This seems to give 
> greater extensibility and is intellectually more satisfying.
> 
> My primary concern is that the resulting mappings may not look very 
> intuitive or easy to work with for a specific data model - a 
> hand-crafted transformation can be simpler. We also increase our 
> coordination problems by having to fit in with other meta-modelling efforts.
> 
> Taking RDF/RDFS as a specific test case then I imagine we would 
> consider using ODM [*], justifying why W3C was investing in another 
> meta-model for RDFS would take some doing. Whilst ODM is a great piece 
> of work it is complex, and doesn't model RDFS in the most natural way 
> from the point of view of RDF rules languages. I would find the simple 
> triple level mapping already proposed rather easier to work with than a 
> mapping auto-derived from ODM.
> 
> Dave
> 
> [*] Ontology Definition Metamodel, not to be confused with ODMG.
> -- 
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
>

Received on Wednesday, 1 August 2007 13:46:09 UTC