Re: Requirement: Evolutionary Path to Adoption

Arthur,

If I understand it correctly, this idea assumes that data is partitioned in the graphs based on what constraints should be applied to it. In my experience, this is not the case.

Irene

> On Feb 21, 2015, at 5:34 PM, Arthur Ryman <arthur.ryman@gmail.com> wrote:
> 
> Irene, Holger, Dean,
> 
> I completely agree that we want a smooth adoption path. However, there
> is more than one way to achieve this. One way is to use a shape that
> depends on the context. There is no need to modify any existing graphs
> or class definitions.
> 
> For example, suppose you have a set of named graphs in a database and
> you want to validate each graph. You have a set of shapes and some
> rule that determines which shape is applicable to which graph. That
> could rule could be defined by a match like:
> GRAPH ?S {?S a ex:SomeType} where you associate ex:SomeType with some shape.
> 
> Or you might want to validate a graph as it is stored in the database.
> The validation process would be associate with the API to the
> database. You'd associate a shape resource with your API.
> 
> -- Arthur
> 
>> On Wed, Feb 18, 2015 at 11:19 PM, Irene Polikoff <irene@topquadrant.com> wrote:
>> Ontologies are used to enable applications to process the information
>> contained in documents. This is a key design goal and the intended use
>> case for OWL as stated in its specification. Thus, one can¹t simply say
>> that ontologies do not define the contents of documents. A fair amount of
>> subtle explanation and qualification would be needed around this statement
>> which doesn¹t lend itself to clean separation.
>> 
>> Of course, the main point is the one Holger is making. There is a
>> substantial amount of RDF data out there. The data is in files, it is in
>> RDF databases, it is sometimes in relational databases or XML or
>> spreadsheets exposed as RDF, it is passed in messages and so on. This data
>> uses ontologies. We need to be able to use this data as-is, extending with
>> constraints as necessary without having to redefine and port everything.
>> 
>>> On 2/18/15, 9:34 PM, "Holger Knublauch" <holger@topquadrant.com> wrote:
>>> 
>>> 
>>>> 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_Constrain
>>>> ts
>>>> 
>>>> [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_Constrain
>>>> ts
>> 
>> 
>>

Received on Sunday, 22 February 2015 02:12:56 UTC