Re: Requirement: Evolutionary Path to Adoption

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 Saturday, 21 February 2015 22:35:13 UTC