RE: Should we say "data model"?

Bernard,

 

I agree that trying to find, if possible, a readily understood term is important. It is too bad that RDF Schema is already taken because people new to RDF expect it to be defining constraints. Data model? May be, although I can see issues with this. Data definition language may be another option. Very familiar to any data manager from its use with relational databases. This topic is certainly something for the working group to work on.

 

Regards,

 

Irene

 

From: Bernard Vatant [mailto:bernard.vatant@mondeca.com] 
Sent: Tuesday, July 29, 2014 11:58 AM
To: public-rdf-shapes@w3.org
Subject: Should we say "data model"?

 

Dear all

My first post to this forum. I've been following the conversation with great interest, as someone who has been, as many others around here it seems, hacking OWL for about ten years to express what boils down (in the software architecture my company is selling) to a kind of entity-relationship data model. Unless our customers are already familiar with OWL and ontologies (which is still the minority of them, I must admit), the easiest way to communicate about this piece in the architecture is to call it the "model" if nobody around has a background in formal logic or model theory where "model" has a quite different meaning. People familar with UML buy this quite easily. Add to this a layer of discourse about the benefit of standard vocabularies and shared URIs, and you're done with justifying the hack, most of the time. And a pinch of validation rules, aka business rules, for the tricky things that do no fit well in the model. 

 

Our interlocutors are data managers, in a very broad acception of the term. What they want is being able to control data quality everywhere : at production and edition time (controlled interfaces), at exchange interfaces (import/export), at data aggregation (if D1 and D2 are valid datasets, what happens when I merge them) etc. The message to data managers should be: if you migrate your data to RDF, you will be able to achieve all those tasks based on standard language(s) and procedures.

Data managers are likely to frown at ontologies, shapes, application profiles etc, all terminology from various foreign lands they don't really want to explore. But if you say "data model" and if it looks more or less like a good old UML they will be ready to buy it.  If you speak of validation and inference rules on top of the model, they can understand also.

>From various posts in this conversation, I understand that the difference between an open world axiom/rule and a closed word constraint is more a question of interpretation than of formal structure. Does that mean that we are looking for something (language, format, whatever) that could be interpreted either with the open world assumption to support open world reasoning, and (exactly the same piece) interpreted in closed world applications as a constraint for interfaces or a validation rule?  

Thoughts?