interoperability (was Re: isolating shapes in named graphs)

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 13:12:16 UTC