Re: How to model valid time of resource properties?

On 2014-10-16 12:45, Hugh Glaser 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.

I hope this thread can be about the very general problem of modelling 
valid time of properties, not some particular use case that I have. I 
have encountered this problem in various unrelated cases. In relational 
databases too. It seems the SQL world has recognized it to be a 
universal problem, because it is addressed by the SQL:2011 standard 
<http://en.wikipedia.org/wiki/SQL:2011#Temporal_support>.

>
>>>> 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!
It is my recent understanding that Named Graphs could be used - or are 
even designed to be used - to carry meta-information that may not be 
always necessary to be aware of, but can be brought forward if 
necessary. Now if everyone would use Named Graphs this way, a common 
usage pattern of Linked Data might be to query for the existence of any 
named graphs that could give further context to data.

I was pleased by the idea that I read somewhere that the current state 
of a resource might be part of the default graph (which can remain 
unnamed) and historical states associated with temporal graphs. I don't 
know if this could work in practice, but I do like the idea that the 
extra constructs needed for versioning can remain hidden, but be called 
upon when necessary. Of course the same approach could be used for other 
types of annotation, like transaction time, quality, access levels, ...

>
> 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.)
That is an important remark. Is it really true that Named Graphs can not 
be nested? That would spoil a lot of fun.

I know that a triple can only be associated with one Named Graph. So 
every triple needs its own unique named graph. The named graph has a 
URI, so it could be considered a separate resource for which data can be 
stored. And part of those data could be relationships with other graphs. 
That way a single triple could belong to multiple hierarchies (or 
graphs) of named graphs (one graph hierarchy for valid time, one for 
transaction time, one for access control, etc.).  Might not the Named 
Graph Vocabulary (http://www.w3.org/2004/03/trix/rdfg-1/) be used for that?


Greetings,
Frans

>
> 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
>>   


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------