W3C home > Mailing lists > Public > public-lod@w3.org > June 2009

Re: Visualization of domain and range

From: Bernhard Schandl <bernhard.schandl@univie.ac.at>
Date: Sun, 28 Jun 2009 09:44:29 +0200
Cc: Dan Brickley <danbri@danbri.org>, Simon Reinhardt <simon.reinhardt@koeln.de>, public-lod@w3.org, public-semweb-ui@w3.org
Message-Id: <CC9C48D2-3FBF-4D11-B314-63296120309A@univie.ac.at>
To: Tim rdf <timrdf@gmail.com>

> Unfortunately, I want to employ an RDFS reasoner AND use the
> foaf:holdsAccount to point to /non/Online Accounts. I can't use it  
> because
> my /non/online Accounts WILL be interpreted as foaf:OnlineAccounts,  
> which I
> want to be satisfiably false (but is provably true).


> To fix this, we'd have to:
> - ( foaf:holdsAccount rdfs:range foaf:OnlineAccount . )
> + ( foaf:holdsAccount rdfs:range ns:Account .
> foaf:OnlineAccount rdfs:subClassOf ns:Account . )

Instead of changing the original FOAF ontology (which only the owners  
of the FOAF namespace can do), I would suggest that you add another  
property for your application and define it as super-property of  

foaf:holdsAccount rdfs:subPropertyOf ex:holdsAccount .

and use ex:holdsAccount instead of foaf:holdsAccount. However whenever  
you encounter a foaf:holdsAccount you can treat it as instance of  

> So, returning to my general question about asserting the domain and  
> range of
> a property. Is it prematurely limiting if the first-party developers
> inadvertently set the range to a /subclass/ of a class that a third- 
> party
> developer thinks is a reasonable range?

If you do not allow ontology developers to define restrictions on the  
classes and properties they define, then we end up with plain  
collections of terms, but without the possibility to derive useful  
conclusions from the data. However to build meaningful applications we  
need constraints on the data, and if you do not need these constraints  
you have two options: either do not use inference, or define your own  
(unrestricted) vocabulary and link it to the .

Best, Bernhard
Received on Sunday, 28 June 2009 07:45:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:15:57 UTC