Re: interoperability (was Re: isolating shapes in named graphs)

Incomplete interoperability is just ... not complete interoperability.   At 
one end it shaedes up to complete interoperability.  The other end is no 
interoperability.

As far as I can determine, incomplete interoperability is the current 
situation of the web, and I don't see how that is likely to change.

Even normative practices that require that all users of a particular world 
identifier abide by the written-down definition of that identifier do not 
ensure complete interoperability.



What sort of normative practices would prohibit using foaf:mbox for shoe size? 
  Can such practices also permit the use of identifiers in unusual ways or 
overcome incorrect definitions?

peter


On 11/26/2014 11:59 AM, Irene Polikoff wrote:
> If there is no way to define the meaning of some version of 'incomplete interoperability' (and I am not saying if there is a way or not), then I don’t see how we could effectively talk about 'incomplete interoperability'.
>
> As far as prohibiting the use of mbox for the shoe size, I see this issue as one of describing and adhering to normative practices including those specified in the relevant standards.
>
> Irene
>
> -----Original Message-----
> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
> Sent: Wednesday, November 26, 2014 10:33 AM
> To: Irene Polikoff
> Cc: Eric Prud'hommeaux; Holger Knublauch; public-data-shapes-wg@w3.org
> Subject: Re: interoperability (was Re: isolating shapes in named graphs)
>
> What would boundaries of incomplete interoperability look like?  I can't think of any way of making such boundaries.
>
> I'm not saying that it is OK to use foaf:mbox for shoe size.  There is a decided cost for going against common usage.  However, I'm not saying that there should be a mechanism to forbid using foaf:mbox for shoe size, even if such a mechanism were possible.
>
>
> Sure data from a single source can be incorrect as well as data from multiple sources.  Perhaps this is a separate issue.  All I was trying to point out is that even if everyone agrees on a common meaning for everything interoperability is by no means guaranteed.
>
> peter
>
>
> On 11/26/2014 05:52 AM, Irene Polikoff wrote:
>> What are the boundaries of the incomplete interoperability? Are they defined in any way? I think it is OK to say that it is incomplete as long as there is some explicit definition as to what that means.
>>
>> As a result, I find some of these statements confusing, as for example, saying that, absolutely, it would be OK to use mbox for the shoe size. This is not incomplete interoperability. It is no interoperability.
>>
>> The fact that data can be incorrect seems to be orthogonal to the subject of merging. Data from a single source can be incorrect as well.
>>
>> Irene
>>
>>
>>> On Nov 26, 2014, at 8:11 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote:
>>>
>>> One usually uses an external URI, like foaf:mbox, because one wants interoperability of meaning.  However, I do not believe that complete interoperability of URI meaning should be mandated.  I also do not believe that complete interoperability of URI meaning is possible.
>>>
>>> Further, I believe that effective interoperability can be achieved without mandating use of defining definitions.  For example, I may decide that I don't want to use the "static" part of the definition of foaf:mbox. Interoperability should remain for most purposes.
>>>
>>> Particular commmunities can, if they want,  require stronger conditions on shared meaning.  Perhaps it would be possible to set up a community that achieves complete interoperability of meaning.  However, I very strongly believe that "the web" cannot be such a community, and thus that W3C recommendations should never mandate it.
>>>
>>>
>>> Merging data from different sources can be problematic even if the use of defining definitions is mandated.  Data can be incorrect, after all.
>>>
>>>
>>> peter
>>>
>>>
>>>
>>>> On 11/26/2014 04:14 AM, Irene Polikoff wrote:
>>>> Interesting... If this is the case, why use foaf:mbox in the first place?
>>>>
>>>> There is no interoperability. There is no common meaning. What is the benefit compared to using my:email, for example?
>>>>
>>>> I think an obvious answer is that the data from different sources
>>>> can be merged and the merge occurs naturally without any effort just
>>>> because the same predicate is used. But, then the question is
>>>> whether this is desirable for data where the meaning of using the
>>>> predicate is different from one source to another. Especially, if
>>>> someone uses it to represent their shoe size :)
>>>>
>>>> Whomever uses the merged data has no way of knowing which data conformed to mbox semantics and which used it without conforming.
>>>>
>>>> On the other hand, if sources/systems that didn't conform used their own predicate and said something like {my:email skos:match foaf:mbox} meaning that it is roughly equivalent to foaf:mbox without confirming to its definition (in other words, it is email, not a shoe size), then the merge would still be possible through an additional processing step and an informed decision could be made on whether to merge or not - depending on how the merged data is to be used.
>>>>
>>>> Irene
>>>>
>>>>> On Nov 26, 2014, at 6:15 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>> On 11/26/2014 02:45 AM, Eric Prud'hommeaux wrote:
>>>>>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-26
>>>>>>> 02:23-0800]
>>>>>>>
>>>>>>>
>>>>>>>> On 11/25/2014 10:22 PM, Eric Prud'hommeaux wrote:
>>>>>>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-25
>>>>>>>> 16:20-0800]
>>>>>>>>>> On 11/25/2014 02:14 PM, Eric Prud'hommeaux wrote:
>>>>>>>>>> * Holger Knublauch <holger@topquadrant.com> [2014-11-19
>>>>>>>>>> 22:36+1000]
>>>>>>>>>>
>>>>>>>>>>>                                       For the majority of use
>>>>>>>>>>> cases you would end up with Shape objects that are mirroring
>>>>>>>>>>> classes,
>>>>>>>>>>
>>>>>>>>>> I disagree that the majority of shapes would be global invariants.
>>>>>>>>>> But regardless, the fact that we don't want to write off the
>>>>>>>>>> other use cases implies that we must not require a model which
>>>>>>>>>> forces one to retract one schema when looking at another when
>>>>>>>>>> both should be associated with particular interfaces.
>>>>>>>>>
>>>>>>>>> What does "global invariant" mean here?
>>>>>>>>>
>>>>>>>>> There is no way that constraints can be truly global, i.e.,
>>>>>>>>> that every use of RDF has to include them all.  I don't see
>>>>>>>>> anyone arguing that the mere use of a class requires the use of
>>>>>>>>> all constraints associated with that class, which perhaps could
>>>>>>>>> be considered to be akin to a global invariant.  All other
>>>>>>>>> setups for constraints appear to be situational, i.e., not global.
>>>>>>>>
>>>>>>>> Three messages "up" in this thread, I was arguing just that. See
>>>>>>>> <http://www.w3.org/mid/20141119111430.GB24640@w3.org> (attached).
>>>>>>>>
>>>>>>>> I agree re "situational". As a counter example, the FOAF
>>>>>>>> ontology
>>>>>>>> *could* say that foaf:mbox had a cardinality of one, but that
>>>>>>>> would needlessly restrict its usage. (At TPAC, Tantek beat me up
>>>>>>>> about having cardinalities attached to vocabulary definitions.
>>>>>>>> After a sound drubbing, I managed to explain that he was beating
>>>>>>>> up the wrong guy.)
>>>>>>>>
>>>>>>>>
>>>>>>>>> peter
>>>>>>>
>>>>>>>
>>>>>>> I don't see in that message that you are arguing for either true
>>>>>>> globality, that all users of RDF commit to all constraints, or
>>>>>>> even mention globality, that all users of something like
>>>>>>> foaf:mailbox commit to all constraints that mention foaf:mailbox.
>>>>>>>
>>>>>>> Note that I'm not stating that no one has argued that constraints
>>>>>>> that are part of an ontology (if this is possible) must be in
>>>>>>> force for all users of that ontology.  I would even argue for
>>>>>>> this.  I'm not even stating that no one has argued constraints
>>>>>>> that are part of an ontology (if this is possible) must be in
>>>>>>> force for all users of vocabulary defined in that ontology.  I,
>>>>>>> however, argue against this, just like I argue against vocabulary
>>>>>>> mention requiring ontology use.
>>>>>>
>>>>>> If I don't owl:includes foaf:, can I use foaf:mbox in a way that
>>>>>> is specifically inconsistent with its definition in FOAF, e.g.
>>>>>> having it not being an IFP, possibly representing my shoe size?
>>>>>
>>>>> Absolutely.
>>>>>
>>>>>> If so, where do
>>>>>> we get interop?
>>>>>
>>>>> We don't, and I don't feel that there is any need to mandate
>>>>> interoperability by simple vocabulary mention.  Interoperability is
>>>>> a desirable goal, of course, and there are many situations where it
>>>>> should be in force.  However, there are lots of situations where
>>>>> interoperability fails.  (The DBpedia ontology shows one failure
>>>>> mode.)
>>>>>
>>>>>> If not, is there a boundary around foaf:box ?p ?o for which I am
>>>>>> responsible when I utter foaf:mbox?
>>>>>
>>>>> No.  You may choose to ignore the defining document for foaf:mbox.
>>>>> You do so at your  peril, of course.  (I wonder how many uses of
>>>>> foaf:mbox are incompatible with its definition, particularly the
>>>>> static inverse functional property aspect.)
>>>>>
>>>>>>> Why do I argue against vocabulary mention requiring ontology use?
>>>>>>> Consider DBpedia.  The DBpedia ontology has many problems,
>>>>>>> including incorrect subClassOf relationships.  It should be
>>>>>>> possible to use the DBpedia class vocabulary, and even the entire
>>>>>>> DBpedia graph, with committing to the DBpedia ontology.
>>>>>>
>>>>>> Is Danbri mischievous enough to add a deliberate inconsistency to
>>>>>> test this issue? IIRC, he started FOAF 'cause said "but RDF could
>>>>>> be used to track everyone. That's horrible; now what would that look like?"
>>>>>
>>>>> Well FOAF is specified using certain OWL properties.  Does that mean that all users of FOAF have to abide by the OWL semantics?  Does the use of rdfs:subClassOf mandate using the RDFS semantics?  Does the use of rdf:type mandate using the RDF semantics?
>>>>>
>>>>>
>>>>> peter
>>>>>
>>>>>
>>>>>
>>>>>
>

Received on Wednesday, 26 November 2014 20:19:11 UTC