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

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-26 05:11-0800]
> 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.

It sounds like if I'm not feeling lucky, I should never consume data
from anyone with whom I've not written up some contract. What would
that contract say? "I agree to use the vocabularies according to their
documented semantics. I will not use terms if I don't understand their
semantics."


> Merging data from different sources can be problematic even if the
> use of defining definitions is mandated.  Data can be incorrect,
> after all.

I suspect you are being a bit provacative here, and I'm playing along
nicely. Surely we needn't jettison this fine bathwater just because
it's slightly sullied by a baby. It's quite practical to say that I
will respect, or at least not contradict, the properties of foaf:mbox
even if there's an assertion elsewhere in that ontology that the moon
is a subclass of Things made of green cheese. What's the actual
screw-case if I use <http://dbpedia.org/resource/Moon>?


> 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
> >>
> >>
> >>
> >>

-- 
-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 Wednesday, 26 November 2014 13:46:28 UTC