7 Jun 2008 00:56
[foaf-dev] Design of FOAF
Hi:
I was reading through the FOAF (N3 serialization), as a good example to use some of the design decisions there, to help in the design of our own ontology. I had some questions in the process and was hoping folks on this list could throw some light. These are not criticisms, obviously, but genuine queries of someone new to the intricacies of ontology design...
In FOAF:
1. Why are (re)defining terms, e.g. wot:assurance to be an owl:AnnotationProperty. It is already defined as an owl:ObjectProperty in the WOT ontology -- shouldn't we defer to that source ontology instead of defining our own, especially when AnnotationProperty and ObjectProperty are meant to be disjoint. How is th is being used?
2. Why do we have to define here what rdfs:Class, as in rdfs:Class is an owl:Class is? Shouldn't that be available to a reasoner from the RDFS ontology?
3. I see combinations of camel casing and underscore and other schemes for naming resources, properties with conjuctions of more than one word -- even for the terms FOAF defines itself. e.g. based_near and firstName. Wouldn't consistent naming have been better?
4. What is the way to modify/adapt (subtle or not not subtle) the semantics of a term / property -- example I don't want foaf:interest to be a "document", as in, foaf:Document. I may want it to be just a list of "terms" or concepts, or maybe "interest" in my application domain is not a document, but much broader, say owl:Thing, or whatever... Do I define my own property, how do I "extend" foaf:interest ? In gen eral what are the semantics of "is-a"; are they as strict as in OO type inheritance, where EVERYTHING TRUE about the super class must also atleast hold true about the subclass? I've seen IS-A used "loosely" in several RDFS/OWL documents. In FOAF for instance, many wide "wordnet concepts" are said to parents of foaf properties, but those wordnet concepts are open to wide interpretation, fuzzy semantics, and I'm not sure how we can definitively say, my class IS-A particular wordnet concept. What's an organizing principle in situations such as these?
Regards,
Revi
I was reading through the FOAF (N3 serialization), as a good example to use some of the design decisions there, to help in the design of our own ontology. I had some questions in the process and was hoping folks on this list could throw some light. These are not criticisms, obviously, but genuine queries of someone new to the intricacies of ontology design...
In FOAF:
1. Why are (re)defining terms, e.g. wot:assurance to be an owl:AnnotationProperty. It is already defined as an owl:ObjectProperty in the WOT ontology -- shouldn't we defer to that source ontology instead of defining our own, especially when AnnotationProperty and ObjectProperty are meant to be disjoint. How is th is being used?
2. Why do we have to define here what rdfs:Class, as in rdfs:Class is an owl:Class is? Shouldn't that be available to a reasoner from the RDFS ontology?
3. I see combinations of camel casing and underscore and other schemes for naming resources, properties with conjuctions of more than one word -- even for the terms FOAF defines itself. e.g. based_near and firstName. Wouldn't consistent naming have been better?
4. What is the way to modify/adapt (subtle or not not subtle) the semantics of a term / property -- example I don't want foaf:interest to be a "document", as in, foaf:Document. I may want it to be just a list of "terms" or concepts, or maybe "interest" in my application domain is not a document, but much broader, say owl:Thing, or whatever... Do I define my own property, how do I "extend" foaf:interest ? In gen eral what are the semantics of "is-a"; are they as strict as in OO type inheritance, where EVERYTHING TRUE about the super class must also atleast hold true about the subclass? I've seen IS-A used "loosely" in several RDFS/OWL documents. In FOAF for instance, many wide "wordnet concepts" are said to parents of foaf properties, but those wordnet concepts are open to wide interpretation, fuzzy semantics, and I'm not sure how we can definitively say, my class IS-A particular wordnet concept. What's an organizing principle in situations such as these?
Regards,
Revi
_______________________________________________ foaf-dev mailing list foaf-dev@... http://lists.foaf-project.org/mailman/listinfo/foaf-dev
> But this is not going to be a problem for long, and perhaps should not
> be a problem at all.
> Services such as 
dct:date in status.n3 is not even needed, HTTP does it all for you. If you wanted to not just describe your
current status but also past ones like in MeNow, you could do that with graphs:
{ :me foaf:based_near [ geo:lat 48.402495 ; geo:long 2.692646 ] } dct:date
"2008-06-12T12:00:00"^^xsd:dateTime .
{ ...
Or have each event in separate file linked to from status.n3.
Talking of events, this seems like the perfect case for the Event ontology [2]. An example:
:me event:isAgentIn [ # Note that this inverse property is deprecated but it makes it easier to write this in RDF/XML.
a event:Event ;
event:time [
a tl:Interval ;
tl:at "2008-06-12T12:00:00"^^xsd:dateTime ;
tl:duration "PT1H"^^xsd:duration
] ;
event:place [
geo:lat 48.402495 ;
geo:long 2.692646
] ;
event:factor :mytv , :mybeer ;
dct:description "Havin' a Bud, watchin' a game"^^xsd:string
] .
I really like this ontology and think it should deserve way more attention. 
RSS Feed