Re: Property Path Profiles

Hi,

As a simpler alternative to different profiles, what about defining a 
third type of path? For example, we could define a /simple recursive/ 
path as a path that uses at most one *, +, ?. This path type would fit 
between simple and complex paths, so, in order of increasing complexity, 
we would have (1) simple paths, (2) simple recursive paths and (3) 
complex paths. This would provide an easy way to identify the set of 
property path queries that can be expressed with SQL.

-Matt

Ivan Herman wrote:
> Matt,
>
> to make things more understandable (for me:-) can you summarize what are
> the features in the current property path document[1] that are _not_
> covered? Ie, what do we give up if we use such profile(s)?
>
> Thanks for your help
>
> Ivan
>
> [1] http://www.w3.org/2009/sparql/docs/property-paths/Overview.xml
>
> On 2010-1-11 19:25 , Matt Perry wrote:
>   
>> Hi,
>>
>> During the last TC, I mentioned the possibility of a Property Paths
>> profile that identifies a subset of property path queries that can be
>> expressed with SQL. Such a profile would make it easy for triple stores
>> implemented on top of relational databases to identify the set of
>> property path queries that they "natively" support.  The purpose of this
>> email is to start a discussion about the possibility of property path
>> profiles.
>>
>> The grammars below show two possible fragments that we have identified.
>> The first grammar is for SQL + CONNECT BY (Oracle) and the second is for
>> PLAIN SQL.
>>
>> CONNECT BY:
>>
>> ALT  -> URI | URI|ALT
>> SEQ  -> URI | URI/SEQ
>> Elem -> URI | SEQ   | ALT   | ^URI
>> COMP -> URI | Elem* | Elem+ | Elem{n,m} | Elem?
>> TOP  -> URI | COMP  | ALT   | SEQ       | ^URI
>>
>> PLAIN SQL:
>>
>> ALT  -> URI | URI|ALT
>> SEQ  -> URI | URI/SEQ
>> Elem -> URI | SEQ       | ALT   | ^URI
>> COMP -> URI | Elem{n,m} | Elem?
>> TOP  -> URI | COMP      | ALT   | SEQ   | ^URI
>>
>> Thanks,
>> Matt
>>
>>
>>
>>     
>
>