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:
[[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.
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.
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 :-) )
> 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: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
> Does anyone have any thoughts on this?