[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] idas model as entities
|
Paul,
Are you using some OWL 1.1 aware drawing tool? Maybe just
wishful thinking on my part ...
Tom
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 8:58 PM >>>
Jim,
Here*s another comment about the [0..3] thing. As you can see below in
OWL
subclass the maxCardinality concept is captured in what*s called a
restriction*a class. [Interesting side note: Every entity shown in a
rectangular box has an EntityID although the bottom- most one (the
restriction) is really a blank entity that has been dynamically
assigned the
entityId of *pcrd:email max 3* by the drawing tool I*m using]
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.
>
>
>
> Where did the "[0..3] get introduced? I see it where pcrd:email
shows that
> on Person, but not on the data range.
>
>
>
> Do we want to do this in Higgins/IdAS?
>
>
>
> 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.ow
> l#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:pat
> tern> <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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
