Well, that is a straw man argument, because you picked a triple that
contains a blatant error. Nobody is arguing that Berlin should become a
country, or that we should reuse the property country in the wrong context.
Now... there is the need to detect that country is wrong in that context.
This could be done with pre-defined domain/range, manually, or can be done
automatically with probabilistic models as you pointed out.
I am sure that everyone has their own definition for what a truly data
driven approach means. But in the context of seeing the schema as
constraints vs seeing it as merely more data, a truly data driven approach
does not *respect* an arbitrary schema that was created with some unknown
purpose in mind. It learns from the actual data usage and makes its own
schema on the fly, perhaps even using the constraints in the schema as
additional data points.
There are arguments for both approaches. But I am not interested in
debating this. Like I said, the data camp does not get hurt by more info.
So please go ahead and summon the schema camp to contribute those
constraints. The more data, the merrier. :)
On Mar 22, 2014 8:29 PM, "Mike Bergman" <m...@mkbergman.com> wrote:
> I agree totally with Aleksander.
>
> Further, Pablo, I also think it was wrong to frame this discussion as
> data v schema. A true *data* perspective should also respect to what the
> data applies and in what context. These are the express purposes of
> domain and range.
>
> Mike
>
> On 3/22/2014 5:30 PM, apoh...@o2.pl wrote:
> > Hi Pablo,
> >
> > well, for me this seems a very interesting opinion, but I am pretty
> > confused. First of all I guess these opinions are not equal in their
> > support. Why I think so? Because when we drop argument constraints (I
> > mean, we do not apply them if they are defined) we no longer follow the
> > mathematical semantics theory, which I believe is the ground for
> > SemanticWeb, and we adopt natural language semantics theory, with
> > metaphor and other phenomena which are pretty hard to model using
> > computers. Let me give you an example: there is a triple in DBpedia
> > regarding Berlin - it is the "country" of e.g. City_Slang (a record
> > label company). How can we interpret this "fact"? "country" has a
> > "Country" constraint on its range and Berlin definitely is not a
> > country. For me it's really hard to accept an interpretation in which
> > "country" predicate is used for other places than countries (as values
> > staying in the object position).
> >
> > Obviously there will be predicates that have a less stricter semantics
> > than "country" and I can imagine using them in contexts not designed by
> > their authors. Still in such cases providing extension to the original
> > predicate definition would seem much better idea than just dropping any
> > constraints.
> >
> > And the last thing - what is the primary point of providing types for
> > entities in KBs such as DBpeida? I thought that they, together with the
> > predicates' constraints, may greatly improve the quality of the KB. I
> > know that you can make inferences based on the data, without any
> > ontology or schema or whatever. You can improve the quality
> > statistically, etc. Machine learning is doing pretty well without
> > explicit constraints. But on the other hand - the DBpedia ontology, its
> > types, predicates and the mappings from infoboxes to predicates are
> > constructed manually. We can backtrack any invalidation of the
> > constraints without problem. There might be many reasons for such
> > situation - the object lacks the appropriate type assignment, the
> > constraint is too narrow, the mapping is invalid or the original
> > statement (i.e. infobox field) is invalid. In the last case this is a
> > genuine problem of the data. In the case of the invalid mapping it can
> > be easily fixed improving the quality of the hundreds or thousands of
> > the extracted triples.
> >
> > So I place myself definitely in the schema camp. It would be very
> > interesting to read some arguments coming from the data camp :-)
> >
> > Cheers,
> > Aleksander
> >
> > ---- Wł. So, 22 mar 2014 18:21:51 +0100 *Pablo N.
> > Mendes<pablomen...@gmail.com>* napisał(a) ----
> >
> >
> > I disagree that this has been only negligence. There are people that
> > believe that constraining the schema is a good thing, and there are
> > people that believe that reusing more freely properties across
> > multiple classes is a good thing. It's a schema driven versus data
> > driven approach.
> >
> > But since the latter group can just ignore the constraints, I don't
> > see harm in doing it.
> >
> > On Mar 21, 2014 1:40 AM, "Kuys, Gerard" <gerard.k...@ordina.nl
> > <mailto:gerard.k...@ordina.nl>> wrote:
> >
> > Hi,
> >
> > In my opinion, the main flaw - indeed, I agree completely with
> > Jona - is that no domain is defined for a huge number of
> > properties. So, let us all add a domain definition for a
> > property whenever we see one missing!
> >
> > Regards,
> >
> > Gerard
> >
> ------------------------------------------------------------------------
> > *Van:* Jona Christopher Sahnwaldt [j...@sahnwaldt.de
> > <mailto:j...@sahnwaldt.de>]
> > *Verzonden:* vrijdag 21 maart 2014 0:11
> > *Aan:* apoh...@o2.pl <mailto:apoh...@o2.pl>
> > *CC:* dbpedia-discussion
> > *Onderwerp:* Re: [Dbpedia-discussion] DBpedia ontology -
> > predicate constraints
> >
> >
> > On Mar 19, 2014 7:24 PM, "apoh...@o2.pl <mailto:apoh...@o2.pl>"
> > <apoh...@o2.pl <mailto:apoh...@o2.pl>> wrote:
> > >
> > > Dear DBpedia creators,
> > >
> > > I am wondering about two issues connected with the properties
> > extracted from the infoboxes and mapped to DBpedia ontology
> > predicates.
> > > The first one is the absence in some of the predicates'
> > definitions domains and ranges - e.g. [1], [2]. Shall I assume
> > that I should consult schema.org <http://schema.org> (which
> > doesn't have the full definitions BTW) in order to check the
> > requirements?
> > > The second observation is connected with the fact, that many
> > of the extracted properties are not compatible with the
> > constraints. E.g. [3] Mens (band) has a hometown property [4],
> > which according to its definition [5] has a domain restricted to
> > People.
> > >
> > > Are there any ongoing efforts to fix these issues? How could
> > I help with them (e.g. by providing the appropriate domain/range
> > definitions)?
> >
> > Are you aware of the DBpedia mappings wiki? Maybe that's a dumb
> > question. Anyway, once you have a user account, you can add the
> > domain/range here:
> > http://mappings.dbpedia.org/index.php/OntologyProperty:Genre
> > and fix the domain (maybe change it from Person to its
> > superclass Agent?) here:
> > http://mappings.dbpedia.org/index.php/OntologyProperty:Hometown
> >
> > JC
> >
> > >
> > > Kind regards,
> > > Aleksander Pohl
> > >
> > >
> > >
> > > [1] http://dbpedia.org/ontology/genre
> > > [2] http://dbpedia.org/ontology/director
> > > [3] http://en.wikipedia.org/wiki/Manes_%28band%29
> > > [4] http://dbpedia.org/page/Manes_%28band%29
> > > [5] http://dbpedia.org/ontology/hometown
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Learn Graph Databases - Download FREE O'Reilly Book
> > > "Graph Databases" is the definitive new guide to graph
> > databases and their
> > > applications. Written by three acclaimed leaders in the field,
> > > this first edition is now available. Download your free book
> > today!
> > > http://p.sf.net/sfu/13534_NeoTech
> > > _______________________________________________
> > > Dbpedia-discussion mailing list
> > > Dbpedia-discussion@lists.sourceforge.net
> > <mailto:Dbpedia-discussion@lists.sourceforge.net>
> > >
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
> > >
> >
> >
> > Disclaimer
> > Dit bericht met eventuele bijlagen is vertrouwelijk en
> > uitsluitend bestemd voor de geadresseerde. Indien u niet de
> > bedoelde ontvanger bent, wordt u verzocht de afzender te
> > waarschuwen en dit bericht met eventuele bijlagen direct te
> > verwijderen en/of te vernietigen. Het is niet toegestaan dit
> > bericht en eventuele bijlagen te vermenigvuldigen, door te
> > sturen, openbaar te maken, op te slaan of op andere wijze te
> > gebruiken. Ordina N.V. en/of haar groepsmaatschappijen
> > accepteren geen verantwoordelijkheid of aansprakelijkheid voor
> > schade die voortvloeit uit de inhoud en/of de verzending van dit
> > bericht.
> >
> > This e-mail and any attachments are confidential and are solely
> > intended for the addressee. If you are not the intended
> > recipient, please notify the sender and delete and/or destroy
> > this message and any attachments immediately. It is prohibited
> > to copy, to distribute, to disclose or to use this e-mail and
> > any attachments in any other way. Ordina N.V. and/or its group
> > companies do not accept any responsibility nor liability for any
> > damage resulting from the content of and/or the transmission of
> > this message.
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases
> > and their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book
> today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Dbpedia-discussion mailing list
> > Dbpedia-discussion@lists.sourceforge.net
> > <mailto:Dbpedia-discussion@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> >
> >
> >
> > _______________________________________________
> > Dbpedia-discussion mailing list
> > Dbpedia-discussion@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
> >
>
> --
> __________________________________________
>
> Michael K. Bergman
> CEO Structured Dynamics LLC
> 319.621.5225
> skype:michaelkbergman
> http://structureddynamics.com
> http://mkbergman.com
> http://www.linkedin.com/in/mkbergman
> __________________________________________
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Dbpedia-discussion mailing list
> Dbpedia-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
