Well, I got to Allen's algebra of intervals because I was concerned about
how to deal with all of the different date time formats that are specified
in XSD. All of these can be treated, correctly, as either an interval or
a set of intervals.
Note there are modelling issues that go beyond this.
For instance, I still say we retain the birth date and death date
properties even though you could model somebody's life as an interval.
There are lots of practical reasons, but one of them is that I know my
life is not an open ended interval although it looks like that now.
Using this is a practical theory of time I can usually figure out what I
need to know.
I can say, however, if a person has a birthdate in Freebase of Jan 1, X,
odds are far less than 0.5 that the person was born on that day. Thus,
if I want to say anything abut people born on Jan 1, X and not look like a
fool, I need to go through those facts and figure out which ones I
believe. Thus, in some cases the data is really broken and energy must be
spent to overcome entropy.
On Tue, Jan 27, 2015 at 1:05 PM, M. Aaron Bossert <maboss...@gmail.com>
wrote:
> Paul,
>
> The date ranges are doable...I would say that one can still work either
> as-is...and working with differing levels of specificity...if you work with
> the dates as they are...
>
> Aaron
>
> On Jan 27, 2015, at 12:27, Paul Houle <ontolo...@gmail.com> wrote:
>
> DBpedia has a mission that is focused around extracting data from
> Wikipedia. Importing data wholesale from Wikidata or something like that
> seems to be inconsistent with that mission, but there are all kinds of
> temporal and provenance things that could be teased out of Wikipedia, if
> not out of the Infoboxes.
>
> I think most query scenarios are going to work like this
>
> [Pot of data with provenance information] -> [Data Set Representing a
> POV] -> query
>
> I've been banging my head on the temporal aspect for a while and I am
> convinced that the practical answer to a lot of problems is to replace
> times with time intervals. Intervals can be used to model duration and
> uncertainty and the overloading between those functions is not so bad
> because usually you know from the context what the interval is being used
> to represent.
>
> There is a lot of pain right now if you want to work with dates from
> either DBpedia or Freebase because different kinds of dates are specified
> to different levels of detail. If you make a plot of people's birthdays in
> Freebase for instance you find a lot of people born on Jan 1 I think
> because that is something 'plausible' to put in.
>
> A "birth date" could be resolved to a short interval (I know was I born at
> 4:06 in the afternoon) and astrologers would like to know that, but the
> frequent use of a calendar day is a statement about imprecision, although
> defining my "birthday" as a set of one day intervals the interval is
> reflecting a social convention.
>
> Anyway, there is an algebra over time intervals that is well accepted
>
>
> http://docs.jboss.org/drools/release/latest/drools-docs/html/DroolsComplexEventProcessingChapter.html#d0e10852
>
> and could be implemented either as a native XSD data type or by some
> structure involving "blank" nodes.
>
>
>
> On Tue, Jan 27, 2015 at 11:22 AM, M. Aaron Bossert <maboss...@gmail.com>
> wrote:
>
>> Martin,
>>
>> When I first started working with RDF, I didn't fully "get" the full
>> expressivity of it. All of the things you are saying can't be done
>> (perhaps, easily?) are quite simple to implement. When compared to the
>> property graph model, RDF, at first glance, seems inferior, but in reality,
>> is much more expressive, in my opinion. Through reification, you can
>> express all of the concepts that you are wanting to (provenance, date
>> ranges, etc). At the end of the day, RDF's expressivity comes at the cost
>> of verbosity, which, in my opinion is well worth it.
>>
>> If you would like some help in modeling your graph to represent the
>> missing concepts that you are after, I will be happy to help you out with
>> some more specific examples and pointers if it would be helpful to you.
>>
>> Aaron
>>
>> > On Jan 27, 2015, at 06:33, Martin Brümmer <
>> bruem...@informatik.uni-leipzig.de> wrote:
>> >
>> > Hi DBpedians!
>> >
>> > As you surely have noticed, Google has abandoned Freebase and it will
>> > merge with Wikidata [1]. I searched the list, but did not find a
>> > discussion about it. So here goes my point of view:
>> >
>> > When Wikidata was started, I hoped it would quickly become a major
>> > contributor of quality data to the LOD cloud. But although the project
>> > has a potentially massive crowd and is backed by Wikimedia, it does not
>> > really care about the Linked Data paradigm as established in the
>> > Semantic Web. RDF is more of an afterthought than a central concept. It
>> > was a bit disappointing to see that Wikidata's impact on the LOD
>> > community is lacking because of this.
>> >
>> > Now Freebase will be integrated into Wikidata as a curated, Google
>> > engineering hardened knowledge base not foreign to RDF and Linked Data.
>> > How the integration will be realized is not yet clear it seems. One
>> > consequence is hopefully, that the LOD cloud grows by a significant
>> > amount of quality data. But I wonder what the consequences for the
>> > DBpedia project will be? If Wikimedia gets their own knowledge graph,
>> > possible curated by their crowd, where is the place for the DBpedia? Can
>> > DBpedia stay relevant with all the problems of an open source project,
>> > all the difficulties with mapping heterogeneous data in many different
>> > languages, the resulting struggle with data quality and consistency and
>> > so on?
>> >
>> > So I propose being proactive about it:
>> >
>> > I see a large problem of the DBpedia with restrictions of the RDF data
>> > model. Triples limit our ability to make statements about statements. I
>> > cannot easily address a fact in the DBpedia and annotate it. This means:
>> >
>> > -I cannot denote the provenance of a statement. I especially cannot
>> > denote the source data it comes from. Resource level provenance is not
>> > sufficient if further datasets are to be integrated into DBpedia in the
>> > future.
>> > -I cannot denote a timespan that limits the validity of a statement.
>> > Consider the fact that Barack Obama is the president of the USA. This
>> > fact was not valid at a point in the past and won't be valid at some
>> > point in the future. Now I might link the DBpedia page of Barack Obama
>> > for this fact. Now if a DBpedia version is published after the next
>> > president of the USA was elected, this fact might be missing from the
>> > DBpedia and my link becomes moot. -This is a problem with
>> > persistency. Being able to download old dumps of DBpedia is not a
>> > sufficient model of persistency. The community struggles to increase
>> > data quality, but as soon as a new version is published, it drops some
>> > of the progress made in favour of whatever facts are found in the
>> > Wikipedia dumps at the time of extraction. The old facts should persist,
>> > not only in some dump files, but as linkable data.
>> >
>> > Being able to address these problems would also mean being able to fully
>> > import Wikidata, including provenance statements and validity timespans,
>> > and combine it with the DBpedia ontology (which already is an important
>> > focus of development and rightfully so). It also means a persistent
>> > DBpedia that does not start over in the next version.
>> >
>> > So how can it be realized? With reification of course! But most of us
>> > resent the problems reification brings with it, the complications in
>> > querying etc. The reification model itself is also unclear. There are
>> > different proposals, blank nodes, reification vocabulary, graph names,
>> > creating unique subproperties for each triple etc. Now I won't propose
>> > using one of these models, this will surely be subject to discussion.
>> > But the DBpedia can propose a model and the LOD community will adapt,
>> > due to DBpedia's state and impact. I think it is time to up the standard
>> > of handling provenance and persistence in the LOD cloud and DBpedia
>> > should make the start. Especially in the face of Freebase and Wikidata
>> > merging, I believe it is imperative for the DBpedia to move forward.
>> >
>> > regards,
>> > Martin
>> >
>> > [1] https://plus.google.com/109936836907132434202/posts/bu3z2wVqcQc
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming. The Go Parallel Website,
>> > sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> > hub for all things parallel software development, from weekly thought
>> > leadership blogs to news, videos, case studies, tutorials and more.
>> Take a
>> > look and join the conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Dbpedia-discussion mailing list
>> > Dbpedia-discussion@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Dbpedia-discussion mailing list
>> Dbpedia-discussion@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>
>
>
> --
> Paul Houle
> Expert on Freebase, DBpedia, Hadoop and RDF
> (607) 539 6254 paul.houle on Skype ontolo...@gmail.com
> http://legalentityidentifier.info/lei/lookup
>
>
--
Paul Houle
Expert on Freebase, DBpedia, Hadoop and RDF
(607) 539 6254 paul.houle on Skype ontolo...@gmail.com
http://legalentityidentifier.info/lei/lookup
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
