Thanks for the response. This confirms what I've been thinking - that, unless there are special circumstances, it should be the attribute that's modified, not the type.

I can foresee other special tags, to allow for, as you point out, numeric values:

[[greater than:=0]]
[[less than:=1000000]]
[[has unique value]]

...or if there's a string type whose length you want to control, you can have tags like:

[[size less than:=10]]

There are other tags that could be implemented - it might make sense to see what the needs are before implementing a whole slew. As I said before, I'm working on a mechanism to have forms for adding/editing data that might use some or all of these attribute tags.

-Yaron


On 2/27/07, S Page <skierpage@earthlink.net> wrote:
On February 11 2007, Yaron Koren wrote:

> There was an email thread around the first week of January on the
> subject of declaring "enum" types, meaning types that should have one of
> a fixed set of values. There were two ways noted to declare such a type:
>
> 1) In the field's "attribute" page, have a tag reading:
>
> [[possible values:=value1,value2,value3]]

That's what I checked in to Subversion and it's now running on
ontoworld.org, see http://ontoworld.org/wiki/Type:Enumeration and
http://ontoworld.org/wiki/Test_Enumeration , but it's not guaranteed to
be in released SMW 0.7.

Pro:
        simple

Con:
        you hit the string size limit really quickly
        harder to control numeric values
        values can't have commas in them without an escape syntax

> 2) In the field's "type" page, have tags reading:
>
> [[Enum mapping:=value1=1]]
> [[Enum mapping:=value1=2]]
> [[Enum mapping:=value1=3]]

That's what Ittay Dror implemented, and sent in the patch to SMW-devel.

> Which of these is recommended/supported? Or is it both? (In theory,
> there's no conflict between the two.)

I still mean to install his patch locally and compare.

> Tied in to this is the more general question of whether descriptive
> information like this should be stored in "attribute" or "type" pages. I
> suspect this question will get more important as SMW gains more
> structured features, like, say, OWL exporting, and forms for editing
> data (I'm working on something involving the second one).
>
> I can think of good arguments either way:
> - if you put the data in "attribute" pages, you don't have to create a
> custom type for each field that you want special handling for.
> - if you put the data in "type" pages, you can have special handling for
> relations, not just attributes (if you ever needed such a thing).

I don't understand.  Relations don't have types.

(SMW currently has almost no error handling for special properties like
[[has type]] , so you can slap them on any page and they'll show up in
the factbox even though only certain namespaces make use of them.  Seems
like a bug, though it makes playing around easy :-) )

> Also,
> you could have different attributes for the same type, with all the same
> properties (if don't know if you'd ever need that either).

Yes, you could have a Type:Severity and then use it for
Attribute:Bug_severity, Attribute:Torture_level,
Attribute:Scale_of_natural_disaster, etc.  That might be useful but why
not just separate attributes?

Some other things to consider:
* An attribute can "refine" handling of a type.  Currently floats can
specify the units to display, and by overloading display units, booleans
and dates can control display format.
* You can't currently query against the underlying type.
* One type can't extend another -- [[Has Type::Type:Foo]] doesn't work
for types.


> Does anyone have any thoughts on this?

--
=S Page