Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] idas model as entities --ignore previous email

Title: Re: [higgins-dev] idas model as entities --ignore previous email
Jim, the N3 examples got scrambled by email. In case it happens again here they are repeated at the top:

pcrd:email   a   owl:DatatypeProperty ;      
  rdfs:comment "Generic email address as defined by Microsoft ISIP" ;      
  rdfs:domain person:Person ;      
  rdfs:range person:EmailDataRange ;
        
  higgins:category person:email-attributes ;
  higgins:displayOrder "1" ;      
  owl:equivalentProperty <http://xmlns.com/foaf/0.1/mbox> ;      
  skos:definition "Email address"@en ;     
  skos:example "ptrevithick@xxxxxxxxx" ;      
  skos:prefLabel "Email"@en .

person:Person   a  owl:Class ;     
  rdfs:subClassOf higgins:Person ;
  rdfs:subClassOf              
    [ a owl:Restriction ;                
      owl:maxCardinality "3"^^xsd:nonNegativeInteger ;                
      owl:onProperty pcrd:email              ] .

On 9/2/08 6:20 PM, "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> wrote:




On 9/2/08 5:58 PM, "Jim Sermersheim" <jimse@xxxxxxxxxx> wrote:

  

 Interesting.  So, it looks like something that could also be accomplished via multiple inheritance, but instead of introducing some of the problems of multiple inheritance, a Data Range" allows one to share just the validAttributes common to a set of different entity types.    

## A Data Range is something that you define and use in place of one of the std xml schema built-in types like integer or string. Any attribute type can simply define its “range” as being the id of the Data Range.

## Here’s the (N3) code for the pcrd:email Attribute Type in OWL 1.1. I’ve highlighted the relevant line

pcrd:email      a       owl:DatatypeProperty ;      
  rdfs:comment "Generic email address as defined by Microsoft ISIP" ;      
  rdfs:domain person:Person ;      
  rdfs:range person:EmailDataRange ;
        
  higgins:category person:email-attributes ;
  higgins:displayOrder "1" ;      
  owl:equivalentProperty <http://xmlns.com/foaf/0.1/mbox> ;      
  skos:definition "Email address"@en ;     
  skos:example "ptrevithick@xxxxxxxxx" ;      
  skos:prefLabel "Email"@en .
      
## Note: you can ignore all of the other lines than the red/highlighted one. I just included them to show what kinds of metadata (with the exception of owl:equivalentProperty —which is needed for the “community dictionary service” that some of us still dream of) are needed on Attribute Types for real-world apps that plan someday to support dynamic metadata-driven UIs.

 Where did the "[0..3] get introduced?  I see it where pcrd:email shows that on Person, but not on the data range.     

## Here is the OWL for the Person “Entity Class”

person:Person      a       owl:Class ;      
  rdfs:subClassOf higgins:Person ;      
  rdfs:subClassOf              
  [ a       owl:Restriction ;                
    owl:maxCardinality "3"^^xsd:nonNegativeInteger ;                
    owl:onProperty pcrd:email              ] .

 Do we want to do this in Higgins/IdAS?    

 ## I’m just showing that OWL provides a way to define entity classes and attribute definitions by recursively using entities and attributes. Our goal with IdAS is to put as little into the API as possible while supporting our use cases. Personally I think both min and max cardinality is worth including, yes.

 Jim

>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 3:26 PM >>>
    
 
 

 Hi Jim,

Speaking of models for datatypes...The OWL1.1 spec lifts all of the datatype definition stuff from xmlschema just as you are proposing. They have introduced a way to define what are called “Data Ranges”. Here’s an example of an “Entity Class” called “Person” in a context that uses the “person” namespace. This “Person” class makes use of Attribute Types links such as “pcrd:email” and “pcrd:phone” (where pcrd is the namespace for information card claim types). The reason I included this diagram is that the person ontology includes a datatype (DataRange) called EmailDataRange that is the “range” of the “person:work-email, pcrd:email.

Here is the OWL code to define EmailDataRange (RDF/XML):
   <rdf:Description rdf:about="http://www.eclipse.org/higgins/ontologies/2008/6/examples/person.owl#EmailDataRange">    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DataRange"/>    <owl11:pattern>^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$</owl11:pattern>    <owl11:onDataRange rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>  </rdf:Description>
Or N3 if you prefer:

person:EmailDataRange      a       owl:DataRange ;      owl11:onDataRange xsd:string ;      owl11:pattern "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}$" .

 “owl11” is the namespace for OWL 1.1.

-Paul

On 9/2/08 5:05 PM, "Jim Sermersheim" <jimse@xxxxxxxxxx> wrote:

      
 
 

 

   

 I previously made a misstatement.  validAttributes will always point at an "attribute type" definition.  It's the attribute type definition which might point at either a simple type (TBD in the model) or point at an entity (complex type) in the attribute type definitions data range.    

       

 Anyway, I'm looking at what needs to be in the definition of a data type.  I think we need everything available at http://www.w3.org/TR/xmlschema-2    
 

 In other words, we (possibly) need:    
 

 * a way to do derivation.  in xmlschema, this is done by restriction, list, or union    
 

 * a way to define the value space including constraining facets    
 

 * a way to define the lexical space?
    
 

 I don't really want to carve out space to define things regarding data types that no one will ever use.  Let's look at the xml schema "language" data type for example:    
 

   <xs:simpleType name="language" id="language">    
 

     <xs:annotation>    
 

       <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#language"/>    
 

     </xs:annotation>    
 

     <xs:restriction base="xs:token">    
 

       <xs:pattern value="[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"    
 

                   id="language.pattern">    
 

         <xs:annotation>    
 

           <xs:documentation source="http://www.ietf.org/rfc/rfc3066.txt">    
 

             pattern specifies the content of section 2.12 of XML 1.0e2    
 

             and RFC 3066 (Revised version of RFC 1766).    
 

           </xs:documentation>    
 

         </xs:annotation>    
 

       </xs:pattern>    
 

     </xs:restriction>    
 

   </xs:simpleType>    

       

 Do we need the ability to annotate? Do we want to allow people to specifiy derivation in terms of a restriction as shown here and allow for provide regex patterns?  What I'm wondering is whether this data will actually be read and used by IdAS consumers.    

       

 Jim
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 1:06 PM >>>
    
 
 

 My $0.02 inline ##.

On 9/2/08 2:40 PM, "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> wrote:

      
 
 
        
 
 

 

 
  

 My opinion is that it's fine.. I don't know how close we want to be to RDF/OWL, but if we want to be as close as possible, then we could do the following:

1. If we want to define what attributes an instance of a model can have, we may want to only have one property for that. I.e. only higgins:validAttributes, not higgins:attributeModelAttributes, higgins:entityAttributes, etc. This higgins:validAttributes is then basically the owl:inverseOf of rdfs:domain. I spent some time in #swig on irc.freenode.net <http://irc.freenode.net>  today.. It's funny, in RDF/OWL they have no way of saying that Class X can have Property Y. You can only say it the other way round, i.e. Property Y rdfs:domain Class X. What we want (higgins:validAttributes) is the exact opposite concept.

## That is correct. Properties (attributes) are first class objects in RDF. Takes some getting used to if you’re used to object oriented programming.

2. Allow minCardinality and maxCardinality only at the Entity Model, not at the Attribute Model.

## Yes. As a byproduct of the fact that properties are first class objects, you can use the same property with N>1 classes. Which means that the cardinality restrictions must be on the class not the attribute.

3. The idea that higgins:validAttributes has complex values is a slight contraction of what RDF/OWL people would do with rdfs:subClassOf and owl:Restriction, but it seems to be equally powerful, so that looks great to me.

Anyway, just ideas..

Markus

On Tue, Sep 2, 2008 at 7:31 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
        
 
 
          
 
 

 

 
  

     
 

 Paul, can you look over the latest text at http://wiki.eclipse.org/Higgins/ModelAPIs and let me know what you'd change?    

       

 re: attribute types: Right now, the entities that describe attribute types are named for the attribute type they describe so one might have the entityID "http://example.com/prop/fullname".  They currently are all of the type "http://www.w3.org/2000/01/rdf-schema#Property" (as per Markus' suggestion).  Also note that these attribute types only describe simple attributes since now complex attributes are entites (blank or named -- doesn't matter), so those are described as entity types (classes)    

       

 re: entity classes: Currently, the entities that describe entity classes are named for the entity type the describe so one might have the entityID "http://example.com/class#Person".  They currently are all of the type "http://www.w3.org/2002/07/owl#Class" (as per Markus' suggestion).    

       

 Jim

>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/01/08 8:19 PM >>>
    

 
 

 Jim,

I agree with Markus' general direction here.

A few words on terminology...

I'm going to assume that we call the entities that define new kinds of attributes "Attribute Types" (see the red links here http://wiki.eclipse.org/Attribute) and I'm going to assume that we call the entities that define new kinds of entities "Entity Classes". I don't have a word for the id of an Attribute Type. I'll just see how it goes referring to it as "Attribute Type id". This id might be a string (e.g. "eye-color") or an opaque URI (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality) or the UDI of a local Attribute Type entity.

-Paul

On 8/28/08 10:39 AM, "Markus Sabadello" <msabadello@xxxxxxxxxxxxx <http://msabadello@xxxxxxxxxxxxx> > wrote:

      
 
 
          
 
 
            
 
 

 

 
  

 
  

 Sounds great. To me it always felt a bit strange to have this separate "model" construct.

But the first thing that comes to mind when reading the page is, shouldn't the "Entity Model" of an Entity simply be that Entity's OWL Class, and the "Attribute Model" of an Attribute that Attribute's OWL Property? This would be consistent with RDF/RDFS/OWL, because Classes and Properties are Resources themselves.

Then for the "Person Model":
- getEntityID() returns http://example.com/some/name/space#Person (as on wiki page)
- getAttributes() returns http://www.eclipse.org/higgins/ontologies/2008/6/higgins#attributeTypes (as on wiki page)
- getAttributes() returns http://www.w3.org/2000/01/rdf-schema#subClassOf instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#supertype (values as on wiki page)
- getType() returns http://www.w3.org/2002/07/owl#Class instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#EntityModel

For the "Top Entity Model":
- getEntityID() returns http://www.eclipse.org/higgins/ontologies/2008/6/higgins#Entity (as on wiki page)
- getAttributes() returns http://www.eclipse.org/higgins/ontologies/2008/6/higgins#attributeTypes (as on wiki page)
- getType() returns http://www.w3.org/2002/07/owl#Class instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#EntityModel

For "Model for Entity Models" (built into Higgins):
- getEntityID() returns http://www.w3.org/2002/07/owl#Class instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#EntityModel
- getAttributes() returns http://www.eclipse.org/higgins/ontologies/2008/6/higgins#attributeTypes (as on wiki page)
- getType() returns http://www.w3.org/2002/07/owl#Class instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#EntityModel

For "Model for Model Elements":
- Don't think that's needed. It's the same as the previous one.

For "Attribute Model":
- getEntityID() returns http://example.com/some/name/space#homeAddress (as on wiki page)
- getAttributes() returns http://www.w3.org/2000/01/rdf-schema#range instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#valueTypes (values as on wiki page)
- getAttributes() returns http://www.w3.org/2000/01/rdf-schema#subPropertyOf instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#supertype (values as on wiki page)
- getAttributes() returns http://www.w3.org/2002/07/owl#minCardinality instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#minCardinality (values as on wiki page)
- getAttributes() returns http://www.w3.org/2002/07/owl#maxCardinality instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#maxCardinality (values as on wiki page)
- getType() returns http://www.w3.org/2000/01/rdf-schema#Property instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#AttributeModel

For "Model for Attribute Models" (built into Higgins):
- getEntityID() returns http://www.w3.org/2000/01/rdf-schema#Property instead of http://www.eclipse.org/higgins/ontologies/2008/6/higgins#AttributeModel
- getAttributes() returns http://www.eclipse.org/higgins/ontologies/2008/6/higgins#attributeTypes (as on wiki page)
- getType() returns http://www.w3.org/2002/07/owl#Class

Wouldn't that be much more consistent with RDF/RDFS/OWL and easier to understand? We would drop the term Model altogether and instead simply attach the Entity metadata and Attribute metadata directly on the OWL classes and properties. In fact, if I remember correctly this is the idea Paul and Valery and I had when talking about these things a while ago.

Also I think an advantage would be that the relation to the CP's schema (IContext.getSchema) would be much clearer. In fact you could even programmatically generate the schema using the calls above.

The only thing we'd have to invent is http://www.eclipse.org/higgins/ontologies/2008/6/higgins#attributeTypes, which would be defined in HOWL as follows:
<higgins:attributeType> <rdfs:inverseOf> <rdfs:domain>

Markus

On Thu, Aug 28, 2008 at 8:47 AM, Jim Sermersheim <jimse@xxxxxxxxxx <http://jimse@xxxxxxxxxx> > wrote:
 
 
 
            
 
 
              
 
 

 

 
  

 
  

     
 

 I started drawing a picture to represent what's being talked about at http://wiki.eclipse.org/Higgins/ModelAPIs <http://wiki.eclipse.org/Higgins/ModelAPIs> and I'm thinking there may be  some things I can optimize.  I'm going to run it by some ppl locally and then send something a little more refined.
 

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx <http://higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev

          
 
 
              
 
 
                
 
 

 

 
  

 
  

 
 
 
 
 
            
 
 
              
 
 

 

 
  

 
 
 _______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

          
 
 
            
 
 

 

 
  

 
 
 
 
 
          
 
 

 

 
 
 
 



Back to the top