Re: Requirement: Evolutionary Path to Adoption

On 2/19/15 12:25 PM, Arthur Ryman wrote:
> 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.

The point of this requirement is that we want the opposite. We want to 
be able to extend existing ontologies and thus reuse existing work and 
instances. "Cleanly" separating shapes from classes creates exactly what 
we do not want: one semantic web that is already established, and a 
parallel newcomer semantic web of shape definitions.

Holger


> _________________________________________________________
> 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:35:05 UTC