- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 17 Oct 2014 14:00:05 -0400
- To: Pat Hayes <phayes@ihmc.us>
- CC: public-lod@w3.org
- Message-ID: <54415925.8030800@openlinksw.com>
On 10/17/14 11:48 AM, Pat Hayes wrote: > On Oct 17, 2014, at 6:34 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 10/17/14 12:00 AM, Pat Hayes wrote: >>> Kingsley, greetings. >>> >>> It is important to keep a clear distinction between what temporal DB calls valid time and transaction time. T-time is when the record was inserted into the databese or when it was created. >> Yes, certainly. >> >>> This is important, basically, for internal accounting and maintenance of the DB itself. >> Yes. >> >>> V-time is the time being referred to in the data. So for example, if Bill and Jane are married on 01012014 and this fact gets inserted into a record of marriages on 05012014, there are two times involved, and these are the valid and transaction times respectively. >> Yes. >> >>> What you are talking about, when you suggest using reification and dates of documents, is transaction time, not valid time. >> If this was based solely on the world view of the RDF Reification Ontology [1], then yes, but I have an extended Ontology [2] that adds addition properties to the Statement Class. These extensions arose so that statements in a document could be endorsed and signed etc.. > But endorsing, signing, etc. are all things that attach to transaction time rather than valid time. They are all things done to the document (to the data) rather than things that the data talks about. (Except in those cases where what the data talks about is those very signings, endorsings, etc., but that is exactly where the distinction becomes pointless since the valid and transaction times coincide.) > > You point me to your ontology, below, where it defines endorsement as a "claim used to describe statements". Exactly: it describes the *statement*, not what the statement is talking about. I can endorse in 2014 a statement made in 2013 about a house purchase deed transfer which took place in 2011. The actual event was the transfer, which is not a document and not an endorement of a document, but an actual event in the world, which these documents refer to. Which is why I, in 2014, might have to pay fines to the IRS for taxes not paid in 2011. > > This is why reification is the wrong tool to be using to describe valid times. Valid times are extra arguments to the relations in the data, or related to events described in the data; transaction times are arguments to relations between times and the data itself. > > Pat I don't believe I am suggesting the use of reification for valid times. I am indicating (hopefully) that what's described in a document and the mechanism of description (RDF statements, using [in my case] TURTLE notation) can be collectively used to establish fact from fiction, so to speak. A marriage certificate is a document comprised of claims that reflect a reality comprised of temporal relations -- just like any other document that describes events e.g., ISWC 2014. Here's the kind of document to which my thoughts apply, in regards to this matter. For instance, I've made a claim about when this event starts and ends, and claimed that some entity (referred to as <#ISWC2014Organization>) has endorsed the statements in question etc.: ## Nanotation Start ## <> a <http://rdfs.org/sioc/ns#Post> ; <http://purl.org/dc/terms/created> "2014-10-17T13:10+05:00"^^xsd:dateTime; <https://twitter.com/hashtag/features#this> [ a Person; foaf:mbox <mailto:phayes@ihmc.us> ], <http://kingsley.idehen.net/dataspace/person#this> ; <http://xmlns.com/foaf/0.1/primaryTopic> <https://twitter.com/hashtage/Reification>; <http://xmlns.com/foaf/0.1/topic> <#ISWC2014>, <#StartStatement> . <#ISWC2014> a <http://purl.org/NET/c4dm/event.owl#Event> ; <http://www.w3.org/2000/01/rdf-schema#label> "ISWC2014" ; <http://www.w3.org/2004/02/skos/core#altLabel> "International Semantic Web Conference 2014"; <http://www.ontologydesignpatterns.org/cp/owl/timeinterval.owl#beginsAtDateTime> "2014-10-19T08:00-01:00"^^xsd:dateTime; <http://www.ontologydesignpatterns.org/cp/owl/timeinterval.owl#endsAtDateTime> "2014-10-23T17:00-01:00"^^xsd:dateTime; <http://www.w3.org/2007/05/powder-s#describedby> <>. <#ISWC2014EventStartStatement> a <http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement> ; <http://www.w3.org/2000/01/rdf-schema#label> "ISWC2014EventStartStatement" ; <http://www.w3.org/2004/02/skos/core#prefLabel> "ISWC2014 Event Start Statement" ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> <#ISWC2014>; <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> <http://www.ontologydesignpatterns.org/cp/owl/timeinterval.owl#beginsAtDateTime> ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> "2014-10-19T08:00-01:00"^^xsd:dateTime ; <http://www.w3.org/2007/05/powder-s#describedby> <>. <#ISWC2014StatementEndorsementExample> <http://www.w3.org/2000/01/rdf-schema#label> "ISWC2014StatementEndorsementExample" ; <http://www.w3.org/2004/02/skos/core#prefLabel> "ISWC 2014 Statement Endorsement Example" ; a <http://www.openlinksw.com/schemas/reification#Endorsement> ; <http://www.openlinksw.com/schemas/reification#endorser> <#ISWC2014Organization> ; <http://www.w3.org/2007/05/powder-s#describedby> <>. <https://twitter.com/hashtag/features#this> rdfs:isDefinedBy <http://linkeddata.uriburner.com/c/8CAOF4> . ## Nanotation End ## To conclude, if my view point remain unclear (I believe I understand your concerns), then a tweak of what's represented above will be mutually beneficial, at the very least :) Kingsley > >>> Conflating these might work in some cases, but it is guaranteed to break eventually, and the ways it breaks can be catastrophic, involving miscarriages of justice, false imprisonment, legal judgements about inheritance, etc.. Better to not get this confused in the first place, especially as the distinciton has been carefully worked out already. >> In my case, I am not conflating these matters. Basically, the concerns you have above are the very reasons behind our reification ontology (I am also very concerned about issues such as false imprisonment, miscarriage of justice etc., that you've listed above, hence my reference to contracts as my basic example. >> >> In hindsight, I think the role of our refiefication ontology in my comments should have been a little clearer, I assumed that looking at my examples would lead readers into the actual definition of terms in our extended reification ontology. >> >> Links: >> >> [1] http://www.openlinksw.com/c/9BFOWHNO -- document presenting description of W3C RDF Reification Ontology >> [2] http://www.openlinksw.com/schemas/reification# -- our extended Reification Ontology >> [3] http://www.openlinksw.com/c/9CX6QLP -- Endorsement Class from our Ontology >> [4] http://www.openlinksw.com/c/976UQCN -- endorser property from our Ontology . >> >> >> Kingsley >> >> >> >>> Pat Hayes >>> >>> >>> On Oct 16, 2014, at 7:00 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote: >>> >>>> On 10/16/14 3:33 AM, John Walker wrote: >>>>> Hi Kingsley, >>>>> >>>>>> On October 15, 2014 at 2:59 PM Kingsley Idehen <kidehen@openlinksw.com> wrote: >>>>>> >>>>>> On 10/15/14 8:36 AM, Frans Knibbe | Geodan wrote: >>>>>>> On 2014-10-13 14:14, John Walker wrote: >>>>>>>> Hi Frans, >>>>>>>> See this example: >>>>>>>> http://patterns.dataincubator.org/book/qualified-relation.html >>>>>>> Thank you John! Strangely enough, I had not come across the Linked Data Patterns book before. But I can see it is a valuable resource with solutions for many common problems. And it looks pretty too! I am sure it will come in handy for problems that I haven't stumbled upon yet. >>>>>>> >>>>>>> A nice thing about this solution is that it doesn't need any extensions of core technologies. I do see some downsides, though: >>>>>>> >>>>>>> Let's assume I want to publish data about people, as in the examples. A person can have common properties defined by the FOAF vocabulary, like foaf:age or foaf:based_near. Properties like these are likely to change. If I want to record the time in which a statement is valid I would have to create a class for that relationship and add properties to that class that will allow me to associate a start time and an end time with the class. But by doing that I would not only be forced to create my own vocabulary, I would also replace common web wide semantics with my own semantics. Or would it still be possible to relate the original property with the custom class somehow? >>>>>>> >>>>>>> In the cases known to me that require the recording of history of resources, all resource properties (except for the identifier) are things that can change in time. If this pattern would be applied, it would have to be applied to all properties, leading to vocabularies exploding and becoming unwieldy, as described in the Discussion paragraph. >>>>>>> >>>>>>> I think that the desire to annotate statements with things like valid time is very common. Wouldn't it be funny if the best solution to a such a common and relatively straightforward requirement is to create large custom vocabularies? >>>>>>> >>>>>>> Regards, >>>>>>> Frans >>>>>> Frans, >>>>>> >>>>>> How about reified RDF statements? >>>>>> >>>>>> I think discounting RDF reification vocabulary is yet another act of premature optimization, in regards to the Semantic Web meme :) >>>>> Just wondering if the semantics of RDF reification would accurately capture the semantics of what Frans wants to model. >>>>> >>>>> If the idea is to capture the start and end date of a relationship, then is RDF reification the answer in this case? >>>>> >>>> Yes, since an RDF statement represents a relationship [1]. Thus, using reification (as per my example) you can refer to utterances (statements) made at a specific time. >>>> >>>>> As the reified statement has rdf:type rdf:Statement, wouldn't we that be making the additional statements about the statement, not about the relationship it represents. If so, what does it mean to indicate a start and end date of a statement? >>>>> >>>>> To use a real life example discussed during Pilod [3] we have multiple conflicting source of information: >>>>> >>>>> Tax office records show Alice and Bob were married from 2010-03-01 to 2014-01-01. >>>>> >>>> The Tax Office statements (recording this event) exist in a document created at a point in time. The document in question is comprised of RDF statements. Each statement was also made at a point in time. Collectively they provide a temporal "context lens" relating to the observations (RDF statements) captured in the aformentioned document. >>>> >>>>> Local council records show Alice and Bob were married from 2001-03-01 to 2014-10-10. >>>>> >>>> Local Council statements (recording this event) exist in a document created at a point in time. This document is independent of the Tax Office document. >>>> >>>>> This probably requires a mix of different modelling techniques and there's no right or wrong way to do it. >>>>> >>>> What would you do in the real-world today? You (the relevant offices, or the marriage relation participants) would reconcile these two documents. >>>> >>>> RDF Reification provides a good foundation for these issues, you can extend the vocabulary to enhance context-fidelity (across various axis), if need be [1][2]. >>>> >>>> >>>> [1] http://www.openlinksw.com/c/9DQD6HLX -- OpenLink Statement >>>> [2] http://www.openlinksw.com/c/9HWIJM -- Statement (which extends rdf:Statement) >>>> >>>> Kingsley >>>>> [3] http://www.pilod.nl/ >>>>> >>>>>> Some examples: >>>>>> >>>>>> [1] http://bit.ly/utterances-since-sept-11-2014 -- List of statements made from a point in time. >>>>>> [2] http://linkeddata.uriburner.com/c/8EPG33 -- About Connotation >>>>> These are great examples of using RDF reification, good stuff! >>>>> It's really clear that here you are capturing additonal (meta)data about who made the statement, when, etc. >>>>> John >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Kingsley Idehen >>>>>> Founder & CEO >>>>>> OpenLink Software >>>>>> Company Web: >>>>>> http://www.openlinksw.com >>>>>> >>>>>> Personal Weblog 1: >>>>>> http://kidehen.blogspot.com >>>>>> >>>>>> Personal Weblog 2: >>>>>> http://www.openlinksw.com/blog/~kidehen >>>>>> >>>>>> Twitter Profile: >>>>>> https://twitter.com/kidehen >>>>>> >>>>>> Google+ Profile: >>>>>> https://plus.google.com/+KingsleyIdehen/about >>>>>> >>>>>> LinkedIn Profile: >>>>>> http://www.linkedin.com/in/kidehen >>>>>> >>>>>> Personal WebID: >>>>>> http://kingsley.idehen.net/dataspace/person/kidehen#this >>>>> >>>> -- >>>> Regards, >>>> >>>> Kingsley Idehen >>>> Founder & CEO >>>> OpenLink Software >>>> Company Web: >>>> http://www.openlinksw.com >>>> >>>> Personal Weblog 1: >>>> http://kidehen.blogspot.com >>>> >>>> Personal Weblog 2: >>>> http://www.openlinksw.com/blog/~kidehen >>>> >>>> Twitter Profile: >>>> https://twitter.com/kidehen >>>> >>>> Google+ Profile: >>>> https://plus.google.com/+KingsleyIdehen/about >>>> >>>> LinkedIn Profile: >>>> http://www.linkedin.com/in/kidehen >>>> >>>> Personal WebID: >>>> http://kingsley.idehen.net/dataspace/person/kidehen#this >>> ------------------------------------------------------------ >>> IHMC (850)434 8903 home >>> 40 South Alcaniz St. (850)202 4416 office >>> Pensacola (850)202 4440 fax >>> FL 32502 (850)291 0667 mobile (preferred) >>> phayes@ihmc.us http://www.ihmc.us/users/phayes >>> >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog 1: http://kidehen.blogspot.com >> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen >> Twitter Profile: https://twitter.com/kidehen >> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this > ------------------------------------------------------------ > IHMC (850)434 8903 home > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile (preferred) > phayes@ihmc.us http://www.ihmc.us/users/phayes > > > > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 17 October 2014 18:00:28 UTC