Hi Jeremy,
Yes, sure, fields have always been possible for such use, also in classic
TW.
The power of such semantics would however lie in how it would provide a
standard for semantic modeling, something that isn't intrinsically clear
with fields, e.g. basic methods that allow to leverage the power of such
qualified tags, in fact, even "tag fields" or "tag slices" that work
equivalently.
Now what do I mean by that?
Obvious, the first and most simple usecase were to make use of it in the
list macro, e.g. something like...
<<list [tag[task]] [by[owner]]>>
<<list [by[parent]]>>
Which could result in a grouped output of tasks by owner or children by
parents.
Another example would be some sort of list query, e.g...
<<list [tag[task]] [where[owner=John]]>>
<<list [where[parent=John]]>>
And further tools that would allow to change semantic tags between
equivalent members of a qualified set, e.g.
Change [[John]](owner) to [[Jane]](owner)... while constraining the
*initially* available options to all those that are...
-- either explicitly tagged as [[owner]]
-- or implicitly already used as [[Jane]](owner) or
[[John]](owner) throughout the wiki
...but, of course, also giving a generic selection that would hence turn
any other tiddler into a semantically qualified "owner", explicitly or
implicitly.
These were a few quick examples of the top of my head of how working with
such semantic qualifiers would signitficantly enhance modeling abilities
and most importantly, reveal implicit relationships for programatic
exploration that don't require the code to know that a "parents" field
actually defines a relationship.
So, the overall reason for enhancing tags this way would be that tags today
are, perhaps for good reasons, too dumb.
~
However, of course, this could definetely be modeled via fields as well. An
approach might be to turn a generic field into "semantic field", i.e. one
defining a relationship at any tiddler in terms of a bracketedList ...upon
which to build further functionality.
This could somewhat easilby be achieved by having a SemanticFieldList
tiddler or setting which defines all fields that are to be interpreted as
both semantic qualifiers and tiddlers and, most importantly, would yield in
*displaying* the field and it's information equally as prominent as tags.
For example, if I defined [[SemanticFieldList]] as a simple breacketedList
of...
[[parent]]
[[owner]]
Then UI would then automatically...
* display such semantic data values at given tiddler more prominently in a
"semantic fields" block
* make the semantic field names clickable, linking to tiddlers that detail
their function
* provide standard lists below such semantic field-tiddlers with qualified
members
* allow for managing the values of semantic relations in the way described
before
* correct any existing semantic relations upon changing tiddler names (!)
Come to think of it, the field-approach seems a lot more elegant and
extensible than perhaps to enhance tags. All in all, the goal would be to
make establishing and managing semantic relations much easier than it is
today in terms of general methods to introspect and change such relations.
Perhaps such a [[SemanticFieldList]] tiddler should rather be in the form
of (pseudo) JSON, e.g...
parent : {
max: 2,
info: "a parent of a person"
}
member : {
info: "a member to a group"
}
owner : {
max: 1,
info: "the owner of a task"
for: [tag[task]]
selection: [tag[member]]
}
date-of-birth: {
type: date
}
In this way, the capabilities could be enhanced little by little, e.g.
looking at the above owner definition the UI (or field validation) would
only allow one owner to any tiddler, display the info "the owner of a task"
as a tooltip or otherwise to that smenatic field being displayed, would
perhaps only display this field as a semantic field *for* tiddlers tagged
[[task]] and only allow those tiddlers for selection as owners that are
tagged [[member]].
All of this starts to very much resemble something I had been pondering a
while back yet never got to it...
http://xfieldsdev.tiddlyspace.com
Cheers, Tobias.
On Tuesday, 20 August 2013 10:01:09 UTC+2, Jeremy Ruston wrote:
>
> Hi Tobias
>
> That's a good summary of how qualified tagging could work. I'm not sure
> about the best syntax, the simpler tag:qualifier still seems attractive
>
> A somewhat similar effect can be achieved at the moment with TW5 by
> putting each qualifier in a separate field. For example:
>
> {title: "John", qualifier-parents: ["Jack"], qualifier-next-of-kin:
> ["Jack", "Jill"], text: "..."}
>
> In effect, each of the qualifier-xxx fields is a separate "tags" field
> with an implied qualifier.
>
> Best wishes
>
> Jeremy
>
>
> On Tue, Aug 20, 2013 at 3:09 AM, Tobias Beer <[email protected]<javascript:>
> > wrote:
>
>> Addendum,
>>
>> As for semantics, somewhat relevant may be...
>> http://semantic.tiddlyspace.com
>>
>> Also, there could at some point be a UI that allows to define a "semantic
>> tag" by chosing the tag target from a given set, e.g. by TW knowing that
>> potential "parents" are [[John]] and [[Jane]] and then offering them first
>> for tagging in terms of a "child of" tagging relation... all other tiddlers
>> being listed subsequently.
>>
>> For example, if the semantic qualifier [[parent]] were a tiddler and all
>> members of it would tag to it, then it would be easy for TW to figure out
>> the existing options, e.g.
>>
>> * semantic qualifier = [[parent]]
>> * [[Jane]], [[John]] <tag to> [[parent]]
>>
>> I want to define the a semantic tag for [[Billy]] in terms of assigning
>> both [[Jane]](parent) [[John]](parent).
>>
>> Eventually [[Jane]] could also tag to a generic [[mother]] and John to a
>> generic [[father]] if one wanted so and then assign Billy as follows:
>>
>> * [[Billy]] <tagged> [[Jane]](mother) [[John]](father)
>>
>> There could even fancy stuff like custom css, e.g. color coding for a
>> given semantic qualifier, e.g. male blue and femal pink, as we all know. ^_^
>>
>> Cheers, Tobias.
>>
>>
>>
>> On Tuesday, 20 August 2013 03:55:59 UTC+2, Tobias Beer wrote:
>>>
>>> Hi Jeremy,
>>>
>>> > Finally, I wonder if there is any work under-way on tag semantics - so
>>> that creating a tag of 'Fred Bloggs' can have semantics of 'Work Colleague'
>>> associated with it when tagging say 'Jane Right'. So it is creating
>>> n-triples (sort of) similar to N3 http://en.wikipedia.org/**
>>> wiki/Notation3 <http://en.wikipedia.org/wiki/Notation3> ?
>>>
>>> This is an idea I am sure I have been trying to communicate a while
>>> back, too.
>>>
>>> Semantically it is quite relevant to be a able to qualify a tag (not
>>> just in terms of polymorphism). It's a bit like a "compound tag", one that
>>> is actually two or more, yet somehow TW would know that the parts are
>>> semantic entities by themselves, too.
>>>
>>> A bit in the direction of what NameSpacePlugin does, I guess, only just
>>> in terms of tagging, rather than tiddler titles.
>>> http://namespace.tiddlyspace.**com <http://namespace.tiddlyspace.com/>
>>>
>>> For example, John could be the son of Jack. So instead of merely
>>> tagging John with [[Jack]], it would semantically be more meaningful to
>>> have a qualifier that allows to specify this tagging relation as...
>>>
>>> John <tagged> [[Jack]](is parent)
>>>
>>> ...and then later be able to leverage a qualifier like this further down
>>> the road. Ideally, [[is parent]] would as well, optionally, be a tiddler
>>> explaining the qualifier and how to use it.
>>>
>>> A tag could perhaps have multiple qualifiers, e.g.
>>>
>>> [[tag]](qualifier1|qualifier2)
>>>
>>> Qualifiers couls be semantic relations in the form of...
>>>
>>> * has value
>>> * is assiged to
>>> * is child of
>>> * is dependency for
>>> * is created by
>>> * is initiated by
>>> * is located at
>>> * is owned by
>>> * is part of
>>> * etc...
>>>
>>> It could even make sense to standardise the most vital of these semantic
>>> qualifiers in the core to have people adopt consistent use cases... makes
>>> communication a whole lot easier.
>>>
>>> Cheers, Tobias.
>>>
>>
>
>
> --
> Jeremy Ruston
> mailto:[email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.
