Re: fundamental issues

Karen, it would be very helpful for the group to have details of your 
example scenarios. It's not efficient to explain the various modeling 
options without such details. I remember you had sent snippets, but we 
need details of the workflow, e.g. who triggers the evaluation based on 
what info.

Thanks,
Holger


On 2/14/15 12:03 PM, Karen Coyle wrote:
>
> On 2/13/15 4:45 PM, Irene Polikoff wrote:
>> <But the fact is that I expect my data to ALSO be available in a
>> web-based environment that 1) uses the open world assumption and 2) is
>> where anyone can say anything about anything.>
>>
>> You may have some data about books or publications that you curate and
>> quality check internally and you also make it accessible to others by,
>> for example, providing a SPARQL endpoint for it or a Linked Data API or
>> whatever.
>>
>> Resources in your data have URIs and, as you made these URIs publicly
>> known, other people could make statements about these URIs that you
>> don't agree with. They could also take the data you are making available
>> and run some reasoning over it using OWA.
>
> I feel like I've said this many times before, but obviously not 
> clearly enough. I cannot design my data for a single validation 
> function because I intend for it to be re-used by other applications, 
> known and  unknown to me, that will need to employ a different view of 
> the data. My data must be "public" in the broadest sense. This is why 
> I resist using classes that define units of validation rather than 
> their intended semantic use.
>
> I want to define my data with a minimal ontological commitment 
> precisely because my data only gains value as it is re-used. 
> Therefore, validation needs to be a function separate from my ontology 
> and must not require modifications to my instance data.
>
> The Dublin Core Description Set Language [1], which is DC's early 
> attempt at defining validation and application profiles, is designed 
> to allow users to keep constraints out of their ontologies and 
> instance data, while using the DSP as a mediation between highly 
> flexible data and the momentary needs of a single application. Note 
> that the dcterms vocabulary makes very little use of domains/classes, 
> and that is intentional. I understood ShEx as taking a similar 
> approach, although that may not be the current picture.
>
> kc
> [1] http://dublincore.org/documents/dc-dsp/
>
>
>
>
>>
>> What problem does this present and what does it have to do with the
>> topic of this discussion?
>>
>> On Fri, Feb 13, 2015 at 7:18 PM, Karen Coyle <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>
>>
>>     On 2/13/15 10:26 AM, Richard Cyganiak wrote:
>>
>>         But that’s not the generally accepted meaning of “open world”
>>         and “closed world”. These terms refer to two specific modes of
>>         data processing (a.k.a. reasoning), e.g., in validation and
>>         querying. Open-world reasoning is when you assume there could be
>>         additional data “out there” that you just don’t know about yet,
>>         so “missing ain’t broken”. Closed-world reasoning is when you
>>         assume that your dataset is complete, so “missing” is a
>>         validation error.
>>
>>
>>     Yes, there is "open world assumption" and "closed world assumption"
>>     that are modes of data processing. Note I carefully did not use
>>     those terms. There is also "LOD" which talks about open data, but
>>     makes no statement about mode of processing. So what shall we call
>>     the difference between the open web and my private, internal data
>>     store? Is it open vs. enterprise? But the fact is that I expect my
>>     data to ALSO be available in a web-based environment that 1) uses
>>     the open world assumption and 2) is where anyone can say anything
>>     about anything.
>>
>>     kc
>>
>>     --
>>     Karen Coyle
>>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234 <tel:1-510-435-8234>
>>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>>
>>
>

Received on Saturday, 14 February 2015 02:11:35 UTC