Re: How to model valid time of resource properties?

Hi,
> On 15 Oct 2014, at 23:02, John Walker <john.walker@semaku.com> wrote:
> 
> Hi
>  
>> 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:
...
> Personally I would not use this approach for foaf:age and foaf:based_near as these capture a certain snapshot/state of (the information about) a resource. Having some representation where the foaf:age triple could be entailed could lead to having multiple conflicting statements with no easy way to find the truth.
> 
> Having a clear understanding of the questions you want to ask of your knowledge base should help steer modelling choices.
This undoubtedly true, and very important - is the modelling fit for purpose?
Proper engineering.

>>> 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?
> If you want to be able to capture historical states of a resource, using named graphs to provide that context would be my first thought.
However, there is a downside to this.
If all that is happening is that Frans is gathering his own data into a store, and then using that data for some understood application of his, then this will be fine.
Then he knows exactly the structure to impose on his RDF using named Graphs.

But this is Linked Open Data, right?
So what happens about use by other people?
Or if Frans wants to build other queries over the same data?
If he hasn’t foreseen the other structure, and therefore ensured that the required Named Graphs exist, then it won;t be possible to make the statements required about the RDF.

The problem is that in choosing the Named Graph structure, the data publisher makes very deep assumptions and even decisions about how the dataset will be used.
This is not really good practice in an Open world - in fact, one of the claimed advantages of Semantic Web technologies is that such assumptions (such as the choice of tables in a typical database) are no longer required!

I’m not saying that Named Graphs aren’t useful and often appropriate, but choosing to use Named Graphs can really make the data hard to consume.
And if they are used, the choice of how really needs to be considered very much with the modelling.
(This is particularly important in the absence of any ability to nest Named Graphs.)

Cheers
> 
> If that resource consists of just one triple, then RDF reification of that statement would also work as Kingsley mentions.
> 
>>> 
>>> 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 :) 
>> 
>> 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 
>> 
>> -- 
>> 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
> 
>  

-- 
Hugh Glaser
   20 Portchester Rise
   Eastleigh
   SO50 4QS
Mobile: +44 75 9533 4155, Home: +44 23 8061 5652

Received on Thursday, 16 October 2014 10:45:54 UTC