Re: Property Path Profiles

Hi Ivan,

Basically, combinations of complex paths are not supported.

For example, { :v1 :myProp1* :v2 }, { :v1 :myProp2+ :v2 }, and { :v1 
:myProp3? :v2 } are all supported, but { :v1 
:myProp1*/:myProp2+/:myProp3? :v2 } is not supported.

Hope this helps,
-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
>>
>>
>>
>>     
>
>