Re: SubObjectPropertyChain question

On 3/9/07 10:16 PM, Xiaoshu Wang wrote:
>
> Sirin,
>
>> Note that, these definitions do not have a meaning in OWL-DL. Both 
>> rdfs:subsPropertyOf and rdf:List (as other built-in vocabulary) are 
>> considered to be part of syntax in OWL-DL.
> Hmm...I am not sure I understand this.  From my understanding, 
> rdfs:subPropertyOf and rdf:List are not the "syntactic construct" like 
> the rdf:Description.  They are the actual semantic constructs.  
No, not in OWL-DL. I was talking about OWL-DL semantics which is 
different than RDF (or RDF-compatible OWL-Full) semantics. These are not 
syntactic constructs in RDF.
> Otherwise, an RDF parser has to treat "rdfs:subPropertyOf" 
> differently, and it seems to me that breaks the backward compatibility.
>>> I wonder if it be cleaner to translate this as an Axiom.  For 
>>> instance, define a term called owl11:ObjectPropertyChainAxiom and 
>>> assign it two property "propChain" which ranges over an rdf:List and 
>>> a superProp ranges over an Object.  So it would be something like
>>>
>>> _:x rdf:type owl11:ObjectPropertyChainAxiom;
>>>      owl11:propChain T(SEQ p1, ... pn).
>>>      owl11:superProp op.
>> With a different motivation, sometime ago I suggested the following 
>> alternative syntax (possibly with different keywords):
>>
>> <owl11:PropertyChain>
>>  <owl11:members rdf:parseType="Collection">
>>       <owl11:ObjectProperty rdf:ID="p1"/>
>>        ...
>>   </owl11:members>
>>   <rdfs:subPropertyOf rdf:resource="#p"/>
>> </owl11:PropertyChain>
> This works fine with me except that I don't think the 
> <rdfs:subPropertyOf/> should be used.  The reason is the same as I 
> raised before, it will suggest <owl:PropertyChain> is a rdf:Property, 
> which is not, because the chain is a composition of properties.  
Ok, I think now I better understand your concern. In your first message, 
you mentioned OWL 1.1 not being in OWL-DL species. But you actually seem 
to be more concerned that OWL 1.1. property chains cause problem w.r.t. 
RDF semantics. I see your point.
> Use another property name will make it separate cleanly.
>>> Another question about the document is why all collection is 
>>> transformed to rdf:List.  Most should be a BAG.  In RDF/XML, writing 
>>> a list is quite cumbersome, but for BAG, parsetype="Collection" can 
>>> be used.  I wonder it is just a careless of writing or is there a 
>>> reason that rdf:List must be used?
>> I think there is a confusion here because parseType="Collection" is 
>> used for rdf:Lists. The only requirement is that the list be an 
>> object of a triple. However, the current specification maps the 
>> rdf:List to a subject position which makes it impossible to use 
>> parseType="Collection".  With a different encoding (like the one you 
>> or I suggest) it would be possible to use parseType. Even though we 
>> think RDF/XML is not for humans to look at, sometimes it is 
>> inevitable (sigh!) and I think these kind of shortcuts would be useful.
> Oh, is it (that parseType can be used for rdf:List)?  I thought the 
> ordering of subelement of a parseType="Collection" is arbiturary. 
No, it is not. The RDF parser should generate the list elements in the 
order specified in XML. However, depending on the application the order 
of list elements may not be important (e.g. in OWL constructs list order 
has no significance).
> (Or it will used for rdf:Seq, rdf:Bag, rdf:Alt) but work for rdf:List 
> as well?
No, parseType="Collection" is only intended for rdf:List and it 
generates rdf:first and rdf:rest triples as explained in [1]. RDF 
containers (Seq, Bag, Alt) are described using rdf:li property which is 
translated to built-in properties rdf:_1, rdf:_2, etc [2].  RDF primer 
[3] has examples and explanation regarding containers and collections.

Regards,
Evren


[1] 
http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-parsetype-Collection
[2] http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-list-elements
[3] http://www.w3.org/TR/rdf-primer/
>
> Xiaoshu
>
>

Received on Monday, 12 March 2007 02:07:14 UTC