Hi Tim,
In general, my experience agrees with yours.
Many people find local class restrictions not user friendly. Their usability
concerns start with having to decide ‘should I do rdfs:subClassOf restriction
or owl:equivalentClass restriction’ before one can even begin to define the
nature of restriction. If a person is mainly concerned with classification of
resources (deriving their types), the set algebra way of thinking that is the
basis of OWL will align reasonably well, but if they are concerned with
describing classes for the purposes of data definition and data validation,
they tend to find this way of thinking pretty foreign.
The issue with “all” and “some” is similar. Then, of course, there is the issue
of open world semantics. It is probably not a secret that many people chose to
ignore open world assumption when modeling in OWL and use the syntax as if
semantics were closed world.
What you should do depends on the audience and what you are trying to
accomplish. In TopBraid EVN, for example, users can select from pre-built SPIN
templates for describing constraints as shown below:
These go beyond what one could do with OWL restrictions, but for the purpose of
this exercise, let’s consider the way to express min and max cardinality. User
would simply fill out the template like so:
Resulting information will look as follows:
example:Person
a owl:Class ;
rdfs:label "Person"^^xsd:string ;
<http://spinrdf.org/spin#constraint>
[ a
<http://spinrdf.org/spl#ObjectCountPropertyConstraint> ;
<http://spinrdf.org/arg#maxCount>
1 ;
<http://spinrdf.org/arg#minCount>
0 ;
<http://spinrdf.org/arg#property>
example:birthDate
] .
Hope this helps.
Irene
From: [email protected] [mailto:[email protected]]
On Behalf Of Tim Smith
Sent: Tuesday, August 05, 2014 10:41 AM
To: [email protected]
Subject: [topbraid-users] Replacing the semantics of local class restrictions
Hi,
I find the semantics of local class restrictions, particularly the use of
"some" vs "all", unintuitive for the less knowledgeable and not as friendly for
re-use when attempting to automatically discover the ontology within a
collection of triples.
Thus, I'm considering creating my own framework for declaring relationships
between properties and classes.
Before I do, is there any support for this within the current implementation of
SPIN?
I was looking through all of the available templates and it seems that
spl:Attribute may contain most of the semantics I wish to express such as:
1. Associating a property to a class
2. Defining the "type" of said property
3. Min/Max cardinality
Assuming I'm interpreting the intended use of spl:Attribute correctly, is there
a way to handle cases where the object of the property could be of type Class1
OR Class2 OR Class3... etc?
Thanks for your insight,
Tim
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
