> On Wed, Feb 24, 2010 at 05:27:19PM +0000, Antoine Zimmermann wrote: > > Another slight problem of owl:equivalentProperty, though arguably > > minor, is that it is not part of the RDF/RDFS vocabulary. So, a pure > > RDFS reasoner or RDFS tool would simply ignore the two implicit > > rdfs:subPropertyOf. There is no reason to assume that all RDFS tool > > support the OWL vocabulary.
> Antoine raises another point on which I would appreciate feedback > on DCMI's work.
> DCMI Metadata Terms [e.g., 1] are currently defined entirely > using RDF and RDFS. Domains and ranges were assigned to most > DCMI properties in 2007, as discussed in [2], but every DCMI > property is still declared simply to be of type rdf:Property -- > not of type owl:DatatypeProperty, owl:ObjectProperty, or > owl:InverseFunctionalProperty, etc, as in FOAF [3].
> DCMI metadata terms started to be coined in 1995, two years > before RDF even began as a project, so much of DCMI's efforts > have been about evolving with the times. Though we have > certainly noticed the rising use of OWL for defining > vocabularies, nobody has ever proposed that we revisit DCMI's > RDF-based style for declaring terms. Indeed, Antoine's point > above makes me wonder whether there might in fact be good > reasons to continue along this current path - or, if we were to > start using OWL vocabulary, to preserve compatibility with RDFS > tools by using it only in addition to RDFS vocabulary.
> I would be very interested to hear views from members of this > list on this question. As always, DCMI tries to promote > solutions that can straightforwardly be imitated by others, > so the general question is whether it is still good practice to > declare such a vocabulary using just RDF and RDFS, or whether > the use of OWL significantly enhances its usability, and if so, > in what ways.
The DC terms are very popular, and in particular many users of OWL (and OWL-DL in particular) use them or adapt data sources that use them. The practice is generally to make a copy of DC and then edit it to turn it into an OWL or OWL-DL file. The popular ontology editor Protege even provides such a DC variant as part of its distribution.
I think users would be served better by having a common OWL-DL version of DC, whether provided by DCMI or by someone else. Protege's is close to being such (although it is based on dc: elements instead of dct: terms). One problem is the question of whether the properties should be annotation properties or object/data properties, which matters for DL. IIUC Protege takes the position that the dc: properties are all annotation properties, while Bibo says that the dct: properties are object/data properties. I could fully sympathize if DCMI didn't want to get into the middle of this feud.
> I will be happy to pass any such views to DCMI lists but also > cordially invite anyone to engage the DCMI community directly on > these issues by posting to the dc-architecture mailing list > [4].
My point of view on this topic somewhat differs from Aidan's and Richard's. I believe and would argue that what you propose, Alex, is actually *the* best practice.
Externalising mappings has a lot of advantage. 1) the vocabulary publisher does not have to update his/her vocabulary in function of the publication and adoption of other vocabularies. Vocabularies should concentrate on specifying their own terms, such that they can reach a certain stability. 2) external mappings are reusable independently from the ontologies. This is useful for a) combining them, e.g., by composing "chains of mappings"; b) improving mapping tools that exploit existing mappings; c) evaluating mapping tools; d) using them to produce a transformation function that mediates between two services using different vocabularies; e) et cetera. [1] 3) it makes modular reuse of vocabularies more flexible. Maybe one wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF and DC with different mappings, thus will import or reuse a different "mapping ontology". One can choose to reuse FOAF in conjunction with the dBPedia vocabulary rather than DC.
In any case, such mappings between existing vocabularies are deadly missing and I would encourage any initiative that favour publishing such mappings, be it independent from the vocabulary publishers or not. Such initiatives are actually taking place in the ontology matching / ontology design / ontology xyz communities but they have not yet gained enough momentum.
> I don't want to bloody the waters, but one of the ways we (a bunch of > us working on semantic interoperability at NC3A) decided to slice this > particular cat was to put these extra "interpretation" axioms into a > separate ontology which imports the two ontologies we want to relate.
> E.g. create FOAF-DC-interpretation.owl which imports foaf and > dc:terms, into which is added the statement that foaf:maker > owl:equivalentProperty dcterms:creator.
> This has the benefit of ring-fencing these potentially subjective > assertions into their own named graph which you can take or leave in > an application simply by importing or not this interpretation > ontology.
> The main issue we had was that while it's relatively easy in this kind > of set-up to say who the authority is for a domain ontology, it's > tricky to figure out who should be in charge of these interpretation > ontologies. In the case of FOAF vs DC, it seems relatively > straightforward for FOAF to publish a separate little ontology.
I would appreciate your thoughts on practical solutions to the problem of conflicting and malicious mappings.
As me and others have explained in this thread, manual methods for picking which mappings to use and which to ignore are not feasible in general on the Web. Any approach that requires manual decisions about inclusion or exclusion of mappings will simply not work for a number of significant use cases. Whatever other advantages the approach may have is irrelevant -- it does not work, and quite frankly misses the topic of this list.
If mappings are externalised, then how do data consumers avoid malicious/broken mappings, and how do they choose between conflicting mappings, without relying on a trained expert to make the decision?
Best, Richard
On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
> My point of view on this topic somewhat differs from Aidan's and > Richard's. I believe and would argue that what you propose, Alex, is > actually *the* best practice.
> Externalising mappings has a lot of advantage. > 1) the vocabulary publisher does not have to update his/her > vocabulary in function of the publication and adoption of other > vocabularies. Vocabularies should concentrate on specifying their own > terms, such that they can reach a certain stability. > 2) external mappings are reusable independently from the ontologies. > This is useful for a) combining them, e.g., by composing "chains of > mappings"; b) improving mapping tools that exploit existing mappings; > c) evaluating mapping tools; d) using them to produce a transformation > function that mediates between two services using different > vocabularies; e) et cetera. [1] > 3) it makes modular reuse of vocabularies more flexible. Maybe one > wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF > and DC with different mappings, thus will import or reuse a different > "mapping ontology". One can choose to reuse FOAF in conjunction with > the dBPedia vocabulary rather than DC.
> In any case, such mappings between existing vocabularies are deadly > missing and I would encourage any initiative that favour publishing > such mappings, be it independent from the vocabulary publishers or > not. Such initiatives are actually taking place in the ontology > matching / ontology design / ontology xyz communities but they have > not yet gained enough momentum.
> 2010/2/25 ajtucker <a.james.tuc...@googlemail.com>: >> I don't want to bloody the waters, but one of the ways we (a bunch of >> us working on semantic interoperability at NC3A) decided to slice >> this >> particular cat was to put these extra "interpretation" axioms into a >> separate ontology which imports the two ontologies we want to relate.
>> E.g. create FOAF-DC-interpretation.owl which imports foaf and >> dc:terms, into which is added the statement that foaf:maker >> owl:equivalentProperty dcterms:creator.
>> This has the benefit of ring-fencing these potentially subjective >> assertions into their own named graph which you can take or leave in >> an application simply by importing or not this interpretation >> ontology.
>> The main issue we had was that while it's relatively easy in this >> kind >> of set-up to say who the authority is for a domain ontology, it's >> tricky to figure out who should be in charge of these interpretation >> ontologies. In the case of FOAF vs DC, it seems relatively >> straightforward for FOAF to publish a separate little ontology.
sketchy thought: in the case of external mappings you could delegate trust by using isDefinedBy, and further point to other non trusted (but not necessarily incorrect) mappings by using seeAlso.
other thought: "how do data consumers avoid malicious/broken mappings, and how do they choose between conflicting mappings, without relying on a trained expert to make the decision" replace the word mappings for data and use the same approach; widespread problems (as you know) and the whole "trust" thing is a major issue; only by delegating trust can you solve either problem.
> I would appreciate your thoughts on practical solutions to the problem > of conflicting and malicious mappings.
> As me and others have explained in this thread, manual methods for > picking which mappings to use and which to ignore are not feasible in > general on the Web. Any approach that requires manual decisions about > inclusion or exclusion of mappings will simply not work for a number of > significant use cases. Whatever other advantages the approach may have > is irrelevant -- it does not work, and quite frankly misses the topic of > this list.
> If mappings are externalised, then how do data consumers avoid > malicious/broken mappings, and how do they choose between conflicting > mappings, without relying on a trained expert to make the decision?
> Best, > Richard
> On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
>> My point of view on this topic somewhat differs from Aidan's and >> Richard's. I believe and would argue that what you propose, Alex, is >> actually *the* best practice.
>> Externalising mappings has a lot of advantage. >> 1) the vocabulary publisher does not have to update his/her >> vocabulary in function of the publication and adoption of other >> vocabularies. Vocabularies should concentrate on specifying their own >> terms, such that they can reach a certain stability. >> 2) external mappings are reusable independently from the ontologies. >> This is useful for a) combining them, e.g., by composing "chains of >> mappings"; b) improving mapping tools that exploit existing mappings; >> c) evaluating mapping tools; d) using them to produce a transformation >> function that mediates between two services using different >> vocabularies; e) et cetera. [1] >> 3) it makes modular reuse of vocabularies more flexible. Maybe one >> wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF >> and DC with different mappings, thus will import or reuse a different >> "mapping ontology". One can choose to reuse FOAF in conjunction with >> the dBPedia vocabulary rather than DC.
>> In any case, such mappings between existing vocabularies are deadly >> missing and I would encourage any initiative that favour publishing >> such mappings, be it independent from the vocabulary publishers or >> not. Such initiatives are actually taking place in the ontology >> matching / ontology design / ontology xyz communities but they have >> not yet gained enough momentum.
>> 2010/2/25 ajtucker <a.james.tuc...@googlemail.com>: >>> I don't want to bloody the waters, but one of the ways we (a bunch of >>> us working on semantic interoperability at NC3A) decided to slice this >>> particular cat was to put these extra "interpretation" axioms into a >>> separate ontology which imports the two ontologies we want to relate.
>>> E.g. create FOAF-DC-interpretation.owl which imports foaf and >>> dc:terms, into which is added the statement that foaf:maker >>> owl:equivalentProperty dcterms:creator.
>>> This has the benefit of ring-fencing these potentially subjective >>> assertions into their own named graph which you can take or leave in >>> an application simply by importing or not this interpretation >>> ontology.
>>> The main issue we had was that while it's relatively easy in this kind >>> of set-up to say who the authority is for a domain ontology, it's >>> tricky to figure out who should be in charge of these interpretation >>> ontologies. In the case of FOAF vs DC, it seems relatively >>> straightforward for FOAF to publish a separate little ontology.
On Mar 3, 3:03 pm, Richard Cyganiak <rich...@cyganiak.de> wrote:
> Antoine,
> I would appreciate your thoughts on practical solutions to the problem > of conflicting and malicious mappings.
> As me and others have explained in this thread, manual methods for > picking which mappings to use and which to ignore are not feasible in > general on the Web. Any approach that requires manual decisions about > inclusion or exclusion of mappings will simply not work for a number > of significant use cases.
such as?
> Whatever other advantages the approach may > have is irrelevant -- it does not work, and quite frankly misses the > topic of this list.
With all due respect, this is just your opinion. Coming to an understanding will be a longer conversation, but as a first step I would like to see a clear and rigorous articulation of your approach. What I have heard so far doesn't make any sense to me.
> If mappings are externalised, then how do data consumers avoid > malicious/broken mappings, and how do they choose between conflicting > mappings, without relying on a trained expert to make the decision?
The same way one decides what to accept when information is expressed in any other way. There is nothing special about RDF that permits formulaic decisions of what is right and what is wrong. There will always be differences of opinion, mistakes that need to be corrected, and situations requiring reinterpretation no matter how an idea is expressed. For some particular uses I may be able to write automatic filters (perhaps a different one for each use) that decides whether accepting a graph has acceptable risk. For others I may need to do my own reviews or hire an expert reviewer. Spam filters, net nannies, and peer review are all methods for vetting information, of varying automatic-ness.
I think you must have in mind some particular verifiable discipline for using RDF that permits some kind of useful automatic combination of unvetted RDF graphs. But I do not know what that discipline is or what its use cases are, so even if I wanted to use it I wouldn't know how or under what circumstances it would be useful. Please fill me in.
> On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
> > My point of view on this topic somewhat differs from Aidan's and > > Richard's. I believe and would argue that what you propose, Alex, is > > actually *the* best practice.
> > Externalising mappings has a lot of advantage. > > 1) the vocabulary publisher does not have to update his/her > > vocabulary in function of the publication and adoption of other > > vocabularies. Vocabularies should concentrate on specifying their own > > terms, such that they can reach a certain stability. > > 2) external mappings are reusable independently from the ontologies. > > This is useful for a) combining them, e.g., by composing "chains of > > mappings"; b) improving mapping tools that exploit existing mappings; > > c) evaluating mapping tools; d) using them to produce a transformation > > function that mediates between two services using different > > vocabularies; e) et cetera. [1] > > 3) it makes modular reuse of vocabularies more flexible. Maybe one > > wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF > > and DC with different mappings, thus will import or reuse a different > > "mapping ontology". One can choose to reuse FOAF in conjunction with > > the dBPedia vocabulary rather than DC.
> > In any case, such mappings between existing vocabularies are deadly > > missing and I would encourage any initiative that favour publishing > > such mappings, be it independent from the vocabulary publishers or > > not. Such initiatives are actually taking place in the ontology > > matching / ontology design / ontology xyz communities but they have > > not yet gained enough momentum.
> > 2010/2/25 ajtucker <a.james.tuc...@googlemail.com>: > >> I don't want to bloody the waters, but one of the ways we (a bunch of > >> us working on semantic interoperability at NC3A) decided to slice > >> this > >> particular cat was to put these extra "interpretation" axioms into a > >> separate ontology which imports the two ontologies we want to relate.
> >> E.g. create FOAF-DC-interpretation.owl which imports foaf and > >> dc:terms, into which is added the statement that foaf:maker > >> owl:equivalentProperty dcterms:creator.
> >> This has the benefit of ring-fencing these potentially subjective > >> assertions into their own named graph which you can take or leave in > >> an application simply by importing or not this interpretation > >> ontology.
> >> The main issue we had was that while it's relatively easy in this > >> kind > >> of set-up to say who the authority is for a domain ontology, it's > >> tricky to figure out who should be in charge of these interpretation > >> ontologies. In the case of FOAF vs DC, it seems relatively > >> straightforward for FOAF to publish a separate little ontology.
> I would appreciate your thoughts on practical solutions to the problem of > conflicting and malicious mappings.
One possible solution is to choose the mappings manually. After all, vocabularies are chosen manually by the people who publish data. They "manually" choose FOAF as a vocabulary for representing people. They "manually" choose DC to annotate the documents etc. They can as well "manually" choose the mappings. For instance, they could get a "mapping ontology" (or, I would rather say, an ontology alignment) which is mentioned explicitly on the FOAF project homepage or even in their spec. People can choose alignments that they trust using similar trust criteria as the ones used to choose vocabularies. This is just one possible solution. Some tools may apply an automatic assessment of the trust-level of vocabularies as well as alignments, which would lead to the automatic selection of alignments in function of the used vocabularies, and maybe in function of the user's preferences.
> As me and others have explained in this thread, manual methods for picking > which mappings to use and which to ignore are not feasible in general on the > Web. Any approach that requires manual decisions about inclusion or > exclusion of mappings will simply not work for a number of significant use > cases. Whatever other advantages the approach may have is irrelevant -- it > does not work, and quite frankly misses the topic of this list.
I admit that it is slightly out of topic for this list. I don't want to develop further on this here (we can discuss it elsewhere), but my point of view is that 1) external mappings *should* be externalised and 2) internal mappings *should* be avoided as much as possible. Note that one may want to build an ontology by reusing an existing vocabulary. This is a different issue which relates to modularity of ontologies rather than ontology matching. I am here talking about relating pre-existing vocabularies (which is what is done between foaf:Agent and dc:Agent, which were preexisting and defined before the new axiom "equivalentTo" was introduced).
> If mappings are externalised, then how do data consumers avoid > malicious/broken mappings, and how do they choose between conflicting > mappings, without relying on a trained expert to make the decision?
Just the same way they choose between conflicting vocabularies.
> On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
>> My point of view on this topic somewhat differs from Aidan's and >> Richard's. I believe and would argue that what you propose, Alex, is >> actually *the* best practice.
>> Externalising mappings has a lot of advantage. >> 1) the vocabulary publisher does not have to update his/her >> vocabulary in function of the publication and adoption of other >> vocabularies. Vocabularies should concentrate on specifying their own >> terms, such that they can reach a certain stability. >> 2) external mappings are reusable independently from the ontologies. >> This is useful for a) combining them, e.g., by composing "chains of >> mappings"; b) improving mapping tools that exploit existing mappings; >> c) evaluating mapping tools; d) using them to produce a transformation >> function that mediates between two services using different >> vocabularies; e) et cetera. [1] >> 3) it makes modular reuse of vocabularies more flexible. Maybe one >> wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF >> and DC with different mappings, thus will import or reuse a different >> "mapping ontology". One can choose to reuse FOAF in conjunction with >> the dBPedia vocabulary rather than DC.
>> In any case, such mappings between existing vocabularies are deadly >> missing and I would encourage any initiative that favour publishing >> such mappings, be it independent from the vocabulary publishers or >> not. Such initiatives are actually taking place in the ontology >> matching / ontology design / ontology xyz communities but they have >> not yet gained enough momentum.
>>> I don't want to bloody the waters, but one of the ways we (a bunch of >>> us working on semantic interoperability at NC3A) decided to slice this >>> particular cat was to put these extra "interpretation" axioms into a >>> separate ontology which imports the two ontologies we want to relate.
>>> E.g. create FOAF-DC-interpretation.owl which imports foaf and >>> dc:terms, into which is added the statement that foaf:maker >>> owl:equivalentProperty dcterms:creator.
>>> This has the benefit of ring-fencing these potentially subjective >>> assertions into their own named graph which you can take or leave in >>> an application simply by importing or not this interpretation >>> ontology.
>>> The main issue we had was that while it's relatively easy in this kind >>> of set-up to say who the authority is for a domain ontology, it's >>> tricky to figure out who should be in charge of these interpretation >>> ontologies. In the case of FOAF vs DC, it seems relatively >>> straightforward for FOAF to publish a separate little ontology.
> sketchy thought: in the case of external mappings you could delegate > trust by using isDefinedBy,
or even owl:imports, which is pretty much designed for delegating trust (although it doesn't say so).
> and further point to other non trusted (but > not necessarily incorrect) mappings by using seeAlso.
> other thought: "how do data consumers avoid malicious/broken mappings, > and how do they choose between conflicting mappings, without relying > on > a trained expert to make the decision" replace the word mappings for > data and use the same approach; widespread problems (as you know) and > the whole "trust" thing is a major issue; only by delegating trust can > you solve either problem.
Yes. But for data (as opposed to term definitions) the problem is slightly less severe. Quite often, if an RDF-based application is faced with potentially conflicting or broken data, it will simply present that data in all its anti-glory to the user; people are quite good at sorting out that kind of stuff, so this works reasonably well. In sig.ma we have tried to embrace this kind of approach.
With term definitions it's harder, because we want to perform inferencing using the definitions, so we cannot simply throw the conflicts at the user to sort out, but need to resolve them based on some algorithm.
But I agree that trust delegation is a workable solution. I guess that using a class (in an rdf:type statement) and using a property (in predicate position) implies trust delegation to the term-defining document. So does owl:imports, and perhaps a few other properties. I'm not aware of any place where someone has worked out or documented the details of this though.
>> I would appreciate your thoughts on practical solutions to the >> problem >> of conflicting and malicious mappings.
>> As me and others have explained in this thread, manual methods for >> picking which mappings to use and which to ignore are not feasible in >> general on the Web. Any approach that requires manual decisions about >> inclusion or exclusion of mappings will simply not work for a >> number of >> significant use cases. Whatever other advantages the approach may >> have >> is irrelevant -- it does not work, and quite frankly misses the >> topic of >> this list.
>> If mappings are externalised, then how do data consumers avoid >> malicious/broken mappings, and how do they choose between conflicting >> mappings, without relying on a trained expert to make the decision?
>> Best, >> Richard
>> On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
>>> My point of view on this topic somewhat differs from Aidan's and >>> Richard's. I believe and would argue that what you propose, Alex, >>> is >>> actually *the* best practice.
>>> Externalising mappings has a lot of advantage. >>> 1) the vocabulary publisher does not have to update his/her >>> vocabulary in function of the publication and adoption of other >>> vocabularies. Vocabularies should concentrate on specifying their >>> own >>> terms, such that they can reach a certain stability. >>> 2) external mappings are reusable independently from the ontologies. >>> This is useful for a) combining them, e.g., by composing "chains of >>> mappings"; b) improving mapping tools that exploit existing >>> mappings; >>> c) evaluating mapping tools; d) using them to produce a >>> transformation >>> function that mediates between two services using different >>> vocabularies; e) et cetera. [1] >>> 3) it makes modular reuse of vocabularies more flexible. Maybe one >>> wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF >>> and DC with different mappings, thus will import or reuse a >>> different >>> "mapping ontology". One can choose to reuse FOAF in conjunction with >>> the dBPedia vocabulary rather than DC.
>>> In any case, such mappings between existing vocabularies are deadly >>> missing and I would encourage any initiative that favour publishing >>> such mappings, be it independent from the vocabulary publishers or >>> not. Such initiatives are actually taking place in the ontology >>> matching / ontology design / ontology xyz communities but they have >>> not yet gained enough momentum.
>>> [1] This is extensively discussed by the ontology matching >>> community. >>> Read more on http://www.ontologymatching.org/.
>>> Regards, >>> AZ.
>>> 2010/2/25 ajtucker <a.james.tuc...@googlemail.com>: >>>> I don't want to bloody the waters, but one of the ways we (a >>>> bunch of >>>> us working on semantic interoperability at NC3A) decided to slice >>>> this >>>> particular cat was to put these extra "interpretation" axioms >>>> into a >>>> separate ontology which imports the two ontologies we want to >>>> relate.
>>>> E.g. create FOAF-DC-interpretation.owl which imports foaf and >>>> dc:terms, into which is added the statement that foaf:maker >>>> owl:equivalentProperty dcterms:creator.
>>>> This has the benefit of ring-fencing these potentially subjective >>>> assertions into their own named graph which you can take or leave >>>> in >>>> an application simply by importing or not this interpretation >>>> ontology.
>>>> The main issue we had was that while it's relatively easy in this >>>> kind >>>> of set-up to say who the authority is for a domain ontology, it's >>>> tricky to figure out who should be in charge of these >>>> interpretation >>>> ontologies. In the case of FOAF vs DC, it seems relatively >>>> straightforward for FOAF to publish a separate little ontology.
2010/3/3 Jonathan Rees <jonathan.r...@gmail.com>: [...]
> I think users would be served better by having a common OWL-DL version > of DC, whether provided by DCMI or by someone else.
I have made a small vocabulary [1] that may be of some help in this case. In this vocabulary, there are annotation properties that should be used to refer to "alternative versions" of an ontology.
For instance, an ontology could have an OWL Full version as well as an OWL DL version. Let assume the Full version is the main (or preferred) ontology version. It can say:
elVersion, qlVersion, rlVersion refer to the new OWL 2 Profiles (OWL 2 EL, QL, RL) that are subsets of OWL 2 DL with "nice" computational properties.
There is also a generic "yoda:altVersion" to refer to any alternative version of the ontology and "yoda:preferredVersion" that can point towards the "main" ontology version. Finally, I've put the legacy versions for OWL 1 DL and OWL 1 Lite. (yoda:dl1Version and yoda:liteVersion).
According to these properties, a user agent can choose whatever alternative version suites it better for its own purposes.
DC could simply refer to alternative versions declaring the type of each property (Datatype/Object/Annotation). What is not clear, however, is what a user agent should do if several suitable alternatives are mentioned this way.
Anyway, the yoda vocabulary is still in a preliminary state, missing some neat documentation. Please send feedback to me rather than to the Pedantic Web list.
[1] Yoda: a vocabulary routing Semantic Web tools to the right ontology profile. http://purl.org/NET/yoda -- --AZ
On 4 Mar 2010, at 17:18, Antoine Zimmermann wrote:
> 2010/3/3 Richard Cyganiak <rich...@cyganiak.de>: >> Antoine,
>> I would appreciate your thoughts on practical solutions to the >> problem of >> conflicting and malicious mappings.
> One possible solution is to choose the mappings manually. After all, > vocabularies are chosen manually by the people who publish data.
Vocabularies are chosen by the *publisher*. If you are saying that publishers should also choose their mappings, then I'm fine with that response.
But I want to make clear that data *consumers* cannot manually choose mappings. That's infeasible. You cannot expect everyone who browses in Tabulator, or does a search in Sigma, or wants to run some SPARQL query against data.gov.uk, to first select a set of mapping ontologies for the job. Not to mention completely automated systems like the Sindice indexer or SOAR, that materialize inferences at indexing time before a user is in the loop.
> my > point of view is that 1) external mappings *should* be externalised > and 2) internal mappings *should* be avoided as much as possible.
Well I gathered this much. But why?
You are probably well aware that almost all popular vocabularies include at least some “internal” mappings. Are you saying that these should be removed?
> Note that one may want to build an ontology by reusing an existing > vocabulary. This is a different issue which relates to modularity of > ontologies rather than ontology matching. I am here talking about > relating pre-existing vocabularies (which is what is done between > foaf:Agent and dc:Agent, which were preexisting and defined before the > new axiom "equivalentTo" was introduced).
I don't know why there should be a difference between relating pre- existing vocabularies and relating a new vocabulary to existing vocabularies. Isn't the end result the same (two vocabularies with mappings between them)?
>> If mappings are externalised, then how do data consumers avoid >> malicious/broken mappings, and how do they choose between conflicting >> mappings, without relying on a trained expert to make the decision?
> Just the same way they choose between conflicting vocabularies.
Data consumers don't have to choose between conflicting vocabularies.
>> On 3 Mar 2010, at 19:17, Antoine Zimmermann wrote:
>>> My point of view on this topic somewhat differs from Aidan's and >>> Richard's. I believe and would argue that what you propose, Alex, >>> is >>> actually *the* best practice.
>>> Externalising mappings has a lot of advantage. >>> 1) the vocabulary publisher does not have to update his/her >>> vocabulary in function of the publication and adoption of other >>> vocabularies. Vocabularies should concentrate on specifying their >>> own >>> terms, such that they can reach a certain stability. >>> 2) external mappings are reusable independently from the ontologies. >>> This is useful for a) combining them, e.g., by composing "chains of >>> mappings"; b) improving mapping tools that exploit existing >>> mappings; >>> c) evaluating mapping tools; d) using them to produce a >>> transformation >>> function that mediates between two services using different >>> vocabularies; e) et cetera. [1] >>> 3) it makes modular reuse of vocabularies more flexible. Maybe one >>> wants to reuse FOAF but not DC at all. Maybe one wants to reuse FOAF >>> and DC with different mappings, thus will import or reuse a >>> different >>> "mapping ontology". One can choose to reuse FOAF in conjunction with >>> the dBPedia vocabulary rather than DC.
>>> In any case, such mappings between existing vocabularies are deadly >>> missing and I would encourage any initiative that favour publishing >>> such mappings, be it independent from the vocabulary publishers or >>> not. Such initiatives are actually taking place in the ontology >>> matching / ontology design / ontology xyz communities but they have >>> not yet gained enough momentum.
>>> [1] This is extensively discussed by the ontology matching >>> community. >>> Read more on http://www.ontologymatching.org/.
>>>> I don't want to bloody the waters, but one of the ways we (a >>>> bunch of >>>> us working on semantic interoperability at NC3A) decided to slice >>>> this >>>> particular cat was to put these extra "interpretation" axioms >>>> into a >>>> separate ontology which imports the two ontologies we want to >>>> relate.
>>>> E.g. create FOAF-DC-interpretation.owl which imports foaf and >>>> dc:terms, into which is added the statement that foaf:maker >>>> owl:equivalentProperty dcterms:creator.
>>>> This has the benefit of ring-fencing these potentially subjective >>>> assertions into their own named graph which you can take or leave >>>> in >>>> an application simply by importing or not this interpretation >>>> ontology.
>>>> The main issue we had was that while it's relatively easy in this >>>> kind >>>> of set-up to say who the authority is for a domain ontology, it's >>>> tricky to figure out who should be in charge of these >>>> interpretation >>>> ontologies. In the case of FOAF vs DC, it seems relatively >>>> straightforward for FOAF to publish a separate little ontology.
Richard Cyganiak wrote: > On 4 Mar 2010, at 17:18, Antoine Zimmermann wrote: >> 2010/3/3 Richard Cyganiak <rich...@cyganiak.de>: >>> Antoine,
>>> I would appreciate your thoughts on practical solutions to the >>> problem of >>> conflicting and malicious mappings.
>> One possible solution is to choose the mappings manually. After all, >> vocabularies are chosen manually by the people who publish data.
> Vocabularies are chosen by the *publisher*. If you are saying that > publishers should also choose their mappings, then I'm fine with that > response.
> But I want to make clear that data *consumers* cannot manually choose > mappings. That's infeasible. You cannot expect everyone who browses in > Tabulator, or does a search in Sigma, or wants to run some SPARQL query > against data.gov.uk, to first select a set of mapping ontologies for the > job. Not to mention completely automated systems like the Sindice > indexer or SOAR, that materialize inferences at indexing time before a > user is in the loop.
but should body start up like DCMI (note like, not specifically them) that wishes to invest expertise of specialists in to doing mapping between widely used ontologies then the owl:imports could surely be used to delegate trust to third party; without breaking anything and letting you the publisher get on with refining you're own ontology and working on your systems ?
ps: for what it's worth I totally agree that clients shouldn't be expected to do the mapping, at the same time though some will - even just for crazy experimental reasons (like I may choose to map vcard:Location, latitude and longitude to the geo:lat,long etc).
>>>> I would appreciate your thoughts on practical solutions to the >>>> problem of >>>> conflicting and malicious mappings.
>>> One possible solution is to choose the mappings manually. After >>> all, >>> vocabularies are chosen manually by the people who publish data.
>> Vocabularies are chosen by the *publisher*. If you are saying that >> publishers should also choose their mappings, then I'm fine with that >> response.
>> But I want to make clear that data *consumers* cannot manually choose >> mappings. That's infeasible. You cannot expect everyone who browses >> in >> Tabulator, or does a search in Sigma, or wants to run some SPARQL >> query >> against data.gov.uk, to first select a set of mapping ontologies >> for the >> job. Not to mention completely automated systems like the Sindice >> indexer or SOAR, that materialize inferences at indexing time >> before a >> user is in the loop.
> but should body start up like DCMI (note like, not specifically them) > that wishes to invest expertise of specialists in to doing mapping > between widely used ontologies
I think this is to some extent what UMBEL is trying to do, although I haven't looked into the mechanisms they use for publishing their mappings.
> then the owl:imports could surely be used > to delegate trust to third party; without breaking anything and > letting > you the publisher get on with refining you're own ontology and working > on your systems ?
Do you mean: If I use vocabulary X to express some data, and X doesn't have mappings to Y, but some third party has published mappings between X and Y, then I could owl:import these mappings in order to allow clients that are programmed against Y to understand my data? Yes, I think that would be a good idea. So by using X I indicate my trust for X, and by importing the mapping I indicate my trust for that mapping.
> ps: for what it's worth I totally agree that clients shouldn't be > expected to do the mapping, at the same time though some will - even > just for crazy experimental reasons (like I may choose to map > vcard:Location, latitude and longitude to the geo:lat,long etc).
> On 4 Mar 2010, at 20:51, Nathan wrote: >>>>> I would appreciate your thoughts on practical solutions to the >>>>> problem of >>>>> conflicting and malicious mappings.
>>>> One possible solution is to choose the mappings manually. After all, >>>> vocabularies are chosen manually by the people who publish data.
>>> Vocabularies are chosen by the *publisher*. If you are saying that >>> publishers should also choose their mappings, then I'm fine with that >>> response.
>>> But I want to make clear that data *consumers* cannot manually choose >>> mappings. That's infeasible. You cannot expect everyone who browses in >>> Tabulator, or does a search in Sigma, or wants to run some SPARQL query >>> against data.gov.uk, to first select a set of mapping ontologies for the >>> job. Not to mention completely automated systems like the Sindice >>> indexer or SOAR, that materialize inferences at indexing time before a >>> user is in the loop.
>> but should body start up like DCMI (note like, not specifically them) >> that wishes to invest expertise of specialists in to doing mapping >> between widely used ontologies
> I think this is to some extent what UMBEL is trying to do, although I > haven't looked into the mechanisms they use for publishing their mappings.
>> then the owl:imports could surely be used >> to delegate trust to third party; without breaking anything and letting >> you the publisher get on with refining you're own ontology and working >> on your systems ?
> Do you mean: If I use vocabulary X to express some data, and X doesn't > have mappings to Y, but some third party has published mappings between > X and Y, then I could owl:import these mappings in order to allow > clients that are programmed against Y to understand my data? Yes, I > think that would be a good idea. So by using X I indicate my trust for > X, and by importing the mapping I indicate my trust for that mapping.
that is exactly what I mean :)
and it leads me on to a further "will this work" question which I've been thinking about for weeks.. but will wait a while before I ask properly!
