Help talk:Annotation
From semanticweb.org
Contents |
[edit] Scratchpad
I found the subsection "annotation of virtual articles" below in the article. The information given there is wrong, since you cannot annotate subsections at all. Also, we do not recommend to use sub-articles in favour of normal articles. On Wikipedia, using subarticles is deprecated in most cases too. The problem that was addressed in the removed section has many different solutions and would need more diverse discussion. In general, SMW cannot capture everything and it might be wise not to use overly artificial workarounds to achieve unsupported statements. --Markus Krötzsch 20:03, 15 July 2006 (CEST)
- With that in mind we should talk about within the mailinglist. — MovGP0 20:16, 15 July 2006 (CEST)
- I think we did: semantic annotation for subsections was discussed there. I think it is a good idea, and I am looking forward to implementing it once. But it is not available in the current version and thus should not be part of the software documentation yet ;-) --Markus Krötzsch 20:21, 15 July 2006 (CEST)
- In SMW 0.6 you can create a relation targeting a subsection, but SMW only stores the article name as the object_title in the smw_relations table, it doesn't store the fragment pointing to the subsection. And making a subsection like Casablanca#Scene_7 the subject of a relation seems completely impossible. FYI, you can easily enable subpages in the main namespace, see meta:Subpages#Administration. -- Skierpage 09:12, 11 March 2007 (CET)
[edit] Annotation of virtual Articles
Sometimes you might want to make a statement about a article that doens't exist and you don't want to create an Article. In Example you want to make a Statement about Temperaturedifference, but there is only the Article Temperature. In that case you can create either a new Header or a Subarticle.
In the first Case you edit the Article Temperature and write a new Paragraph:
== Temperaturedifference == A Temperaturedifference is the Difference between the Temperature from two Points...
Then you can refer to this using something like
[[is a::Temperature#Temperaturedifference]]
In the second Case you create a new Article with the Name Temperature/Temperaturedifference. This will get handeled as Subarticle from Temperature. In this Article you can make any semantic statement you want to do. Then you can refer to this using something like
[[is a::Temperature/Temperaturedifference]]
Warning: Beware when you are using a technique like this. It's not good when creating a Subarticle when there is already a common article about. This would lead to double articles.
[edit] External Annotations
be able to create a relation P R Q from outside P. This is useful, for example for mass creation of an inverted relation Ittayd 07:14, 3 January 2007 (CET)
- looking at the code, it is hard to do since then there is no single point where a relation is created, so hard to track updates etc. So, maybe add a $source to the relation triplet Ittayd 07:14, 3 January 2007 (CET)
[edit] Using a query to produce wikitext for annotations
- I moved that complex section to Help:Inline_queries#Using_a_query_to_produce_wikitext_for_annotations -- Skierpage 02:52, 30 September 2007 (CEST)
Holy crap. This page is very nicely written and understandable... until I get to the section Using a query to produce wikitext for annotations. Yikes! Any chance this could be cleaned up a bit? -Matt (71.57.32.65 03:31, 10 March 2007 (CET))
- For interpreting the query, note that the part between quotes is just a text, used for the separator.--Patrick 16:45, 10 March 2007 (CET)
- I think maybe the reason that section looks ugly is because it is actually an ugly hack, like using a UNIX pipeline 300 characters long (with half a dozen uses of
xargs), or using SQL to compose SQL statements. I do it all the time; hell, but it's never really the "right" solution, and certainly not something I'd put in a user guide! - I'm only passing through, so I may have got this all wrong, but doesn't using a scratch-pad to do a query like this that will work for now but be broken tomorrow really defeat the object of having all this semantic stuff? I mean, OK, the query's only possible because the semantic data's there, but since it will still be there tomorrow, why should I have to re-run the query manually?
- I guess what I'm getting at is that the semantic wiki should simply "understand" the concept of inverse relations, so that the list of location-of values for California would automatically and without ambiguity be the list of pages with located-in=California.
- Obviously, this would mean that the same relation could end up defined from either direction, and there'd have to be some editorial decisions about how to manage such things in practice (e.g. in this case, you would have a guideline discouraging the direct use of location-of in favour of having located-in the other side). But that would seem to make a lot more sense than leaving all the effort to the users to keep everything in sync. - IMSoP 03:28, 8 July 2007 (CEST)
- I think maybe the reason that section looks ugly is because it is actually an ugly hack, like using a UNIX pipeline 300 characters long (with half a dozen uses of
- Yes, the semantic wiki "understanding" the concept of inverse relations would be useful. The current section is about a workaround while that improvement has not yet been made--Patrick 09:40, 12 July 2007 (CEST).
[edit] How would I assign a particular type to a parameter in a template?
- Comment on what follows: Please create a User:yourname page here on ontoworld.org and move all this long-winded stuff to it. And the semediawiki-user mailing list is better for tech support than a discussion page. And if you can, please refer to pages on ontoworld.org that show the problems you're experiencing. You can create your own pages on ontoworld.org, just put "test" in the name and add [[Category:Testpage]]. And create the SIMPLEST possible test case, not a five-way test.-- Skierpage 00:43, 8 June 2007 (CEST)
I'm tinkering around with templates, parameter, and Semantic MediaWiki, but somehow it seems as if I'm missing something rather important, ie. how to assign a particulare type to a given parameter in a template.
My template definition looks like:
== Basic Types ==
Integer Value: [[IntVal:={{{IntVal|}}}]]<br />
Floating Value: [[FloatVal:={{{FloatVal|}}}]]<br />
String Value: [[StrVal:={{{StrVal|}}}]]<br />
== Type email ==
eMail: <[[email:={{{eMail|}}}|[mailto:{{{eMail|}}} {{{eMail|}}}]]]>
[[Category:Sandbox]]
<noinclude>
Usage of this template:
<pre>
{{Simple Semantic Template
|IntVal={{{IntVal}}}
|FloatVal={{{FloatVal}}}
|StrVal={{{StrVal}}}
|eMail={{{eMail}}}
}}
[[Category:Template]]
</noinclude>
And now I would like to assign appropriate type to those parameters. 85.125.230.177 21:48, 7 June 2007 (CEST)
- Read the Annotation section of this help page. As it says, you need to create a page for Attribute:IntVal specifying [[has type::Type:integer]]. Your template looks more or less OK, but: a) I'm not sure why you suppress display of the IntVal itself with the '|' symbol. b) in your noinclude usage, give actual values like 42, 3.1415, Abcd. c) I think your email display is needlessly complicated — if you say your Attribute:eMail has [[has type::Type:email]], it should turn into a mailto link. Template:Test is (currently( a really simple template. -- Skierpage 22:34, 7 June 2007 (CEST)
What do you mean by "surpressing IntVal"? Okay, I now create a page for each of my parameters (attributes) on their own and did as you said. When I'm now using my template like
== Providing Parameter ==
{{Simple Semantic Template|
|IntVal=12345
|FloatVal=3.1415693
|StrVal=Sunny Side
|EnumVal=Mr.
|BoolVal=True
|eMail=Some.Body@Somewhere.net
}}
== Omitting Parameter ==
{{Simple Semantic Template}}
[[Category:Sandbox]]
- the output looks like
Simple Semantic Template Contents [hide] 1 Providing Parameter 2 Basic Types 3 Type email 4 Omitting Parameter 5 Basic Types 6 Type email [edit] Providing Parameter [edit] Basic Types Integer Value: 12345 Floating Value: 3.1415693 String Value: Sunny Side Enumeration Value: Mr. Boolean Value: True [edit] Type email eMail: Some.Body@Somewhere.net [edit] Omitting Parameter [edit] Basic Types Integer Value: Floating Value: String Value: Enumeration Value: Boolean Value: [edit] Type email eMail: Facts about Simple Semantic TemplateRDF feed BoolVal [Oops! No type defined for attribute] EMail [Oops! No type defined for attribute] EnumVal [Oops! No type defined for attribute] FloatVal [Oops! No type defined for attribute] IntVal [Oops! No type defined for attribute] StrVal [Oops! No type defined for attribute] Category: Sandbox
What do does "Oops" messages indicate? That I maybe have done something wrong with the attribute definition?
My "IntVal" (Attribute:IntVal) looks like:
The type of this attribute is [[has type::Type:Integer]]. <ask /> [[Category:Attribute Definition]]
and my "Type:Integer" (I had to create this page first) -- 85.125.230.177 22:47, 7 June 2007 (CEST)
- (You don't have to create a page for a built-in type, so your Type:Integer page is just informative.) 1. After you created Attribute:IntVal it should have a factbox displaying the Special Property has type Type:Integer without any errors; like the factbox in ontoworld's Attribute:Population. 2. Don't run before you can walk, just put [[IntVal:=23]] on a test page and make sure that IntVal 23 shows up in that page's factbox without any errors. The [Oops! No type defined for attribute] error means just what it says. 3. If steps 1 and 2 work, edit or purge your page with the template and it should work. Are you doing this in an English-language wiki? -- Skierpage 00:43, 8 June 2007 (CEST)
[edit] Getting the most out of the Boolean type
The SemanticForms Extension to SMW permits the use of forms with check boxes to input values to attributes of type Boolean. The templates on which a Semantic Form is based can contain parser functions that, based on the checkbox, assign pre-defined groups of categories or relations.
When using attributes of type Boolean, the output can be set up not only to show true-false, yes-no, 1-0, but also other words or phrases, such as male-female, or even 'located in Europe' or 'not located in Europe'.
For example:
<ask format=table> [[male:=+]] [[male:=*male,female]] </ask>
or:
<ask format=table> [[located in Europe?=+]] [[located in Europe?=*located in Europe,not located in Europe]] </ask>
In these examples, the attributes 'male' and 'located in Europe?' are set to type Boolean.
- Note: the Boolean type must be 'turned on' by uncommenting line 372 in SMW 0.7 distribution, includes/SMW_Datatype.php
- --Joschroy 15:25, 22 July 2007 (CEST)
[edit] suggested edit
The text that reads;
- The reason we didn't have to specify a datatype for the "capital of" property above is that the default datatype is Type:Page, which displays as a link. If you change the datatype of a property later on it does not affect the annotations of existing articles until they are modified and saved again. Even though Type:Page is the default, you should explicitly specify a datatype to every property, just to prevent confusion or later redefinition with an unintended type.
Should read (I suggest);
- The reason we didn't have to specify a datatype for the "capital of" property above is that the default datatype is Type:Page, which displays as a link. (Note that, for technical reasons, if you change the datatype of a property later on it does not affect the annotations of existing articles until they are modified and saved again). Even though Type:Page is the default, you should explicitly specify a datatype to every property, just to prevent confusion or later redefinition with an unintended type.
--Dmb 17:07, 29 September 2007 (CEST)
- Sounds good, I made more or less this change. -- Skierpage 02:56, 30 September 2007 (CEST)
