FOAF and dcterms:creator/dcterms:Agent
Hogan, Aidan
So, I just noted in the new version of FOAF that you relate foaf:maker
to dcterms:creator using owl:equivalentProperty. This seems contrary to
precedent elsewhere in the specification, where you use
subclass/subproperty relations to relate local terms with external
terms.
My main concern is that FOAF is mandating the translation of
dcterms:creator triples into foaf:maker triples, somehow "redefining"
the external dcterms:creator term as a subproperty of foaf:maker. As
general vocabulary etiquette, I would prefer to see vocabularies purely
extend external terms, and avoid saying anything about external terms
which will affect reasoning on the "instance triples" which use them.
Such cross-definition of terms across vocabularies on the Web will
quickly become really messy. I would prefer to see more of a "modular
design" etiquette -- something I already viewed as an "unspoken rule"
amongst the more popular Web vocabularies -- in which, for example,
reasoning over dcterms: instance data is precisely the same whether you
include only the dcterms: vocabulary, or include dcterms: and foaf:
vocabularies. Instead of using the owl:equivalentProperty relation --
thus implicitly stating that dcterms:creator is a sub-property of
foaf:maker (somehow on the behalf of dcterms) -- I would prefer if FOAF
stated:
foaf:maker rdfs:subPropertyOf dcterms:creator .
and then ask the maintainers of dcterms to add the "backward-link" ( :O
) on their end -- i.e., let them decide if they want to translate
dcterms: instance data into the respective foaf: terms.
Similarly, you use an owl:equivalentClass relation between dcterms:Agent
and foaf:Agent.
Was just wondering what the thoughts are on this topic, would the FOAF
folk agree with the importance of "modular design" for vocabularies, and
why the owl:equivalentXXX relations were chosen over rdfs:subXXXOf
relations in the current version of FOAF. I would also like to hear
Tom's perspective on this, with respect to the DC side of things. I am
particularly concerned because FOAF sets an example for Web vocabularies
-- my concern here is that FOAF might be setting a really bad precedent.
In the reasoning engine I work on for RDF Web data, we enforce much a
model of "modular" term re-use, and ignore cross-definitions as
exemplified above -- ironically, we first encountered the need for
ignoring cross-definitions to protect FOAF terms, which were commonly
redefined by third-parties.
Thoughts/rebukes welcome,
Aidan
On a side note, please don't remove the foaf:name subproperty relation
to rdfs:label -- in general, (and this is purely my own personal
opinion, and probably arguable) I dislike Web vocabularies bending over
backwards to be DL compliant, and in any case, you are already
non-compliant with mbox_sha1sum defined as an inverse-functional
property (if a vocabulary can *easily* be made OWL DL, OWL Lite, OWL
EL... compliant without losing *much*, then fair enough).
As you probably already know, many systems use the
rdfs:label/rdfs:comment properties as 'hooks' for displaying information
(the name and description of an entity -- would love to see every entity
described in RDF have at least a label/comment or super-property thereof
defined). In the absence of a viable and agreed-upon alternative, please
(please, please) leave foaf:name as a subproperty of rdfs:label.
Similarly, I would *love* to see dc:title made as a subproperty of
rdfs:label, and dc:description made as a subproperty of rdfs:comment.
But that's perhaps a different topic.
Dan Brickley
> Hey folks,
>
> So, I just noted in the new version of FOAF that you relate foaf:maker
> to dcterms:creator using owl:equivalentProperty. This seems contrary to
> precedent elsewhere in the specification, where you use
> subclass/subproperty relations to relate local terms with external
> terms.
Hi there,
They mean the same thing. They are true under the same conditions. The
equivalentProperty claim merely documents that. Nobody is forcing
anyone to create triples! Honestly :)
Dan
Damian Steer
On 23 Feb 2010, at 20:47, Hogan, Aidan wrote:
> Hey folks,
>
> So, I just noted in the new version of FOAF that you relate foaf:maker
> to dcterms:creator using owl:equivalentProperty. This seems contrary to
> precedent elsewhere in the specification, where you use
> subclass/subproperty relations to relate local terms with external
> terms.
>
> My main concern is that FOAF is mandating the translation of
> dcterms:creator triples into foaf:maker triples, somehow "redefining"
> the external dcterms:creator term as a subproperty of foaf:maker. As
> general vocabulary etiquette, I would prefer to see vocabularies purely
> extend external terms, and avoid saying anything about external terms
> which will affect reasoning on the "instance triples" which use them.
In general I'd agree with much of this, but this particular case seems entirely reasonable. I really can't see there's any difference between the terms. That both exist is unfortunate, but that's what history has provided.
foaf:maker rdfs:subPropertyOf dc:creator .
is ok, but doesn't project the foaf:maker claims into dc land.
dc:creator rdfs:subPropertyOf foaf:maker .
would be very useful for dc-consumers, giving them access to the foaf corners of the web.
Damian
Hogan, Aidan
> They mean the same thing. They are true under the same conditions. The
> equivalentProperty claim merely documents that.
Ah yes... but applying that logic, I'd be looking at a lot more
equivalentClass and equivalentProperty relations in FOAF... unless the
class http://www.w3.org/2000/10/swap/pim/contact#Person includes some
form of hybrid mutant people that foaf:Person doesn't? :) :P
To clarify, I have no problem with the equivalentProperty claim in its
own right. My question and argument is more philosophical with respect
to how vocabularies re-use and extend other vocabularies.
My root (purposefully leading) question is this:
Do we want each vocabulary to have a distinct view on the world,
possibly cross-defining terms in other vocabularies?
Or do we only allow vocabularies to cleanly extend other vocabularies,
contributing its own independent set of terms to model the world, thus
following modular design practices?
Cheers,
Aidan
Story Henry
On 23 Feb 2010, at 22:13, Damian Steer wrote:
> On 23 Feb 2010, at 20:47, Hogan, Aidan wrote:
>
>> Hey folks,
>>
>> So, I just noted in the new version of FOAF that you relate foaf:maker
>> to dcterms:creator using owl:equivalentProperty. This seems contrary to
>> precedent elsewhere in the specification, where you use
>> subclass/subproperty relations to relate local terms with external
>> terms.
>>
>> My main concern is that FOAF is mandating the translation of
>> dcterms:creator triples into foaf:maker triples, somehow "redefining"
>> the external dcterms:creator term as a subproperty of foaf:maker. As
>> general vocabulary etiquette, I would prefer to see vocabularies purely
>> extend external terms, and avoid saying anything about external terms
>> which will affect reasoning on the "instance triples" which use them.
It is in the html, but not in the RDF, so not much damage done.
There is indeed a problem on this which we were discussing today on the mailing list. The spec also says
[[
When describing a PersonalProfileDocument it is typical (and useful) to describe its associated Person using the maker property. Anything that is a Person and that is the maker of some Document will be the primaryTopic of that Document. Although this can be inferred, it is helpful to include this information explicitly within the PersonalProfileDocument.
]]
And I would think that dc:creator would be more neutral as to the creator having to be the primary topic too.
Nathan
> On 23 Feb 2010, at 22:13, Damian Steer wrote:
>> On 23 Feb 2010, at 20:47, Hogan, Aidan wrote:
>>
>>> Hey folks,
>>>
>>> So, I just noted in the new version of FOAF that you relate foaf:maker
>>> to dcterms:creator using owl:equivalentProperty. This seems contrary to
>>> precedent elsewhere in the specification, where you use
>>> subclass/subproperty relations to relate local terms with external
>>> terms.
>>>
>>> My main concern is that FOAF is mandating the translation of
>>> dcterms:creator triples into foaf:maker triples, somehow "redefining"
>>> the external dcterms:creator term as a subproperty of foaf:maker. As
>>> general vocabulary etiquette, I would prefer to see vocabularies purely
>>> extend external terms, and avoid saying anything about external terms
>>> which will affect reasoning on the "instance triples" which use them.
>
> It is in the html, but not in the RDF, so not much damage done.
>
> There is indeed a problem on this which we were discussing today on the mailing list. The spec also says
>
> [[
> When describing a PersonalProfileDocument it is typical (and useful) to describe its associated Person using the maker property. Anything that is a Person and that is the maker of some Document will be the primaryTopic of that Document. Although this can be inferred, it is helpful to include this information explicitly within the PersonalProfileDocument.
> ]]
>
> And I would think that dc:creator would be more neutral as to the creator having to be the primary topic too.
I just read that to read "only use foaf:maker inside a foaf profile
(PersonalProfileDocument) - ie don't use it anywhere else. is that
correct???
Tom Baker
The DCMI Usage Board discussed this at its meeting last October
[1]. We agreed in principle to make an equivalent assertion but
took an action to explore whether this should more properly be
done with mutual sub-property assertions or with
owl:equivalentProperty.
It just so happened that I had the rare opportunity two weeks
later to discuss this very question at a VoCamp in Washington DC
with Richard Cyganiak, Pat Hayes, and Jon Phipps. In that
discussion, we came to the conclusion that making two mutual
sub-property assertions would be preferable, because the two
statements taken together would be logically equivalent to
owl:equivalentProperty, but they would be attaining this
equivalence through the _socially_ significant act of
mutual agreement.
If I understand Aidan's concern, his is an issue that also came
up in the discussion: the notion that one would seem to
"project" triples onto external terms that may be unwarranted -
possibly constituting a form of "namespace hijacking".
We left the meeting resolved to write this up as a proposed best
practice for discussion on a list somewhere. On further
reflection, however, Richard then leaned back towards the
argument that if you think they are equivalent, "why not just
say so" with owl:equivalentProperty (an argument hard
to refute), and concluded that his DERI colleague's
notion of "hijacking" would not really apply. And in the
meantime, Dan has now used owl:equivalentProperty in FOAF.
I still have a slight preference for the subProperty option
because I think it is in general a bit more polite and avoids
implying that one party really understands the intended
semantics of the other property well enough to make the stronger
statement.
At any rate, it has been on my to-do list for a long time to
follow up on this, so I would be interested in hearing opinions
on this list. DCMI is in principle ready to make such a
statement, and if opinions tend towards owl:equivalentProperty,
I for one would not object.
Either way, however, I do see this particular equivalence as a
small but precedent-setting test case for the sorts of mapping
assertions that should probably be encouraged more generally.
Alot of equivalent properties are going to be coined (or
discovered after the fact), so the need to assert mappings will
only grow. In this particular case, I believe we do understand
the intended semantics to make a strong statement, but do we
want to encourage people to make such strong statements in general?
Whichever way we settle this, I would welcome volunteers to help
us vet a one-page explanation for publication by DCMI laying out
the issue and articulating the rationale for the approach we end
up following - as a stake in the ground for good practice.
Tom
[1] http://dublincore.org/usage/minutes/2009/2009-10-16.dcub-meeting-seoul-minutes.html
--
Tom Baker <tba...@tbaker.de>
Damian Steer
On 23 Feb 2010, at 21:49, Hogan, Aidan wrote:
> Hey Dan,
>
>> They mean the same thing. They are true under the same conditions. The
>> equivalentProperty claim merely documents that.
>
> Ah yes... but applying that logic, I'd be looking at a lot more
> equivalentClass and equivalentProperty relations in FOAF... unless the
> class http://www.w3.org/2000/10/swap/pim/contact#Person includes some
> form of hybrid mutant people that foaf:Person doesn't? :) :P
Missing isn't broken :-)
> My root (purposefully leading) question is this:
>
> Do we want each vocabulary to have a distinct view on the world,
> possibly cross-defining terms in other vocabularies?
>
> Or do we only allow vocabularies to cleanly extend other vocabularies,
> contributing its own independent set of terms to model the world, thus
> following modular design practices?
As far as I can see dc11:creator might well have been used if it had been suitable, but the range issue was a problem. So foaf:maker filled the gap. Now we have dc:creator which is just the same, and that equivalence is documented.
Is that a 'dirty' extension? I think it runs the risk that another party (namely dc) could alter the meaning of the term. But that's also true of the subproperty case, were dc to strengthen maker to something like 'creator (in a particular legal sense)'.
For third parties it is clear who is making the equivalence claim.
Damian
Hogan, Aidan
the
> mailing list. The spec also says
>
> [[
> a Person and that is the maker of some Document will be the
primaryTopic
> of that Document. Although this can be inferred, it is helpful to
include
> this information explicitly within the PersonalProfileDocument.
> ]]
>
Hmm... to me, this text is very strange, and does not reflect the
underlying vocabulary (i.e., maker is not a subproperty of primaryTopic,
nor should it be IMO). My two cents: drop this text.
Cheers,
Aidan
Dan Brickley
Yes, that loks like a bug: it should say PersonalProfileDocument
there, not just any old Document! Oops :)
The wording of that whole section is really awkward, and needs a
rewrite. Good catch...
cheers,
Dan
Hogan, Aidan
I think that Tom has nicely summarised the issue, so I'll try wrap up using Tom's discussion.
> It just so happened that I had the rare opportunity two weeks
> later to discuss this very question at a VoCamp in Washington DC
> with Richard Cyganiak, Pat Hayes, and Jon Phipps. In that
> discussion, we came to the conclusion that making two mutual
> sub-property assertions would be preferable, because the two
> statements taken together would be logically equivalent to
> owl:equivalentProperty, but they would be attaining this
> equivalence through the _socially_ significant act of
> mutual agreement.
+1.
> If I understand Aidan's concern, his is an issue that also came
> up in the discussion: the notion that one would seem to
> "project" triples onto external terms that may be unwarranted -
> possibly constituting a form of "namespace hijacking".
+1.
> We left the meeting resolved to write this up as a proposed best
> practice for discussion on a list somewhere. On further
> reflection, however, Richard then leaned back towards the
> argument that if you think they are equivalent, "why not just
> say so" with owl:equivalentProperty (an argument hard
> to refute), and concluded that his DERI colleague's
> notion of "hijacking" would not really apply.
That's me :). Strictly speaking, the notion of "hijacking" does apply -- FOAF has affected reasoning over 'instance triples' using DC terms. We purposefully chose a term with negative connotations to discourage such practice. We found documents on the Web which, e.g., define the domain of rdf:type as nine of it's local properties [line 602, 1] or define foaf:Image as a property [line 270, 2] -- you could also pick through [3] for some more examples of FOAF/DC "hijacking".
Not to get too detailed, but in our reasoning, we need to create a global model (T-Box) of classes and properties, and we found that the only reasonable way to do this is to ignore such "hijacking" of terms -- the vocabularies above probably never even intended to be considered at a global context. Granted, not all such hijacking is as clear-cut as the above examples, but we felt that our approach was in-tune with current vocabulary best-practices.
(Again, not to get too detailed but other sensible web reasoning regimes exist which create a model per document and would consider everything being said, but only within a local scope. Such reasoning would not work so well given our particular environment/use-case.)
Again, the problem I'm trying to address is not specific to the maker/creator Agent/Agent case, it is the precedent that FOAF sets. I believe that a better precedent could be set by FOAF and DC using mutual subproperty relations -- I had thought that FOAF always had this precedent in mind, exemplified by not making equivalent relations to (for example) the http://www.w3.org/2000/10/swap/pim/contact#Person term.
> I still have a slight preference for the subProperty option
> because I think it is in general a bit more polite and avoids
> implying that one party really understands the intended
> semantics of the other property well enough to make the stronger
> statement.
+1. Besides "politeness" and the notion of "namespace sovereignty" that such usage implies, I think that the mutual subproperty option leads to a better design/re-use principle (relating to modularity) for vocabularies on the Web. (To maybe refer to Damian's earlier point about subproperty relations to remote terms also creating a dependency on remote vocabularies, at least such usage is "opt-in" -- this is then more a problem with versioning in vocabularies.)
> Either way, however, I do see this particular equivalence as a
> small but precedent-setting test case for the sorts of mapping
> assertions that should probably be encouraged more generally.
+4 (or maybe even 5).
> Alot of equivalent properties are going to be coined (or
> discovered after the fact), so the need to assert mappings will
> only grow. In this particular case, I believe we do understand
> the intended semantics to make a strong statement, but do we
> want to encourage people to make such strong statements in general?
>
> Whichever way we settle this, I would welcome volunteers to help
> us vet a one-page explanation for publication by DCMI laying out
> the issue and articulating the rationale for the approach we end
> up following - as a stake in the ground for good practice.
Sign me up :).
Cheers,
Aidan
[1] http://www.eiao.net/rdf/1.0
[2] http://wiki.sembase.at/index.php/Special:ExportRDF/Dieter_Fensel
[3] http://pike.kw.nl/files/documents/pietzwart/RDF/PietZwart200602.owl
Antoine Zimmermann
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.
More generally, whenever possible, it is good to use the RDFS
vocabulary in conjunction with the OWL vocabulary, to preserve
compatibility with both OWL tools and RDFS tools.
For instance, if you are defining an OWL class, type it as an
rdfs:Class as well. If you define an ObjectProperty, DatatypeProperty
or AnnotationProperty, type it as an rdf:Property as well. When
convenient, use rdfs:subPropertyOf.
Another example is whenever you want to define a class as a subclass
of an intersection. In such case, don't define the intersection at
all, just assert that your class is a subclass of both the classes.
E.g., don't write:
:Seaplane rdfs:subClassOf [ a owl:Class ;
owl:intersectionOf ( :Plane :Boat ) ] .
write instead:
:Seaplane rdfs:subClassOf :Plane, :Boat .
it is equivalent from an OWL point of view, but completely different
from an RDFS perspective. In the first case, :Seaplane is a subclass
of an unknown and meaningless class (from an RDFS view). In the
second case, it is, rightly so, a subclass of Plane and a subclass of
Boat.
Regards,
--
--AZ
Laurian Gridinoc
I guess we're kinda getting outside the remit of the pedantic-web. This is not a clear-cut issue for resolution, but a more general discussion -- and an important one at that -- on vocabulary re-use. I had kinda [perhaps naïvely :)] hoped that agreement could quickly be reached here to do mutual sub-property/-class relations between the two vocabularies, as is my personal preference.
Antoine Zimmermann
> Hello,
> On 24 Feb 2010, at 16:35, Hogan, Aidan wrote:
>
> I guess we're kinda getting outside the remit of the pedantic-web. This is
> not a clear-cut issue for resolution, but a more general discussion -- and
> an important one at that -- on vocabulary re-use. I had kinda [perhaps
> naïvely :)] hoped that agreement could quickly be reached here to do mutual
> sub-property/-class relations between the two vocabularies, as is my
> personal preference.
>
> I was wondering if it is good to promote such bidirectional links, ignore
> for the moment the semantics, just look at:
> foaf:maker rdfs:subPropertyOf dcterms:creator .
> dcterms:creator rdfs:subPropertyOf foaf:maker .
Actually, what Aidan is promoting is rather the opposite.
owl:equivalentProperty has *exactly* the same meaning as:
foaf:maker rdfs:subPropertyOf dcterms:creator .
dcterms:creator rdfs:subPropertyOf foaf:maker .
together in one statement. What Aidan says is that you should not have
both statements together because they somewhat impose a
"bidirectional" relation. So, one should rather say:
foaf:maker rdfs:subPropertyOf dcterms:creator .
and let the other side [the Dublin Core] decides whether they want to
link back or not (quite the same as a hyperlink, in fact).
--
--AZ
Richard Cyganiak
>> I guess we're kinda getting outside the remit of the pedantic-web.
>> This is not a clear-cut issue for resolution, but a more general
>> discussion -- and an important one at that -- on vocabulary re-use.
>> I had kinda [perhaps naïvely :)] hoped that agreement could quickly
>> be reached here to do mutual sub-property/-class relations between
>> the two vocabularies, as is my personal preference.
>
> I was wondering if it is good to promote such bidirectional links,
Aidan didn't talk about promoting bidirectional links. He talked about
the best property to use for expressing a bidirectional link on which
both sides agree.
> ignore for the moment the semantics, just look at:
>
> foaf:maker rdfs:subPropertyOf dcterms:creator .
> dcterms:creator rdfs:subPropertyOf foaf:maker .
>
> it reminds of the bidirectional links of some “closed” hypertext
> systems … the web was able to grow just because linking was free of
> such constrains (i.e. coordination between two parties to establish
> a link).
That's something completely different. When we talk about
bidirectional links, we mean that both sides make an unidirectional
link to the other side. That doesn't imply any kind of constraint and
has nothing to do with hypertext systems that enforce link consistency.
> I doubt that it is good for the web to promote such constrains.
Well then I'm happy to inform you that no one is doing so.
Best,
Richard
Laurian Gridinoc
On 24 Feb 2010, at 17:46, Laurian Gridinoc wrote:I was wondering if it is good to promote such bidirectional links,
Aidan didn't talk about promoting bidirectional links. He talked about the best property to use for expressing a bidirectional link on which both sides agree.
Well then I'm happy to inform you that no one is doing so.
ajtucker
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.
Alex.
Richard Cyganiak
On 25 Feb 2010, at 17:45, ajtucker wrote:
> 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.
This works in a closed environment where you pick the ontologies that
you want to use in your system.
I don't see how it would work on the web where, by default, nothing
can be trusted. How does an RDF search engine or crawler know that the
“interpretation ontology” isn't published by someone malicious or
incompetent and will mess up *both* FOAF and DC? How should it choose
between different conflicting “interpretation ontologies” published by
different parties?
The “ontology hijacking” concept addresses this.
Best,
Richard
Thomas Baker
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.
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].
Best regards,
Tom
[1] http://triplr.org/ntriples/purl.org/dc/terms/
[2] http://dublincore.org/documents/2007/07/02/domain-range/
[3] http://triplr.org/ntriples/xmlns.com/foaf/spec/
[4] http://www.jiscmail.ac.uk/lists/dc-architecture.html
--
Thomas Baker <tba...@tbaker.de>
Jonathan Rees
On Feb 25, 2:32 pm, Richard Cyganiak <rich...@cyganiak.de> wrote:
> Hi Alex,
>
> On 25 Feb 2010, at 17:45, ajtucker wrote:
>
> > 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.
>
> This works in a closed environment where you pick the ontologies that
> you want to use in your system.
>
> I don't see how it would work on the web where, by default, nothing
> can be trusted. How does an RDF search engine or crawler know that the
> “interpretation ontology” isn't published by someone malicious or
> incompetent and will mess up *both* FOAF and DC?
The same way that it knows that FOAF or DC isn't malicious or
incompetent maybe?
> How should it choose
> between different conflicting “interpretation ontologies” published by
> different parties?
The same way that it chooses between conflicting versions of FOAF or
DC maybe?
> The “ontology hijacking” concept addresses this.
>
> Best,
> Richard
Every little bit of RDF constrains the interpretation of every URI
occurring in it, so every little bit of RDF has the potential for
mischief. There is no formula for determining trust. Either you are
promiscuous, like Tabulator, and risk inconsistency at every step
(fine if you can detect and back out), or you pick and choose based on
a trust judgment for each triple or graph. I don't see the difference
between "closed environment" and prudent policy regarding what you
choose to load into your knowledge base.
Best
Jonathan
Hogan, Aidan
> > > 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.
> >
> > This works in a closed environment where you pick the ontologies
that
> > you want to use in your system.
> >
> > I don't see how it would work on the web where, by default, nothing
> > can be trusted. How does an RDF search engine or crawler know that
the
> > "interpretation ontology" isn't published by someone malicious or
> > incompetent and will mess up *both* FOAF and DC?
>
> The same way that it knows that FOAF or DC isn't malicious or
> incompetent maybe?
Possibly, but then clearly the independent mapping ontology is not a
solution to the problem. Again, an independent mapping could be seen as
redefining FOAF *and* DC terms outside of its jurisdiction. This was
Richard's original point.
> > How should it choose
> > between different conflicting "interpretation ontologies" published
by
> > different parties?
>
> The same way that it chooses between conflicting versions of FOAF or
> DC maybe?
Agreed, but again it does not help -- this is Richard's point.
> > The "ontology hijacking" concept addresses this.
>
> Every little bit of RDF constrains the interpretation of every URI
> occurring in it, so every little bit of RDF has the potential for
> mischief. There is no formula for determining trust.
I have to admit, I largely don't follow. There is no *one* formula for
determining trust: there are *myriads* of ways of automatically
determining trust -- or at least approximating trust depending on your
definition. Some of them even make sense and are practical! To determine
trust, however, one must include the notion of provenance for RDF graphs
on the Web.
> Either you are
> promiscuous, like Tabulator, and risk inconsistency at every step
> (fine if you can detect and back out), or you pick and choose based on
> a trust judgment for each triple or graph. I don't see the difference
> between "closed environment" and prudent policy regarding what you
> choose to load into your knowledge base.
Again, I largely don't follow. Inconsistency is not the problem under
discussion; the problem is protecting vocabularies from external
redefinition. As you say, from an application point of view one can
disregard certain RDF contributions based on some notion of trust and
enforce a certain trust model which it deems suitable for protecting
vocabularies.
What Richard was saying was that in a "closed environment", one can
*manually* pick and choose what they want to include in their
knowledge-base -- this is arbitrary and not under discussion.
The more interesting issue is what trust models can be *automatically*
applied across the Web and how. A conservative trust model for the
definition of classes and properties across Web vocabularies -- and one
I've been working on with colleagues -- is related to the previously
mentioned notion of "ontology hijacking".
This leads to the primary question... should Web vocabularies freely
state anything about any term anywhere and leave the trust-model pruning
to the application, or should Web vocabularies abide by some
best-practices for which application-side pruning will not be necessary.
I'm an advocate of the latter.
> I don't see the difference
> between "closed environment" and prudent policy regarding what you
> choose to load into your knowledge base.
So, I think the answer to your question is: in the former, the decision
of what to include or exclude is *manual* and thus somewhat trivial; in
the latter, the decision must be made *automatically*.
Cheers,
Aidan
Hogan, Aidan
This is another hot-topic/can-of-worms, which relates to the
expressiveness of Web vocabularies and compliance with the requirements
of different applications and possible adopters.
One point of note: adding OWL axioms to a vocabulary will not affect
RDFS compliance. RDFS can be applied to arbitrary RDF graphs. Similarly,
any reasoner with RDF-based semantics (RDFS/ OWL 2 RL *rule* engine)
should usually be applicable over any RDF graph. Similarly, OWL is
backwards compatible with a large part of the more interesting segment
of RDFS.
With respect to the DCMI metadata terms, the first question then is
whether or not you need OWL? My intuition would be that you don't: DC
terms are so popularly instantiated by RDF publishers because they are
lightly specified. That said, some lightweight OWL constructs could
prove useful... owl:inverseOf springs to mind for properties of the form
dct:replaces/dct:isReplacedBy.
More generally, once one steps outside of pure RDFS, the argument
becomes more broad with respect to the myriad of restrictions present in
the different DL-based species and profiles of OWL (OWL DL, OWL Lite,
OWL 2 RL, OWL 2 EL, OWL 2 RL, OWL 2 QL). Each has its own restrictions
for validity with respect to a given ontology. Each has its own
advocates and implementations and possible use-cases. Ouch.
In any case, most Web vocabularies are either RDFS or OWL Full: they
reasonably pick-and-choose the RDFS/OWL constructs they deem useful
without too much sympathy for the DL-based restrictions (which,
conversely, are not sympathetic to the creation of Web vocabularies).
FOAF have had this problem for years I guess, with respect to trying to
keep their vocabulary within OWL DL. Thus, they have included some OWL
syntactic sugar to keep the vocabulary *nearly* OWL DL compliant.
However, FOAF have encountered an ultimatum: in OWL DL, a
datatype-property cannot be inverse-functional, and thus FOAF cannot say
that foaf:mbox_sha1sum is inverse-functional without dropping OWL DL
compliant. Since this definition was core to the earlier FOAF use-case
of "smushing" (in the heady days of rampant blank-nodes) they reasonably
decided to forgo OWL DL compliance. [I may stand corrected here Dan?]
I know that Antoine has been informally thinking about how to neatly
allow Web vocabularies to link to different versions of the vocabulary
compliant with different profiles and tools which might fit into this
discussion. Perhaps Antoine might elaborate?
Again, I cannot offer a concrete solution or way forward. All I know is
that if DCMI leaves the safe cove of RDFS -- and given the more formal
nature of DCMI which will probably not allow "best-effort" OWL Full
extension -- some difficult/interesting questions will have to answered.
Cheers,
Aidan
Richard Cyganiak
On 26 Feb 2010, at 22:25, Jonathan Rees wrote:
>>> 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.
>>
>> This works in a closed environment where you pick the ontologies that
>> you want to use in your system.
>>
>> I don't see how it would work on the web where, by default, nothing
>> can be trusted. How does an RDF search engine or crawler know that
>> the
>> “interpretation ontology” isn't published by someone malicious or
>> incompetent and will mess up *both* FOAF and DC?
>
> The same way that it knows that FOAF or DC isn't malicious or
> incompetent maybe?
If Alice publishes an RDF file, and that file uses terms in the FOAF
namespace, then I would assume that Alice has, based on whatever
process, determined that the FOAF spec is not malicious or
incompetent. Hence I would argue that it's safe to apply inferences
that are implied by the FOAF spec to Alice's RDF file.
We have no idea what Alice thinks about the mapping ontology though.
Summary: We know that Alice considers FOAF and DC as not malicious
because she uses them. We don't know the same for the mapping ontology.
>> How should it choose
>> between different conflicting “interpretation ontologies” published
>> by
>> different parties?
>
> The same way that it chooses between conflicting versions of FOAF or
> DC maybe?
When I look into Alice's RDF file, and see some URI that she uses,
let's say a FOAF URI, then I can resolve it. I get exactly one version
of the FOAF spec. I know that this is the current authoritative
version of the FOAF spec, because the owner of the FOAF URI space has
configured his server to make it so.
There is no algorithm that has Alice's RDF file as input, and will
supply me with an authoritative version of the mapping ontology.
>> The “ontology hijacking” concept addresses this.
>>
>> Best,
>> Richard
>
> Every little bit of RDF constrains the interpretation of every URI
> occurring in it, so every little bit of RDF has the potential for
> mischief. There is no formula for determining trust. Either you are
> promiscuous, like Tabulator, and risk inconsistency at every step
> (fine if you can detect and back out), or you pick and choose based on
> a trust judgment for each triple or graph.
This is not an either/or. There are many possible formulas in between,
and some of them have been implemented and tested and work reasonably
well. The discussion we were having here is about the details of such
formulas.
> I don't see the difference
> between "closed environment" and prudent policy regarding what you
> choose to load into your knowledge base.
Web-scale inference engines (like the one my colleague Renaud Delbru
built for the Sindice search engine, or the one that Aidan is working
on) have to make millions of such trust decisions. Hence we need an
algorithmic alternative to the prudence that works for you and your
NC3A colleagues.
Best,
Richard
>
> Best
> Jonathan
Richard Cyganiak
On 26 Feb 2010, at 20:48, Thomas Baker wrote:
> 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].
The thing that worries me here is owl:AnnotationProperty. OWL (at
least in the DL flavour) strictly separates the “instance” level from
the “schema” level, and one has to choose wether a property is to be
used on the one level or on the other. Unlike FOAF properties, which
are about the “instance” level (people etc), most DC properties can be
reasonably used both on the instance and on the schema level
(ontologies have creators and modification dates). A decision to type
DC properties as Datatype- or ObjectProperties would rule out the use
of DC properties for annotating ontologies.
Personally I'd prefer if DC steered clear of this issue. The RDFS
definitions are sufficient for use on the web of data. And OWL users
can add additional local constraints for their particular ontologies,
as they already do today.
Best,
Richard
Jonathan Rees
> Hi Jonathan,
>
>> > > 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.
>> >
>> > This works in a closed environment where you pick the ontologies
> that
>> > you want to use in your system.
>> >
>> > I don't see how it would work on the web where, by default, nothing
>> > can be trusted. How does an RDF search engine or crawler know that
> the
>> > "interpretation ontology" isn't published by someone malicious or
>> > incompetent and will mess up *both* FOAF and DC?
>>
>> The same way that it knows that FOAF or DC isn't malicious or
>> incompetent maybe?
>
> Possibly, but then clearly the independent mapping ontology is not a
> solution to the problem.
I didn't say that it was. I was saying that the problem had no
methodical solution.
> Again, an independent mapping could be seen as
> redefining FOAF *and* DC terms outside of its jurisdiction. This was
> Richard's original point.
*Any* RDF graph that uses FOAF or DC risks redefining the terms in
them. If I find a rock in a field, and then assert that I am the
dc:creator of that rock, then I have plausible deniability on my side:
I can say in good faith that I used the DC term as it was intended.
You can disagree, and say I am privately redefining dc:creator, but
there is no automatic method for adjudicating such a disagreement. At
best we can say that you and I have different interpretations for the
URIs in DC and/or in my ontology.
So there is nothing special about bridge ontologies that distinguishes
them from any other kind of RDF.
Such disagreements are a good thing; they lead to better ontologies as
we iterate to tighten up the logic and get better agreement. But they
cannot be completely legislated away or automatically prevented, since
the interpretation of terms always relies on judgment.
Perhaps you have a different theory of RDF; mine comes from the RDF
model theory. If you're operating by different or additional rules I
would be interested in learning about them.
> I have to admit, I largely don't follow. There is no *one* formula for
> determining trust: there are *myriads* of ways of automatically
> determining trust -- or at least approximating trust depending on your
> definition. Some of them even make sense and are practical!
I am ignorant of these. Please direct me to information about them.
> To determine
> trust, however, one must include the notion of provenance for RDF graphs
> on the Web.
>
>> Either you are
>> promiscuous, like Tabulator, and risk inconsistency at every step
>> (fine if you can detect and back out), or you pick and choose based on
>> a trust judgment for each triple or graph. I don't see the difference
>> between "closed environment" and prudent policy regarding what you
>> choose to load into your knowledge base.
>
> Again, I largely don't follow. Inconsistency is not the problem under
> discussion; the problem is protecting vocabularies from external
> redefinition. As you say, from an application point of view one can
> disregard certain RDF contributions based on some notion of trust and
> enforce a certain trust model which it deems suitable for protecting
> vocabularies.
>
> What Richard was saying was that in a "closed environment", one can
> *manually* pick and choose what they want to include in their
> knowledge-base -- this is arbitrary and not under discussion.
I wasn't talking about manual vs. automatic, I was talking about
prudent vs. promiscuous. If you are defining "closed" to mean
"manually picked" that is not what I would have expected, but I guess
I understand at least what was intended.
But if you have adopted an automatic rule for deciding what to believe
and what not to, then you manually picked that particular automatic
rule. So I don't see the importance of the distinction. Maybe I have
my own automatic rule that leads to "trust" in a bridge ontology.
> The more interesting issue is what trust models can be *automatically*
> applied across the Web and how. A conservative trust model for the
> definition of classes and properties across Web vocabularies -- and one
> I've been working on with colleagues -- is related to the previously
> mentioned notion of "ontology hijacking".
I would be interested in seeing a writeup.
Best
Jonathan
Jonathan Rees
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.
Best
Jonathan
http://groups.google.com/group/bibliographic-ontology-specification-group/browse_thread/thread/55e19fa2a18e8fdf?hl=en
http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl
Antoine Zimmermann
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...@googlemail.com>:
--
--AZ
Richard Cyganiak
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
Nathan
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.
regards!
nathan / still learning / webr3
Jonathan Rees
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.
Best
Jonathan
> > Read more onhttp://www.ontologymatching.org/.
>
> > Regards,
> > AZ.
>
> > 2010/2/25 ajtucker <a.james.tuc...@googlemail.com>:
Antoine Zimmermann
2010/3/3 Richard Cyganiak <ric...@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. 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.
> Best,
> Richard
Cheers,
AZ.
--
--AZ
Richard Cyganiak
> 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.
Best,
Richard
Antoine Zimmermann
[...]
> 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:
ex:myOnto a owl:Ontology;
yoda:dlVersion ex:myOntoDL;
yoda:elVersion ex:myOntoEL;
yoda:qlVersion ex:myOntoQL;
yoda:rlVersion ex:myOntoRL.
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
Richard Cyganiak
> 2010/3/3 Richard Cyganiak <ric...@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.
Richard
Nathan
> On 4 Mar 2010, at 17:18, Antoine Zimmermann wrote:
>> 2010/3/3 Richard Cyganiak <ric...@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).
regards!
Richard Cyganiak
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.
> 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).
Agreed, and of course nothing wrong with that.
Richard
>
> regards!
Nathan
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!
many regards,
nathan