Re: Restrictions on Bags and Seqs content

>Hi, Matthew!
>
>What you describe here, your array and your linked-list 
>construction, is what I referred to as "custom OWLList classes", and 
>(as far as I understood him) is pretty similar to what Alan 
>Ruttenberg was about in his two answers to Roberto's questions. And 
>as I said before, I think that such an approach (your approach!) is 
>(technically) the best one can do in OWL/DL.
>
>With my own analysis I only tried to answer Roberto's original 
>question: If it is somehow possible (in OWL/DL) to use an rdf:Bag 
>and build an allValuesFrom restriction for its members, and if it is 
>good practice to do so. My answer was, that it /is/ possible, but 
>with several ugly limitations, which few people would probably be 
>willing to accept. So no good practice at all!
>
>My opinion: One can, of course, always use a custom approach of the 
>form you and Alan proposed - it works. But I suppose that many 
>people will dislike the situation to always build their own custom 
>list types

We really only need one, and encourage everyone to use it. We could 
make it by replacing the OWL prefix by some other namespace, such as 
http://www.w3.org/2002/07/owllist#  and calling it 'owllist:'

>, while there is already a lot of collection vocabulary in RDF, 
>which they can only use either in a very limited way, like for 
>rdf:Bag and friends, or not at all, like for rdf:List. Perhaps, it 
>would have been wiser to not use 'rdf:List' in the OWL-to-RDF 
>mappings (like e.g. for the argument list of owl:intersectionOf 
>expressions), but instead use a custom OWLList for this purpose.

That is what probably should have been done, give that the DL purists 
insisted on putting that vocabulary out of bounds. But oh well, its 
too late now.

>  This would have resulted in some inconveniences when writing down 
>things like intersection expressions with many classes in RDF/N3 or 
>RDF/XML, where rdf:ListS are supported by special syntax. But then, 
>it would have been at least possible to use rdf:List in OWL axioms, 
>if I correctly understand the situation (FIXME if I'm wrong!).

Yes, that is correct. The key point is that you aren't allowed to use 
*in* OWL-DL the same vocabulary that OWL-DL itself *uses* to encode 
OWL syntax in RDF. (Because if you did, you *could* then screw up the 
OWL-DL syntactic mappings, if you were to be bloody-minded about it, 
and part of the DL philosophy is to provide guarantees of not being 
screwupable.)

This applies only to OWL-DL: there is nothing intrinsic to OWL that 
prevents this usage, and it is quite legal and meaningful in OWL-Full.

Pat

>But other people here will probably disagree with this view. :)
>
>
>Cheers,
>Michael
>
>Matthew Pocock wrote on Tue, 10 Apr 2007
>
>>Hi,
>>
>>Not sure if this kind of modelling will throw OWL reasoners for a 
>>loop, although I'm sure someone on this list will know. Is there a 
>>reason you can't explicitly have a collection individual and a 
>>member_of_collection style property that binds an instance to the 
>>collection?
>>
>>For the case of a list, you can introduce a qua on the instance 
>>that stands for the membership of the list. So,
>>
>>array <-member_of- member -refers_to-> someIndividual
>>
>>Where member has a property index, and index is set to be unique 
>>with respect to the array instance, and the presence of a member 
>>with index x imples the existance of a member with every index >=0 
>>and < x. Alternatively, use a linked list with e.g. a head/cons 
>>pair of relations and cardinality restrictions to prevent 
>>unintended branching.
>>
>>Using collection instances like this you can restrict 
>>someIndividual to a specific class by placing a universal 
>>restriction on the inverse of member_of that places a universal 
>>restriction to revers_to on that class. So:
>>
>>PersonArray == Array &
>>   all inverse(member_of) all refers_to Person
>>
>>The member qua instances tend to be useful places to hang other 
>>things than the index from, if the individual at that index in the 
>>list needs treating differently to the individual at other indexes 
>>or independent of the list.
>>
>>Sorry if you've been up and down this kind of solution already.
>>
>>Matthew


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 11 April 2007 21:58:46 UTC