SEssaid / connect-isf

Automatically exported from code.google.com/p/connect-isf
0 stars 0 forks source link

property-curated.owl #5

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The curated file that will contain the final version of ISF properties.

Original issue reported on code.google.com by sha...@essaid.com on 25 Sep 2012 at 8:54

GoogleCodeExporter commented 9 years ago
Used vivo foaf http://xmlns.com/foaf/0.1/firstName data property to replace ero 
http://purl.obolibrary.org/obo/ERO_0000042. This property is functional!

Original comment by sha...@essaid.com on 25 Sep 2012 at 9:03

GoogleCodeExporter commented 9 years ago
Used vivo foaf http://xmlns.com/foaf/0.1/lastName to replace ero 
http://purl.obolibrary.org/obo/ERO_0000049. This property is functional!

Original comment by sha...@essaid.com on 25 Sep 2012 at 9:05

GoogleCodeExporter commented 9 years ago
Added http://xmlns.com/foaf/0.1/Person, and asserted it to be an OWL class. It 
is the range of firstName and lastName.

Original comment by sha...@essaid.com on 25 Sep 2012 at 9:06

GoogleCodeExporter commented 9 years ago
Used vivo http://vivoweb.org/ontology/core#phoneNumber to replace ero 
http://purl.obolibrary.org/obo/ERO_0000051. There are annotations from the ero 
version that could be moved to the the vivo one. The vivo one was used because 
it also has a more specific subproperty "primary phone".

Original comment by sha...@essaid.com on 25 Sep 2012 at 9:16

GoogleCodeExporter commented 9 years ago
Added http://xmlns.com/foaf/0.1/Agent and asserted as OWL class.

Original comment by sha...@essaid.com on 25 Sep 2012 at 9:16

GoogleCodeExporter commented 9 years ago
Adopting the vCard model for addresses and similar entities as an experimental 
replacement for the current entities. Needs review.  The vCard model is from 
http://www.w3.org/TR/vcard-rdf/  and the owl file is at 
http://www.w3.org/2006/vcard/ns. The needed entities are being copied.

Original comment by sha...@essaid.com on 25 Sep 2012 at 11:05

GoogleCodeExporter commented 9 years ago
Using http://www.w3.org/2006/vcard/ns#street-address  instead of 
http://vivoweb.org/ontology/core#address1, 
http://vivoweb.org/ontology/core#address2, 
http://vivoweb.org/ontology/core#address3.

We can still add the 1/2/3 versions as subtypes if they are really needed. They 
will still be understood as a vCard street address.

Original comment by sha...@essaid.com on 25 Sep 2012 at 11:08

GoogleCodeExporter commented 9 years ago
Using http://www.w3.org/2006/vcard/ns#locality instead of 
http://vivoweb.org/ontology/core#addressCity.

Original comment by sha...@essaid.com on 25 Sep 2012 at 11:10

GoogleCodeExporter commented 9 years ago
There is no "contact" class in the current vivo or ero model. The above vCard 
model has a "vCard Class" OWL class that is a class of vCard instances and the 
instances can then be the domain of various contact related properties. Also, 
the vCard model states the following comment on the "vCard Class":

"Resources that are vCards and the URIs that denote these vCards can also be 
the same URIs that denote people/orgs"

In other words, we can use a new URI for an instance of a vCard, or use the 
same resource (instance) URI that the contact information is about, as the 
subject of vCard statements.  However, if we follow the second option, we can 
only have one type of contact information. On the other hand, the first options 
gives us the option of giving a resource many contact instances (of the same or 
different type) to capture multiple contact. The following comments show how 
the first approach is being implemented in the ISF.

Original comment by sha...@essaid.com on 26 Sep 2012 at 3:04

GoogleCodeExporter commented 9 years ago
Added a top level "contact" class as the root of all types of contacts.

Original comment by sha...@essaid.com on 26 Sep 2012 at 3:08

GoogleCodeExporter commented 9 years ago
Added the class http://www.w3.org/2006/vcard/ns#VCard from vCard and asserted 
it to be a subclass of the top "contact" class to represent the "vCard" type of 
contacts.

Original comment by sha...@essaid.com on 26 Sep 2012 at 3:13

GoogleCodeExporter commented 9 years ago
The vCard model uses the general rdf:value property to capture values. This 
property is a general property to capture what is considered a value in any 
context. See http://www.w3.org/TR/2004/REC-rdf-schema-20040210/#ch_value.

An example from the vCard is:
v:tel
   [ a v:Work, v:Cell, v:Pref ;
     rdf:value "+61 7 5555 5555"
   ] 
where the rdf:value is used to capture a telephone number. There is no vCard 
specific property to capture such a value. 

The rdf:value property (a rdf:Property instance) has a domain and range of 
rdfs:Resource. This means that the range of the property can be an OWL 
Individual or a Literal. However, the OWL specification does not allow the use 
of the same URI as a DataProperty and an ObjectProperty and this would cause 
problems for reasoners. With this in mind, and wanting to have a similar 
general "value" property (at least for DataProperty) that is compatible with 
the rdf:value and with OWL, we could declare a dataValue DataProperty and make 
it a subProperty of rdf:value. We can do the same for a objectValue property if 
needed. There is an issue with how the OWL-API handles RDF entities, it 
frequently treats a rdfs:Resource as a owl:AnnotationProperty but I do not 
think that this should be a problem.

Original comment by sha...@essaid.com on 26 Sep 2012 at 5:50

GoogleCodeExporter commented 9 years ago
Added a "has_contact" object property with a "contact" range.

Original comment by sha...@essaid.com on 26 Sep 2012 at 5:59

GoogleCodeExporter commented 9 years ago
Replaced http://vivoweb.org/ontology/core#contactInformation with the following:

1. The subject is asserted to have a "has_contact" object relationship to an 
instance of "contact"

2. The "contact" instance has a "has_data_value" property to the same literal 
that the original property above was used to capture.

This is a very general way to capture contact information as literal strings 
instead of using one of the subtypes of "contact" such as a vCard instance.  
The same "has_data_value" can also be used with the more structured "contact" 
types to capture a (derived) literal representation of the structured data if 
needed. This is similar to how a Java object has a toString() method that can 
be used to returns a string representation of a structured object.

Original comment by sha...@essaid.com on 26 Sep 2012 at 6:07

GoogleCodeExporter commented 9 years ago
Replaced http://vivoweb.org/ontology/core#email with object property 
http://www.w3.org/2006/vcard/ns#email to a vCard Email class.

Original comment by sha...@essaid.com on 26 Sep 2012 at 8:26

GoogleCodeExporter commented 9 years ago
Replaced http://purl.obolibrary.org/obo/ERO_0000041 "contact email" with 
http://www.w3.org/2006/vcard/ns#email as above. The definition states that this 
is the primary email but there is no other non-primary email property. VIVO has 
a primary version. We should probably generalize this to 
contact/primary-contact instead of doing it at each level (email, phone, 
address, etc.)

Original comment by sha...@essaid.com on 26 Sep 2012 at 8:57

GoogleCodeExporter commented 9 years ago
The vivo data property "primary email":  the vCard model has a data property 
"category" that is used to categorize a vCard instance. We can use this 
property to indicate primary from other. I am not sure if there is a set of 
predefined categories. TODO

Original comment by sha...@essaid.com on 26 Sep 2012 at 9:01

GoogleCodeExporter commented 9 years ago
The vivo fax http://vivoweb.org/ontology/core#faxNumber replaced with the vCard 
"tel" object property and the "Fax" "Tel" subtype.  Added:
http://www.w3.org/2006/vcard/ns#tel (OP)
http://www.w3.org/2006/vcard/ns#Fax (subClassOf Tel)
http://www.w3.org/2006/vcard/ns#Tel

Original comment by sha...@essaid.com on 26 Sep 2012 at 9:16

GoogleCodeExporter commented 9 years ago
The FOAF vocabulary has as core terms "givenName" and "familyName" as preferred 
properties for first and last name. There is also a "name" property to capture 
a name as a string. "name" and "givenName" do not have a domain but 
"familyName, firstName, lastName" have "Person" as a domain. They are all 
intended to be used for persons.

Original comment by sha...@essaid.com on 26 Sep 2012 at 9:36

GoogleCodeExporter commented 9 years ago

Original comment by sha...@essaid.com on 9 Oct 2012 at 6:18