On 3/24/2015 4:18 PM, Irene Polikoff wrote:
Scott, I believe we are saying the same thing,
but possibly interpreting David’s question in a slightly
different way:
<In TBC
forms to edit an instance, the button "show widgets for all
matching properties" somehow shows ALL my defined
properties.
I would like to see only the properties with domains
matching the types of my instance (that are really the
relevant properties for a given instance).>
I am interpreting the above as:
David is viewing or editing information about a
resource. He is clicking on the button"show widgets for
all matching properties" and is seeing in the Resource
Editor widgets that he thinks he should not see. He wants to
see only widgets for the relevant properties.
To which I am saying that yes, this is exactly how
it should work. If you see properties that “don’t belong”, you
should re-eximine the model.
But this is not how the feature works. It displays ALL property
values, regardless of property definitions. None are hidden. I.e.
it is an RDF interpretation of the resources property values - no
schema affects any of the property values.
Properties that appear in the form that *do not* have values appear
because either the property's domain is the class the instance
belongs to or a local class restriction includes the property.
Scott is interpreting this as:
David is able to add a widget for a property that
“doesn’t belong” by dragging and dropping it onto the Resource
Editor or by using “add widget for property” menu item in
Resource Editor or by building a custom form for the
resource's class and adding in the custom form a widget for
the property that “shouldn’t be there". He doesn’t want this
to be possible.
I quibble with the definition of "doesn't belong". If a property is
given a value for the resource, then it belongs. By RDF definition.
If you want to only have values that the model says should appear,
then then the definition of "doesn't belong" is re-defined to state
that a resource should only have property values that align with the
model's definition - through property domain or local class
restrictions. These are RDFS or OWL interpretations.
This is probably the source of the difference in perspectives. If
you work with Composer's form view, you will note that the RDF
definition of "belongs" is what is being defined. To state
something "doesn't belong" requires other definitions of what does
and doesn't belong in a resource's definition. Composer does do
this, but it only affects properties that **do not** have values -
these are displayed if the model defines them as Relevant
Properties.
To which Scott is saying that TBC will not prevent
a user from adding any property widget he wants because in RDF
one could use any property even if it is not in the domain of
the resource’s class (or its parent class or declared as part
of a restriction).
Yes. And all of this is quite aside from what the "Show widgets for
matching properties" does. Regardless of the definition of "belong"
or "doesn't belong", the only thing "Show widgets for matching
properties" will do is hide properties that do not have values.
That's it. Maybe it could instead be called "Hide properties
without values".
-- Scott
From: Scott Henninger < [email protected]>
Organization:
TopQuadrant, Inc.
Reply-To: < [email protected]>
Date: Tuesday, March
24, 2015 at 4:10 PM
To: < [email protected]>
Subject: Re:
[topbraid-users] Re: [TBC] : how to show only properties with
matching domains in forms ?
On 3/24/2015 2:50 PM,
Irene Polikoff wrote:
I think though that when this option is selected, the Form should contain widgets only for
properties a given Resource is in the domain of, or
properties that are restricted at the type of the
resource.
Irene, I think you are assuming that a form has been
defined. Regardless of whether a form is defined or not the
only difference selecting the "Show widgets for all matching
properties" will make is that only properties with values
will be displayed. I.e. properties whose domain includes
the selected resource, but do not have values, will not be
displayed.
To test this, open the kennedys model. Open an instance of
Person. By default a form is defined that displays a set
list of properties. Some of these properties have no
values. Now choose "Show widgets for all matching
properties". Only the properties with values is shown.
When it is unselected the Form
should show only widgets that have values in them.
No, it shows all property widgets that has the resources
class defined in the property's domain. Try this on a model
that does not have forms defined such as
TopBraid/Schema.org/faocountries.ttl
-- Scott
If you are seeing more than what
you expect, you may need to check your model. It may
be that these properties are defined for a superclass
and this is why they are showing.
From:
Scott Henninger < [email protected]>
Organization:
TopQuadrant, Inc.
Reply-To: < [email protected]>
Date: Tuesday,
March 24, 2015 at 3:35 PM
To: < [email protected]>
Subject: Re:
[topbraid-users] Re: [TBC] : how to show only
properties with matching domains in forms ?
Hello David;
Yes it is the case that "show widgets for all
matching properties" is designed to show all defined
properties for a resource. In RDF, it is perfectly
valid to have any property defined for a resource,
regardless of the property's domain definitions.
Will the Relevant Properties tab in the
middle-bottom row do what you want? See Composer
Help > User Interface Overview > Relevant
Properties View
-- Scott
On 3/24/2015 2:25 PM,
David Rouquet wrote:
What ? Nobody ?
This forum has never let me down before.
Let me know if I need to clarify my question !
Best regards
--
David
Le lundi 23 mars 2015 12:10:54 UTC+1, David
Rouquet a écrit :
Hi,
(Of course thanks for TopQuadrant products
and this very active group :-)
In TBC forms to edit an instance, the button
"show widgets for all matching properties"
somehow shows ALL my defined properties.
I would like to see only the properties with
domains matching the types of my instance
(that are really the relevant properties for
a given instance).
Is it possible without a custom forms that
would require to select relevant properties
for each instance type (fastidious...).
Best regards
--
David
You received this message because you are
subscribed to the Google Group "TopBraid Suite
Users", the topics of which include Enterprise
Vocabulary Network (EVN), Reference Data Manager
(RDM), TopBraid Composer, TopBraid Live, TopBraid
Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
---
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),
Reference Data Manager (RDM), TopBraid Composer,
TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL
Web Pages and SPIN.
To post to this group, send email to [email protected]
---
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),
Reference Data Manager (RDM), TopBraid Composer, TopBraid
Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and
SPIN.
To post to this group, send email to [email protected]
---
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), Reference Data Manager
(RDM), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
---
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), Reference Data Manager (RDM),
TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion,
SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
---
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), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
---
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.
|
