Re: UNSAID and OR use cases, from PRIME

Seconding Thomas' suggestion.

It pretty obvious that many implementers are going to implement analogs 
of OR and NOT
whether or not SPARQL sanctions them or not.  From an implementation 
standpoint,
these operators are no more difficult than the OPTIONAL clauses, and 
much better
understood.  Semantically, OR is pretty straightforward.  Possibly 
NOT/UNSAID would
require a bit of care, but that's what Pat Hayes and PFPS are here for, 
is it not?

If the problem is "trying to find a lowest common denominator that 
everyone can
implement", I'd recommend having a SPARQL Lite with no OR and UNSAID,
and a SPARQL Full that has them.

The obstructionists keep shouting "use cases" whenever issues like these 
come up.
I regard SQL was a mountainous use case that dwarfs the sum of all 
extant RDF
use cases.  That means that we should also be including ORDER BY and 
GROUP BY
in SPARQL Full, an IN operator, and various other SQL flotsam that have been
very heavily blessed.

Cheers, Bob



Thomas Roessler wrote:

>Hello,
>
>for PRIME [1] purposes, it would be preferable to have both UNSAID
>and OR clauses in SPARQL.  The project envisions translating APPEL
>[2] type queries into RDF queries.  This would be difficult without
>negation and both OR, and AND.  Design of the project's software
>architecture is currently ongoing, and would be affected by
>decisions to drop or include the UNSAID and OR clauses.
>
>Two possible use cases are included below.
>
>[1] http://www.prime-project.eu.org/
>[2] http://www.w3.org/TR/P3P-preferences/
>
>
>Use case 1, PRIME; UNSAID and OR: A mobile phone provider offers
>location and contact information to third parties which, in turn,
>offer location-based advertising by mobile phone short message.  An
>airline operates an airport restaurant as a subsidiary, which wants
>to advertise a special gourmet meal based on pork to members of the
>airline's frequent flyer program who are nearby the restaurant,
>unless these have indicated halal, kosher, or vegetarian meal
>preferences.
>
>(Note that meal preferences give hints about religious convictions
>and health conditions, and should as such not be processed by a
>restaurant's advertising department.)
>
>
>
>Use case 2, non-PRIME; UNSAID: A financial institution in Europe
>wants to query an RDF database of its extremely wealthy clients to
>send out an investment prospectus.  The prospectus must, however,
>not be given to persons within the US or Canada, since the financial
>institution wants to avoid SEC jurisdiction.  ("This prospectus is
>not to be sent or given to any person within the United States or
>Canada" is actually a standard clause in such documents.)
>
>Speaking more generically, UNSAID queries enable access-controlled
>queries which are based on *restrictions*, as opposed to explicit
>*permissions*.  They would also enable data using parties to ask for
>all attributes of a certain entity, unless these attributes are of a
>certain type.
>
>
>
>If you have any questions, feel free to contact me.
>
>Regards,
>  
>

-- 

Bob MacGregor
Chief Scientist

	
	Siderean Software Inc
390 North Sepulveda Blvd., Suite 2070
<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=5155+Rosecrans+Ave&csz=Hawthorne%2C+Ca+90250&country=us> 
El Segundo, CA 90245
bmacgregor@siderean.com <mailto:bmacgregor@siderean.com> 	
tel: 	+1-310 647-4266
fax: 	+1-310-647-3470