RE: shapes and classes: different

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.

Received on Thursday, 5 February 2015 18:02:19 UTC