Paul; In terms of usability, this is always a contextualized
requirement dependent on the type of user.  TopBraid Composer provides
a standards-based UI for base ontology editing.  In addition TopBraid
Suite offers a number of ways to build interfaces that can meet
specialized requirements such as yours.  The SPIN constraints you
mention are an example of that.

In terms of modifying the datatype, the typical TBC user is expected
to be conversant in RDF, RDFS, OWL, and SPARQL.  Therefore you could
modify the type through the following query in the SPARQL view:

DELETE {?this events:someDate ?value .}
INSERT {?this events:someDate ?newValue .}
WHERE
{   ?this events:someDate ?value .
    BIND (xsd:gYearMonth(?value) AS ?newValue)
}

Note that the type case will make some modifications for you.  In this
example, if you started with an xsd:date, it will truncate the value
to year-month.  This is limited to what the RDF parser supports,
though.  For more specific casts, I'd suggest using regex as you did
in your example.  Also look at spif:regex which supports regex-based
replacement expressions.

If you want more of an end-user experience, then I'd suggest looking
into building an customized interface using TopBraid Ensemble, EVN,
Web Services (via SPARQLMotion), or SWP.

-- Scott

On Jan 5, 7:37 am, PaulZH <[email protected]> wrote:
> Indeed Holger this is cleaner.
>
> But there is also the user's perspective who doesn't always want
> separate properties for several potential datatypes, certainly when
> the datatypes are very close to each other such as xsd:date,
> xsd:gYearMonth, xsd:Year.
> In a real project in the Cultural Heritage domain where the properties
> startDate and endDate of a Period/TimeFrame are not always precisely
> known, the explicit change request came in to adapt the existing
> metadata management system to allow this.
> Looking to replace this system now, the potential alternatives should
> not have the same issue.
>
> But using SPIN constraints can help us along.
> ASK WHERE {
>     ?this :startDate ?date .
>     FILTER (!regex(?date, "^\\d{4}(-\\d{2}(-\\d{2})?)?$")) .
>
> }
>
> Another small usability issue in this area:
> If I enter as value:
> 1986^^xsd:gYear
> It is not possible to change the datatype later on to xsd:gYearMonth
> (understandable because the existing value pattern doesn't fit).
> But it would be easier to allow the switch and to indicate directly
> the error so the user can correct it.
> Now he is forced to delete the existing value and to restart or am I
> missing something?
>
> Paul
>
> On Jan 5, 3:01 am, Holger Knublauch <[email protected]> wrote:
>
>
>
>
>
>
>
> > I don't think we support that, and I would generally discourage such things 
> > from an ontology point of view. The problem is not just that UIs will find 
> > it hard to provide meaningful widgets - in your example we couldn't even 
> > display a date picker. The other problem is that any query on that data 
> > will have to walk through both cases, making it useless for SPARQL etc. 
> > Databases will also find it hard to optimize the literals if they can't 
> > find a suitable default ordering on them (to optimize FILTER and ORDER BY).
>
> > Why don't you define two properties with individual ranges? To work with 
> > such data you could then use constructs such as
>
> > <span>{= COALESCE(spl:object(?subject, :published_in_date), 
> > spl:object(?subject, :published_in_duration) }</span>
>
> > You could also turn the COALESCE above into a SPIN function so that it will 
> > get either the first or the second property, which ever is available.
>
> > Thanks
> > Holger
>
> > On Jan 5, 2012, at 6:17 AM, PaulZH wrote:
>
> > > How can I limit a property e.g. :published_in to or a xsd:date or a
> > > xsd:duration and that the corresponding field in the form accepts
> > > both?
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Group "TopBraid Suite Users", the topics of which include TopBraid 
> > > Composer,
> > > TopBraid Live, TopBraid Ensemble, SPARQLMotion 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
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion 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

Reply via email to