RE: shapes and classes: different

Karen,

I do not mean a single enterprise only although the example I gave was of a single enterprise.

Alternatively, I could have given a cross enterprise example that would work the same. For example, FIBO defines a general/core model and then a bank that adopts it may extend the general definition of a contract that is in FIBO. And another bank also extends it in some other way. Similarly, many SKOS users extend SKOS model in various ways. In the Norwegian Oil and Gas industry, there is a standard model that also gets extended for different purposes. And so on.

The key here is that there is a model with some core semantics that all its users agree with. When they adopt it for their use, they extend it where necessary. Different groups have different extensions. They add to, but they do not contradict with the core model.

I am not saying that this is the only way to reuse, but that this is a very common way of reusing. Yes, I think it would be beneficial to describe other approaches to re-use, so that when we say "re-use" we actually know what re-use we mean.

Irene

-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: Thursday, February 05, 2015 1:20 PM
To: Irene Polikoff; 'Eric Prud'hommeaux'
Cc: public-data-shapes-wg@w3.org
Subject: Re: shapes and classes: different

Irene, I think what you describe below is 1) a single enterprise 2) centralized with extensions. There is another model, that that is multiple enterprises or communities, decentralized, where data is aggregated from different ontologies for some purpose. Some of these aggregate data into a central store for efficient searching, but there are also systems that use linked data across different data stores to respond to queries.

Can/should these be included in our considerations?

kc

On 2/5/15 10:01 AM, Irene Polikoff wrote:
> OK, I was just saying that if we are to use terms like closed, open and semi-closed systems, we must define them. I, for one, am not sure what they mean.
>
> As far as re-use in a corporate setting, it is very common for an organization to have a core definition that everyone agrees with and then for specific departments to extend it for their context. They would think of this as an HR or Sales extension of the common definition. Not as the common one is a class and extended is a shape. And then, US HR can have its own extension "on top" of HR and Europe HR would have its own. And so on.
>
> Reuse happens all the way down the chain the key word being "extension". Extensions typically happen as subclasses - e.g., US Employee versus Employee in general and there would be corresponding instances of type US Employee. So, I don’t see the re-use as a distinction. It may be that you are thinking of a different approach to reuse which is fine, but then we need to describe different ways people reuse models.
>
> Irene
>
> -----Original Message-----
> From: Eric Prud'hommeaux [mailto:eric@w3.org]
> Sent: Thursday, February 05, 2015 12:19 PM
> To: Irene Polikoff
> Cc: kcoyle@kcoyle.net; public-data-shapes-wg@w3.org
> Subject: Re: shapes and classes: different
>
> * Irene Polikoff <irene@topquadrant.com> [2015-02-05 11:36-0500]
>> There is an existing definition for what "open world" and "closed world" mean. Basically, open world means that one doesn't make any conclusions based on the absence of data. For example, a min cardinality constraint on a property can't cause an error because no triples with that predicate are found - they may exist, we just don't know it yet. Obviously, from the data validation perspective this is not very useful.
>>
>> Another set of terms is now being introduced: open systems, closed systems and semi-closed systems.
>>
>> I believe these terms need to be defined so that we could use them consistently on this forum and, where appropriate, in the working group deliverables.
>
> I think the important distinction WRT shapes vs. classes is whether a class is likely to be reused. We have more influence over that in closed systems for short periods of time, but what matters is whether HR and Sales are both going to use objects of type myco:Contact, but with different restrictions.
>
>
>> Irene
>>
>> Sent from my iPhone
>>
>>> On Feb 5, 2015, at 11:16 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>
>>>
>>>
>>>> On 2/5/15 7:32 AM, Richard Cyganiak wrote:
>>>> You make it sound like attaching shapes to classes is something 
>>>> that one would only want to do in closed systems. I disagree with 
>>>> this. I expect that ontologies designed for use in open systems 
>>>> will also include shapes in their definitions. I know I would have 
>>>> liked to include some in several ontologies that I’ve worked on.
>>>>
>>>>>> - […] we should not force future systems to couple shapes with 
>>>>>> classes when they don't need to be coupled.
>>>> We should also not force future systems to decouple shapes and 
>>>> classes when they don’t need to be decoupled.
>>>
>>> The way that the Dublin Core community sees this working is through 
>>> published application profiles. For data which I want to share, and 
>>> which I want to be shared widely even with folks outside of my 
>>> immediate community, I want two things:
>>>
>>> 1) a minimally constrained ontology that is designed for re-use 
>>> ("minimally constrained semantics" - T Gruber). This doesn't mean "no shapes" but it may well mean "insufficient for closed world validation needs"
>>>
>>> 2) a profile through which I express (in a machine-actionable form) 
>>> MY view of MY data (which may not be how others see or choose to use 
>>> the data I provide). This profile is what I validate against.
>>>
>>> This serves both those who may wish to make use of my data, but who 
>>> are not likely to engage in a data exchange agreement with me, as 
>>> well as my community partners, who wish to do some alignment of 
>>> their data with mine for inter-system linking.
>>>
>>> The ability for different users to have different "views" of the 
>>> data is key to the success of a heterogeneous community of users.
>>> Even within closed or semi-closed systems different views must be possible because there are different materials being described and a variety of users and uses. It seems obvious that the same data may be re-used even within closed systems, and I think this is what Peter P-S was referring to in his response to Holger's example. And, btw, we've been doing this in databases for decades, haven't we?
>>>
>>> I promised to find some documentation. This article has some 
>>> diagrams that may suffice, even if folks don't have time to read the text:
>>>
>>>      http://dlib.org/dlib/january10/hillmann/01hillmann.html
>>>
>>> I don't know that this is the best way to accomplish this, but it is 
>>> one idea that is circulating.
>>>
>>> kc
>>>
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> m: 1-510-435-8234
>>> skype: kcoylenet/+1-510-984-3600
>>>
>>
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.
>
>

--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 5 February 2015 19:46:42 UTC