Re: Requirement: Evolutionary Path to Adoption

Dean/Holger,

I don't see any conflict between ontologies and shapes. Ontologies define 
1) the meaning of terms and 2) interference rules. Ontologies DO NOT 
define the contents of documents (aka information resources, aka graphs 
since we are interested in RDF documents). Shapes apply to graphs (or 
datasets) which are closed, finite sets of triples (or maybe infinite sets 
of triples allowing for inference). These graphs may be passed around in 
HTTP messages, or may live in databases, file systems, etc.

If we cleanly separate shapes from classes, then there is zero impact to 
existing ontologies. Shapes then provide a net new capability.
_________________________________________________________
Arthur Ryman, PhD
Distinguished Engineer | Master Inventor | Academy of Technology
Chief Data Officer, Application Platform
IBM Systems | Middleware
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015




From:   Dean Allemang <dallemang@workingontologist.com>
To:     Holger Knublauch <holger@topquadrant.com>
Cc:     RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Date:   02/04/2015 05:05 PM
Subject:        Re: Requirement: Evolutionary Path to Adoption
Sent by:        deanallemang@gmail.com



I can second this, with some very specific examples from FIBO and the 
current work being done in some of the banks. 


In FIBO, we have so far defined classes in terms of OWL Classes (including 
restrictions), and I don't see this changing any time soon.  But we have 
found a number of cases in which OWL cannot express what we want (role 
intersection and "firendly fire" situations).  I am hoping that FIBO will 
be able to make use of Shapes for these situations, as well as for some 
more mundane use cases like forms generation and checking.  

This means that we can expect FIBO to include both Shapes and Classes.   
Speaking as someone writing FIBO, I'm not so concerned about whether a 
Shape is a Class or if I have to create two things and link them together 
(I could imagine some 'profile' setup where we'd want different shapes for 
some class, but I'm not really sure that flexibility is needed)   But I'll 
figure out how to cope in either case.  

The real issue is that there are already RDF deployments out there that, 
of course, use ordinary RDFS classes and use rdf:type to relate their 
individuals to those classes.  We (FIBO) hope that those deployments (like 
the one I worked on at the Bank of America) will want/need to adopt FIBO, 
either as a regulatory requirement, or as a way for them to extend their 
systems. When that happens, the legacy data will then be related to the 
FIBO specs (both classes and shapes).  

If the shapes are done separately, either we are asking them to go back 
and change the rdf:type triples into something else (which in a bitemporal 
system is problematic; technically, it is impossible, but especially if 
you are tracking system time, it is a violation of the bitemporal contract 
to ever change something in a past system time), or to use some more 
complex query to figure out which shape goes with which entity.  I'm 
pretty sure that anyone managing such a system will just pretend that the 
standard says that you can use rdf:type to connect to Class/Shapes (and 
likewise rdfs:subClassOf to related shapes to one another and/or to 
classes), and implement the system that way (I've seen such things 
before).  Yes, they feel bad that they are not in full compliance with the 
standard, but they do what is expedient.  And then they mutter to each 
other over a beer after hours why the standards folks didn't just make it 
easy. 

This sort of smooth migration requirement that Holger is talking about 
here will be essential to getting the legacy systems on board (with a 
minimum of tears in beers). 


Dean







On Sun, Feb 1, 2015 at 4:07 PM, Holger Knublauch <holger@topquadrant.com> 
wrote:
I believe there is a high-level requirement that has not been sufficiently 
captured yet: how to make sure that the new standard provides a reasonably 
evolutionary path from existing systems and data models into the new 
closed constraint checking world. There is obviously a very large body of 
existing ontologies and instance data out there. Some of these are written 
down as User Stories including SKOS [1], Data Cube [2], PROV [3], but 
there is also a large body of lesser-known or even private data models in 
use.

The developers of those ontologies have already done a lot of hard work in 
devising suitable class hierarchies (via rdfs:subClassOf) and these 
hierarchies could often form the backbone of a "shapes" hierarchy too. 
Likewise, there is lots of instance data out there, often relying on 
rdf:type triples to identify applicable owl:Restrictions or RDFS 
ranges/domains.

I believe it is very important for the new shapes language to make it as 
easy as possible to reuse that data, and provide an evolutionary path for 
users who want to take their existing applications as starting point and 
extend them with closed-world semantics.

Holger

[1] 
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S21:_SKOS_Constraints

[2] 
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S22:_RDF_Data_Cube_Constraints

[3] 
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S30:_PROV_Constraints

Received on Thursday, 19 February 2015 02:25:45 UTC