Re: foaf/OWL

FWIW, my impression is that a solution for simple datatypes (strings,  
integrers, literals) would go a long way - in the groups I work with,  
the two main reason things are in Full are the use of rdfs;class,  
which we've discussed elsewhere, and this (and not typing external  
references, but it seems like most OWL tools  fix that).

On Nov 25, 2007, at 12:05 PM, Alan Ruttenberg wrote:

>
> On Nov 25, 2007, at 11:37 AM, Jim Hendler wrote:
>
>> Alan,
>>   Forgive me for disagreeing
>
> With the ifdt, ok. I said I wasn't holding my breath. What about  
> the other stuff?
>
> With respect to that issue, there are a couple of things. First, I  
> think the chatid properties need to be reworked. They need to be  
> extensible - there ought to be a way to add a new chat service, an  
> id in that service, and to be able to look up some information  
> about how to connect. For example, there is no standard way to add  
> a skype id currently.
>
> That leaves only the foaf:mbox_sha1sum. Currently, the range is   
> rdfs:Literal. This seems wrong - I expect that all clients expect  
> it to be a string. It certainly can't be an xsd:float, which is  
> licensed by this range.
>
> It seems to me that OWL-DL could handle the special case of  
> InverseFunctional string datatype properties by treating them as  
> individuals named within a reserved namespace, and considering  
> these properties to be in a class like "simple" properties, which  
> disallowed any other constructs that could result in the range of  
> the property becoming finite.
>
> Essentially, DatatypeProperty(foo range(xsd:string)  
> InverseFunctional) creates an additional, internal hidden property
>
> ObjectProperty(*foo range(owl:stringObject) InverseFunctional) and
>
> Individual(bar value(foo "12345")) generates an additional fact
>
> Individual(bar value(foo <http://owl/stringobject/12345>))
>
> Although this doesn't solve if datatypes in general, it would, I  
> think, solve the problem for the 50M or so foaf files, and  
> countless others that want *really simple* keys.
>
> -Alan
>
>> , but the solution is for OWL DL to figure out how to deal with  
>> inverseFunctional datatypes, not to refit the 50M or so FOAF files  
>> out there with "objects" that are really datatypes and should be  
>> datatypes - this issue was the one that split OWL DL from OWL FULL  
>> in the Owl 1.0 group, and remains unresolved.  I know there has  
>> been work in the DL community on providing "key" functionality,  
>> and Evren Sirin had a usable handling of it in his thesis work,  
>> but as best I can read the OWL 1.1 specs, it doesn't seem to have  
>> made it in.
>>  -JH
>>
>>
>> On Nov 23, 2007, at 8:45 PM, Alan Ruttenberg wrote:
>>
>>>
>>> For foaf, foaf-a-matic(http://www.ldodds.com/foaf/foaf-a-matic)   
>>> writes
>>>
>>> <foaf:workplaceHomepage rdf:resource="http:// 
>>> sciencecommons.org/"></foaf:workplaceHomepage>
>>>
>>> The species validator considers this OWL Full because
>>>
>>> Untyped Individual: Assuming http://sciencecommons.org/ is an  
>>> individual
>>>
>>> Elsewhere, we have that the domain of foaf:workplaceHomepage is  
>>> foaf:Document
>>>
>>> To get this to validate as DL(*)  I need to
>>>
>>> <foaf:workplaceHomepage><owl:Individual rdf:about="http:// 
>>> sciencecommons.org/"/></foaf:workplaceHomepage>
>>>
>>> This is an annoying bit of incompatibility with RDF. Any way to  
>>> fix it?
>>>
>>> -Alan
>>>
>>> (*) If the foaf ontology were itself valid as OWL DL.
>>>
>>> It's not that far off...
>>>
>>> Invalid Range Restriction: foaf:myersBriggs (ObjectProperty) has  
>>> rdfs:range rdfs:Literal (Datatype)
>>> (looks like a foaf bug - foafers: take note)
>>>
>>> Invalid SubProperty Axiom: rdfs:subPropertyOf is used with  
>>> foaf:name (DatatypeProperty) and rdfs:label (AnnotationProperty)
>>> (seems this could be handled on the OWL side - harm from the  
>>> subproperty going the other way, but not from Object/Datatype  
>>> property up to Annotation...)
>>>
>>> Multiple Types: Resource foaf:icqChatID is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>> Multiple Types: Resource foaf:jabberID is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>> Multiple Types: Resource foaf:yahooChatID is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>> Multiple Types: Resource foaf:msnChatID is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>> Multiple Types: Resource foaf:aimChatID is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>> Multiple Types: Resource foaf:mbox_sha1sum is defined both as  
>>> DatatypeProperty and as InverseFunctionalProperty
>>>
>>> All of these could be reasonably handled by making them objects.  
>>> I won't hold my breath. For all but the sha1sum, it seems there  
>>> is a reasonable analogy to mailto:
>>>
>>> -Alan
>>>
>>> ps. foafers: the link named foaf-dev@lists.foaf-project.org on  
>>> http://xmlns.com/foaf/spec/ is to http://lists.foaf-project.org/ 
>>> mailman/listinfo rather than to the expected mailto:foaf- 
>>> dev@lists.foaf-project.org
>>>
>>>
>>>
>>
>> "If we knew what we were doing, it wouldn't be called research,  
>> would it?." - Albert Einstein
>>
>> Prof James Hendler				http://www.cs.rpi.edu/~hendler
>> Tetherless World Constellation Chair
>> Computer Science Dept
>> Rensselaer Polytechnic Institute, Troy NY 12180
>>
>>
>>
>>
>

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180