Re: Provenance for section 3 in technologies.tex

On Thursday, June 26, 2003, at 05:27  PM, Butler, Mark wrote:
>
> I do have additional an use case for contexts though which you may be
> interested in, based on my previous work on CC/PP. In CC/PP requests
> (normally HTTP) are augmented with CC/PP information about device
> capabilities and (some) user preferences. So you get a chain of  
> profiles
> e.g. the factory presets for the device, the user preferences for the
> device, an intermediate proxy etc each represented by an individual  
> profile.
> So one of the roles of CC/PP processors is to perform "resolution" i.e.
> determine when there are multiple values for the same property which  
> is the
> preferred property. In UAProf, a particular application of CC/PP  
> developed
> by the OMA (formerly the WAP Forum) they define rules called locked,
> override or append e.g. select the first value of an attribute, select  
> the
> last value of an attribute, or append all the attribute values  
> together.

interesting!

we have a similar scenario/use-case and requirements for the  
implementation of a flavoring system in our latest news searching  
service - where each user can tell to the system via an RDF file  
(parsed and processed on-the-fly and specified as a CGI parameter,  
using a cookie or HTTP headers) which are his/her own preferences and  
flavoring. For example, the same newspaper might be politically from  
the left for somebody while just center-left or right for somebody else  
- in addition a user could express that a specific source could be  
authoritative, conservative, neutral and so on. Such user preferences  
needs to be meshed together with some predefined (default) values also.  
Each profile describes newspapers channel or articles URLs with  
different or similar properties used for the news itself. Descriptions  
of articles (link, description, urls, acquisition time and so on) and  
user preferences (left/center/right,  
moderate/conservative/authoritative) are being put into different  
contexts/groups to avoid clashing into the RDF system. The immediate  
results is that having the news and the preferences expressed in RDF  
and referring to the same URIs (but in different contexts!) at search  
time is possible to select or gray-out some articles or sources, and  
present the news and pictures based on the specific user preferences.  
It is worth noting that this approach is completely different from  
other content syndication approaches existing today, where there is an  
assumption in there of central database or system storing and  
controlling either the news and the user profiles (e.g. where you  
register to a Web portal with your own preferences and "they know who  
you are"). With an RDF solution (like in the CC/PP /UAProf case I  
guess) the system can be completely dynamic and decentralized by using  
descriptions of common URI references (e.g. the user might change  
his/her local RDF profile, for example to band a channel or article  
without requiring any expensive centralized CMS).

http://demo.asemantics.com/biz/radio/?profile=http:// 
www.asemantics.com/people/zac.rdf
http://www.asemantics.com/people/zac.rdf

But IMO, what is even more fundamental here is the need to have some  
way into the RDF system to distinguish between RDF descriptions about  
the news, descriptions about user preferences and so on. An this is  
where source identification, contexts, provenance, scopes or whatever  
you want to call them :) are going to be of relevance for the success  
of any RDF system

>
> When I was implementing CC/PP and UAProf I found it quite hard to  
> implement
> these resolution rules, at least when performing the merge in a single
> model, so in the end I just created an RDF model from each profile  
> then read
> that information into another data structure to perform the merge.  
> However I
> note this problem could also be solved with contexts e.g. you would  
> place
> each profile into a different context, and use a query mechanism that
> supports contexts (which I understand RDFstore does) to perform  
> resolution
> as part of query. The UAProf standard is well documented, and in  
> addition I
> have quite a few reports on my implementation on my web page so it  
> might be
> an interesting experiment to apply your architecture to this problem,
> although as I am working on SIMILE I'm afraid I can't undertake to do  
> this
> myself :)

it would be interesting to have a look to some of those CC/PP profiles  
and have a try :-) let's talk about that off-list perhaps

>
>> BTW: while at www2003 I had a chat with Matt Biddulph about his RSS
>> codepiction code/demo and he seems to have similar problems and
>> solutions using Jena with reification to mimic contextual
>> information - that means that this aspect is going to fundamental for  
>> the
>> success of the whole Semantic Web and RDF systems to me
>
> Yes I agree. I think merging information from multiple sources while
> retaining context information is a pretty generic use case.  
> Furthermore I'm
> not as familiar with processing the :log namespace in cwm as other  
> people on
> this list probably are, but it seems to me that there are use cases  
> where
> "information destructive" context resolution i.e. you get all the data  
> and
> resolve it once is undesirable, especially for large problems. We can  
> do the
> same thing with quads in an information conservative way, although as  
> Andy
> has pointed out if you do further manipulation to the RDF after  
> merging it
> you get a problem because if may be harder to label the contexts of
> different statements. Of course, if you can avoid manipulating e.g.  
> you only
> add statements, you can get around this. Information destructive versus
> information conservative processing has been considered by some of
> theoretical computer science community (e.g. billard ball logic) do  
> you know
> of any papers that have considered this in relation to the SW and RDF?

I have to admit that I am not a logician and I do not have a background  
in logics as most of people on this list seems to have - to me the  
concepts above turned out to be pretty useful and straightforward to  
implement. I would really like to see some day a much clearer and  
exhaustive treatment of this provenance/context stuff in the RDF specs  
perhaps, due that users and developers will end up to invent them  
anyway :-)

I am afraid but I do not have any further reference to "billard ball  
logic" or similar theories - I will to dig into Sowa book here or  
google perhaps to get an idea of what you are referring to.

Yours

Alberto

Received on Friday, 27 June 2003 05:57:07 UTC