Development/Tutorials/Metadata/Nepomuk/Resources - Revision history

AnneW at 10:47, 15 July 2012

2012-07-15T10:47:10Z

Neverendingo: Text replace - "" to ""

2011-06-29T20:53:23Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:45:03Z
Text replace - "<code>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 20:45, 29 June 2011
			
Line 32:
Line 32:
  To use Nepomuk in your application simply make cmake search for it using the Nepomuk macro that comes with kdelibs:   To use Nepomuk in your application simply make cmake search for it using the Nepomuk macro that comes with kdelibs:
    
− <code> + <syntaxhighlight lang="text">
  find_package(Nepomuk REQUIRED)   find_package(Nepomuk REQUIRED)
  include_directories(${NEPOMUK_INCLUDES})   include_directories(${NEPOMUK_INCLUDES})



Neverendingo: Text replace - "" to ""

2011-06-29T20:29:41Z
Text replace - "<code cppqt>" to "<syntaxhighlight lang="cpp-qt">"

				
				
				
				
			
			← Older revision
			Revision as of 20:29, 29 June 2011
			
Line 49:
Line 49:
  Setting and getting metadata is done via two methods:   Setting and getting metadata is done via two methods:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  void Nepomuk::Resource::setProperty( const QUrl& key, const Nepomuk::Variant& value );   void Nepomuk::Resource::setProperty( const QUrl& key, const Nepomuk::Variant& value );
  Variant Nepomuk::Resource::property( const QUrl& key );   Variant Nepomuk::Resource::property( const QUrl& key );
Line 60:
Line 60:
  [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] provides static instances of the most often used URIs as we see below (Soprano also comes with a code generation tool which can create these kind of namespaces from ontology files).     [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] provides static instances of the most often used URIs as we see below (Soprano also comes with a code generation tool which can create these kind of namespaces from ontology files).  
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  Nepomuk::Resource tag( "TestTag", Soprano::Vocabulary::NAO::Tag() );   Nepomuk::Resource tag( "TestTag", Soprano::Vocabulary::NAO::Tag() );
  tag.setProperty( Soprano::Vocabulary::RDFS::label(), QString("Important stuff") );   tag.setProperty( Soprano::Vocabulary::RDFS::label(), QString("Important stuff") );
Line 77:
Line 77:
  The second way of using Nepomuk is to rely on its class generator which, as mentioned in the introduction, generates C++ classes from ontologies. Suddenly the above code looks much simpler:   The second way of using Nepomuk is to rely on its class generator which, as mentioned in the introduction, generates C++ classes from ontologies. Suddenly the above code looks much simpler:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  Nepomuk::Tag tag( "TestTag" );   Nepomuk::Tag tag( "TestTag" );
  tag.setLabel( "Important Stuff" );   tag.setLabel( "Important Stuff" );
Line 99:
Line 99:
  In Nepomuk each resource has only one instance at all times. Thus, the following code will actually result in only one new tag with two labels since the second one is simply a local copy:   In Nepomuk each resource has only one instance at all times. Thus, the following code will actually result in only one new tag with two labels since the second one is simply a local copy:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  Nepomuk::Tag tagA( "test" );   Nepomuk::Tag tagA( "test" );
  Nepomuk::Tag tagB( "test" );   Nepomuk::Tag tagB( "test" );



Rainer: Undo revision 56772 by Rainer (Talk)
2011-01-28T10:02:52Z
Undo revision 56772 by Rainer (Talk)

				
				
				
				
			
			← Older revision
			Revision as of 10:02, 28 January 2011
			
Line 81:
Line 81:
  tag.setLabel( "Important Stuff" );   tag.setLabel( "Important Stuff" );
    
− Nepomuk::Resource aFile( "/tmp/testfile.txt" ); + Nepomuk::File aFile( "/tmp/testfile.txt" );
  aFile.addTag( tag );   aFile.addTag( tag );
  </code>   </code>



Rainer: Nepomuk::File does not exist. Changed to Nepomuk::Resource
2011-01-27T17:33:57Z
Nepomuk::File does not exist. Changed to Nepomuk::Resource

				
				
				
				
			
			← Older revision
			Revision as of 17:33, 27 January 2011
			
Line 81:
Line 81:
  tag.setLabel( "Important Stuff" );   tag.setLabel( "Important Stuff" );
    
− Nepomuk::File aFile( "/tmp/testfile.txt" ); + Nepomuk::Resource aFile( "/tmp/testfile.txt" );
  aFile.addTag( tag );   aFile.addTag( tag );
  </code>   </code>



Tankaa: misspelling fixed
2010-01-13T23:27:20Z
misspelling fixed

				
				
				
				
			
			← Older revision
			Revision as of 23:27, 13 January 2010
			
Line 111:
Line 111:
  ===Two ways of accessing existing data===   ===Two ways of accessing existing data===
    
− The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag. + The constructor of Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.



Trueg at 07:47, 23 August 2009
2009-08-23T07:47:54Z


				
				
				
				
			
			← Older revision
			Revision as of 07:47, 23 August 2009
			
Line 4:
Line 4:
  series=[[../|Nepomuk]]|   series=[[../|Nepomuk]]|
  name=Resource Metadata Handling with Nepomuk|   name=Resource Metadata Handling with Nepomuk|
− pre=[[../RDFIntroduction|Introduction to RDF and Ontologies]]| + pre=[[../RDFIntroduction|Introduction to RDF and Ontologies]],[[../DataLayout|Data Layout in Nepomuk]]|
  next=[[../ResourceGenerator|Using the Nepomuk Resource Generator]]|   next=[[../ResourceGenerator|Using the Nepomuk Resource Generator]]|
  reading=[[../Quickstart|Nepomuk Quickstart for the impatient]], [[../NepomukServer|The Nepomuk Server]], [http://api.kde.org/4.0-api/kdelibs-apidocs/nepomuk/html/index.html Nepomuk API Documentation]|   reading=[[../Quickstart|Nepomuk Quickstart for the impatient]], [[../NepomukServer|The Nepomuk Server]], [http://api.kde.org/4.0-api/kdelibs-apidocs/nepomuk/html/index.html Nepomuk API Documentation]|



Trueg at 09:10, 21 August 2009
2009-08-21T09:10:20Z


				
				
				
				
			
			← Older revision
			Revision as of 09:10, 21 August 2009
			
Line 112:
Line 112:
    
  The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.   The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.
−  
−  
− ==Ontologies in Nepomuk==  
−  
− Nepomuk is a semantic desktop project which is influenced by semantic web technologies such as RDF.  
−  
− A direct result from this is that in Nepomuk all metadata is stored as RDF triples. Normally you as an application developer should not care about that too much. Unless you want to create your own resource classes, i.e. types and properties or fields.  
−  
− Each resource class and property is defined in an ontology. Let us look at an example we know from before: tagging. The following code is an excerpt from the Nepomuk Annotation Ontology which defines basic annotation properties such as tagging:  
−  
− <code xml>  
− <rdf:Description rdf:about="&nao;Tag">  
−         <rdf:type rdf:resource="&rdfs;Class"/>  
− </rdf:Description>  
− <rdf:Property rdf:about="&nao;annotation">  
−         <rdfs:domain rdf:resource="&rdfs;Resource"/>  
−         <rdfs:range rdf:resource="&rdfs;Resource"/>  
− </rdf:Property>  
− <rdf:Property rdf:about="&nao;hasTag" rdfs:label="hasTag">  
−         <rdfs:domain rdf:resource="&rdfs;Resource"/>  
−         <rdfs:range rdf:resource="&nao;Tag"/>  
−         <rdfs:subPropertyOf rdf:resource="&nao;annotation"/>  
− </rdf:Property>  
− </code>  
−  
− This defines the Tag class and the hasTag property which is a sub-property of annotation. The property has a domain and a range which defines the classes that can be used with this property.  
−  
− This is the information used by the Nepomuk class generator to create the convenient C++ classes we saw before.  
−  
− At the moment the basic metadata ontologies are created in cooperation with the Strigi developers and some other open-source projects. These ontologies will include things like id3 tags and exif data and much more.  



Trueg: /* The manual way of doing things */
2009-06-08T08:03:05Z
‎The manual way of doing things

				
				
				
				
			
			← Older revision
			Revision as of 08:03, 8 June 2009
			
Line 51:
Line 51:
  <code cppqt>   <code cppqt>
  void Nepomuk::Resource::setProperty( const QUrl& key, const Nepomuk::Variant& value );   void Nepomuk::Resource::setProperty( const QUrl& key, const Nepomuk::Variant& value );
− Variant Nepomuk::Resource::getProperty( const QUrl& key ); + Variant Nepomuk::Resource::property( const QUrl& key );
  </code>   </code>

← Older revision		Revision as of 10:47, 15 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Development/Tutorials/Metadata/Nepomuk/Resources}}~~	+

	{{TutorialBrowser\|		{{TutorialBrowser\|

@@ Line 36: / Line 36: @@
 include_directories(${NEPOMUK_INCLUDES})
 target_link_libraries( [...] ${NEPOMUK_LIBRARIES})
-</code>
+</syntaxhighlight>
@@ Line 52: / Line 52: @@
 void Nepomuk::Resource::setProperty( const QUrl& key, const Nepomuk::Variant& value );
 Variant Nepomuk::Resource::property( const QUrl& key );
-</code>
+</syntaxhighlight>
 {{note|Why don't we use {{qt|QVariant}} instead of Nepomuk::Variant? Actually Nepomuk::Variant has been derived from {{qt|QVariant}} and extended with some nice list-handling features that will come in handy later on.}}
@@ Line 66: / Line 66: @@
 Nepomuk::Resource aFile( "/tmp/testfile.txt", Soprano::Vocabulary::Xesam::File() );
 aFile.setProperty( Soprano::Vocabulary::NAO::hasTag(), tag );
-</code>
+</syntaxhighlight>
 Now what does this do then?
@@ Line 83: / Line 83: @@
 Nepomuk::File aFile( "/tmp/testfile.txt" );
 aFile.addTag( tag );
-</code>
+</syntaxhighlight>
 Isn't this much more readable and much easier to remember and debug? The nice thing is that both Tag and File are subclasses of Nepomuk::Resource and internally methods like addLabel are only based on setProperty and some magic use of Nepomuk::Variant.
@@ Line 105: / Line 105: @@
 tagA.setLabel( "testtagA" );
 tagB.setLabel( "testtagB" );
-</code>
+</syntaxhighlight>
 The actual data is cached and synced back regularly by the framework.

← Older revision		Revision as of 23:27, 13 January 2010
Line 111:		Line 111:
	===Two ways of accessing existing data===		===Two ways of accessing existing data===

−	The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.	+	The constructor of Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.

← Older revision		Revision as of 09:10, 21 August 2009
Line 112:		Line 112:

	The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.		The constructor or Nepomuk::Resource (and with it the constructors of all subclasses) allows to use an identifier or an actual resource URI for creation. The framework will then look if the passed string already exists as an URI or an identifier and load the data appropriately. If neither identifier or URi exist the passed string is used as a new identifier and a new random resource URI is generated. To understand what this means it is important to know that each resource in Nepomuk is uniquely identified by its URI (which is also used for storage in RDF) but can also have an arbitrary number of alternative identifiers which are more convenient for certain applications to find a resource. A typical example is the path of a file or the name of a tag.
−
−
−	~~==Ontologies in Nepomuk==~~
−
−	~~Nepomuk is a semantic desktop project which is influenced by semantic web technologies such as RDF.~~
−
−	A direct result from this is that in Nepomuk all metadata is stored as RDF triples. Normally you as an application developer should not care about that too much. Unless you want to create your own resource classes, i.e. types and properties or fields.
−
−	Each resource class and property is defined in an ontology. Let us look at an example we know from before: tagging. The following code is an excerpt from the Nepomuk Annotation Ontology which defines basic annotation properties such as tagging:
−
−	~~<code xml>~~
−	~~<rdf:Description rdf:about="&nao;Tag">~~
−	~~<rdf:type rdf:resource="&rdfs;Class"/>~~
−	~~</rdf:Description>~~
−	~~<rdf:Property rdf:about="&nao;annotation">~~
−	~~<rdfs:domain rdf:resource="&rdfs;Resource"/>~~
−	~~<rdfs:range rdf:resource="&rdfs;Resource"/>~~
−	~~</rdf:Property>~~
−	~~<rdf:Property rdf:about="&nao;hasTag" rdfs:label="hasTag">~~
−	~~<rdfs:domain rdf:resource="&rdfs;Resource"/>~~
−	~~<rdfs:range rdf:resource="&nao;Tag"/>~~
−	~~<rdfs:subPropertyOf rdf:resource="&nao;annotation"/>~~
−	~~</rdf:Property>~~
−	~~</code>~~
−
−	~~This defines the Tag class and the hasTag property which is a sub-property of annotation. The property has a domain and a range which defines the classes that can be used with this property.~~
−
−	~~This is the information used by the Nepomuk class generator to create the convenient C++ classes we saw before.~~
−
−	At the moment the basic metadata ontologies are created in cooperation with the Strigi developers and some other open-source projects. These ontologies will include things like id3 tags and exif data and much more.