Re: Requirement: Evolutionary Path to Adoption

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