Re: Profiles intro

i was picking up on some issues other mentioned to try to lend support.
you are right - from a strictly application-oriented view, i do not care 
how the queries are answered.
in some settings, i have some rdf only data (that does not use any owl) 
and some owl data intermixed. 
i also have some settings where people are comfortable with rdf and rdf 
graphs and sparql so it is nice to be able to be compatible with things 
they understand.

my main point for the profiles document was to describe to applications 
people why they might choose a particular profile.
my main point for following up to michael schneider's post was that i 
also had users who would like what he was describing - although no doubt 
we could describe it differently (and get away from an implementation 
focus).

deborah

Bijan Parsia wrote:
>
> On 9 Apr 2008, at 20:00, Deborah L. McGuinness wrote:
>
>>
>> just to add some support to this thread
>> 1 - i am strongly supportive of this need for having simple 
>> understandable descriptions of at least one kind of user we believe 
>> should use each fragment.
>> 2 - on the 3 points below, if i had 2 and 3 below, i would use them 
>> right away.
>
> I.e., if you had a scalable system, that would drive your choice here :)
>
>> my restatement of what i would use today would be:
>>
>> 2a Creating inference graphs from RDF data by performing rule-based 
>> forward chaining thus making information that is implicit in the rdf 
>> explicit in the rdf graph.
>
> I don't know why this is a desiderata for *any* user. It seems very 
> implementation oriented to me.
>
>> 3a  Efficiently querying the resulting inference RDF graph with 
>> standard web query languages including SPARQL.
>
> But this specifies an implementation technique. What do you care if 
> your sparql queries are evaluated by computing a bigger rdf graph 
> instead of some other technique as long as you get the same answers 
> for acceptable resource consumption?
>
> In other words, I thought the missing bit wasn't about the 
> computational properties (Carsten's did a good job), it's about the 
> "fit" of the expressivity. I agree that this is a hard think to 
> describe. So, one (sorta false and not super *duper* useful) 
> description of this sort is that EL++ is designed for TBox heavy, 
> structurally complex ontologies (such as biomedical ones) and DL-Lite 
> can handle conceptual models and thus relational database federation.
>
> (Note that there's nothing wrong with being concerned with performance!)
>
> Cheers,
> Bijan.
>

Received on Thursday, 10 April 2008 05:39:41 UTC