Matches in LOV for { ?s <http://www.w3.org/2000/01/rdf-schema#comment> ?o. }
- SubQuery comment "A nested SELECT query inside of an element list. The query is stored in sp:query.".
- SystemClass comment "An \"artificial\" root class that groups all SP classes. This makes them look much less overwhelming in UI tools. Typical end users don't need to see those classes anyway.".
- Triple comment "A base class for TriplePattern and TripleTemplate. This basically specifies that subject, predicate and object must be present.".
- TriplePath comment "Similar to a TriplePattern, but with a path expression as its predicate. For example, this can be used to express transitive sub-class relationships (?subClass rdfs:subClassOf* ?superClass).".
- Tuple comment "Abstract base class for things that have subject and object.".
- Update comment "Abstract base class to group the various SPARQL UPDATE commands.".
- Values comment "A VALUES element. sp:varNames points to an rdf:List of strings for the variables, sp:values to an rdf:List of rdf:Lists with nodes for each variable, in the order defined by the variables list.".
- Variable comment "A variable mentioned in a Triple or expression. Variables are often blank nodes with the variable name stored in ts:name. Variables can also be supplied with a URI in which case the system will attempt to reuse the same variable instance across multiple query definitions.".
- arg comment "Abstract superproperty for the enumerated arg1, arg2 etc.".
- systemProperty comment "An abstract base proprerty that groups together the SP system properties. Users typically don't need to see them anyway.".
- spin comment "An RDF Schema that can be used to attach constraints and rules to RDFS classes, and to encapsulate reusable SPARQL queries into functions and templates.".
- AskTemplate comment "A SPIN template that wraps an ASK query.".
- Column comment "Provides metadata about a column in the result set of a (SPARQL) query, for example of the body queries of SPIN templates. Columns can define human-readable labels that serve as column titles, using rdfs:label.".
- ConstraintViolation comment "An object that can be created by spin:constraints to provide information about a constraint violation.".
- ConstraintViolationLevel comment "The type of the supported levels of constraint violations, including spin:Error and spin:Warning.".
- Function comment "Metaclass for functions that can be used in SPARQL expressions (e.g. FILTER or BIND). The function themselves are classes that are instances of this metaclass. Function calls are instances of the function classes, with property values for the arguments.".
- Functions comment "An abstract base class for all defined functions. This class mainly serves as a shared root so that the various instances of the Function metaclass are grouped together.".
- MagicProperties comment "An abstract superclass that can be used to group all spin:MagicProperty instances under a single parent class.".
- Module comment "An abstract building block of a SPARQL system. A Module can take Arguments as input and applies them on an input RDF Graph. The Arguments should be declared as spin:constraints.".
- Modules comment "An \"artificial\" parent class for all Functions and Templates.".
- Rule comment "Groups together the kinds of SPARQL commands that can appear as SPIN rules and constructors: CONSTRUCT, DELETE WHERE and DELETE/INSERT. This class is never to be instantiated directly.".
- RuleProperty comment "The metaclass of spin:rule and its subproperties. spin:RuleProperties can have additional metadata attached to them.".
- SelectTemplate comment "A SPIN template that wraps a SELECT query.".
- TableDataProvider comment "An abstraction of objects that can produce tabular data. This serves as a base class of spin:SelectTemplate, because SELECT queries can produce tables with columns for each result variable. However, other types of TableDataProviders are conceivable by other frameworks, and this class may prove as a useful shared foundation.\n\nTableDataProviders can link to definitions of columns via spin:column, and these definitions can inform rendering engines.".
- Template comment "The metaclass of SPIN templates. Templates are classes that are instances of this class. A template represents a reusable SPARQL query or update request that can be parameterized with arguments. Templates can be instantiated in places where normally a SPARQL query or update request is used, in particular as spin:rules and spin:constraints.".
- Templates comment "Suggested abstract base class for all Templates.".
- UpdateTemplate comment "A SPIN template that has an UPDATE command as its body.".
- body comment "The body of a Function or Template. This points to a Query instance. For Functions, this is limited to either ASK or SELECT type queries. If the body is the ASK function then the return value is xsd:boolean. Otherwise, the SELECT query must have a single return variable. The first binding of this SELECT query will be returned as result of the function call.".
- command comment "Can be used to link a resource with a SPARQL query or update request (sp:Command).".
- query comment "Can be used to point from any resource to a Query.".
- systemProperty comment "An \"abstract\" base property that groups together those system properties that the user will hardly ever need to see in property trees. This property may be dropped in future versions of this ontology - right now it's mainly here for convenience.".
- violationRoot comment "The root resource of the violation (often ?this in the constraint body).".
- ns comment " Please report any error to myriam.leggieri_at_deri.org".
- ns comment "This ontology describes sensors, observations, and related concepts. It also describes events and their correlations. The final aim is to support a better description of sensor context.".
- ns comment "This ontology is developed by DERI ( http://www.deri.ie ) for the SPITFIRE project ( http://spitfire-project.eu ) . It is based on the alignment among the W3C Semantic Sensor Networks Incubator Group (SSN-XG) ontology, the Dolce-DnS Ultralite ontology and the Event Model F ontology. ".
- DataLink comment "Link Association.".
- OV comment "Observation Value.".
- Quantity comment "Observed property (Quantity).".
- TSMap comment "Versions of a same observed Property (Quantity) which vary across time and space, as captured by the sensor's observed values.".
- AdministrativeStaff comment "This class represents administrative staff.".
- AgentSequence comment "This is an adhoc solution for creating and ordered group of Agents, e.g. an authorlist.".
- Article comment "An article from a journal or magazine.".
- Book comment "A book with an explicit publisher. NOTES: - Either <link>authors</link> or <link>editedBy</link> must be given - Either <link>volume</link> or <link>number</link> may be given.".
- Booklet comment "A work that is printed and bound, but without a named publisher or sponsoring institution.".
- City comment "This class defines geopraphical bodies that are cities.".
- Cluster comment "A Cluster is a kind of group which focuses on a research area and typically is part of a research institute or university.".
- Company comment "This class represents all kinds of companies. Currently only publishers and software developers are modelled.".
- Conference comment "This class represents all kinds of conferences in the academic domain.".
- Continent comment "This class defines geopraphical bodies that are continents.".
- Country comment "This class defines geopraphical bodies that are countries.".
- Deliverable comment "A document which is produced as part of a project. Deliverables are not formally published. NOTE: This concept was not derived from any of the BibTex types, but considered useful anyway.".
- Event comment "This class represents events relevant for the area of teaching, research, business, i.e. conferences, presentations, tutorials, workshops and lectures.".
- Inbook comment "A part of a Book, which may be a chapter (or section or whatever) and/or a range of pages. Because the BibTex types inCollection and inBook are very similiar, we decided to keep the ontology as simple as possible and merge them both into <link>Inbook</link>.".
- IndividualPublication comment "The instances of this class comprise all publications which have a specific publication date. If a publication P is contained within an <link>PublicationContainer</link>, and this container has a publication date, than P is not an <link>IndividualPublication</link>. Example: an <link>Inbook</link> publication is not an <link>IndividualPublication</link>, because its publication date can be inferred from the <link>Book</link> which contains it.".
- Inproceedings comment "An article in a conference proceedings (i.e. Proceedings).".
- Journal comment "A scientific journal or magazine. The instances of this class are not individual issues or voulumes of a journal, but the journal as such.".
- Lecture comment "This class represents lectures with an educational purpose, e.g within a university.".
- Location comment "This class is the superclass for all classes defining geographical locations. The approach for this subontology is to have a hierarchy of location classes, such that instances of the classes further down in the hierarchy can be contained in instances of the classes higher up in the hierarchy. On each level, there exist two sister classes: class L defines a certain type of location, while class SubL defines locations which can be contained in instances of L. SubL then defines a property inL, to express which instance of L an instance of SubL is contained in. E.g. for a class Continent, there exists a class SubContinent. All children of SubContinent (either direct or transitive) define locations that can be contained in a continent, such as countries, regions, cities, etc. By virtue of inheritance, all these location classes then have a property inContinent, to express that they are contained in some continent. In a simpler, flat structure, inContinent would have to be defined explicitly for all kinds of locations that can be contained in a continent.\nThe intepretation of the inL predicates should be as follows: if, for a particular instance K, inL has a value, this value is valid. If inL has no value, the value of inL in the next location K is contained in valid, and so forth. E.g. an instance \"Hawaii\" has the value \"Oceania\" defined for <link>inContinent</link> and \"USA\" for <link>inCountry</link>. \"Delaware\" has no value for inContinent. \"USA\" has the value \"North America\" for <link>inContinent</link>. The interpretation would be that \"Hawaii\" is located in \"Oceania\", while \"Delaware\" is located in \"North America\".\nWe are aware of the fact that this approach is idealized and can therefore conflict with reality in some situations. E.g., the exact borders of continents are not always defined (there are contradicting opinions on where exactly Europe begins or ends). Countries could be contained in more than one continent (Turkey belongs to both Europe and Asia). However, we think that these situations are marginal and have little or no impact on the intended use of this ontology.\nWe think that this recursive modelling of locations is at the same time simple and powerful enough to capture all necessary aspects of the concept of location for a domain such as an SWPortal. While the SubL classes might appear to be somewhat artificial, they are actually not. They are just an abstraction for geographical entities that are (under normal circumstances) smaller than entities of type L. As such, they are no more abstract than, say, the concept of an agent.".
- MasterThesis comment "A thesis written to receive a Master degree.".
- Misc comment "Some sort of publication which doesn't fit into any of the other concepts.".
- NewsItem comment "This class is the super-class for any kind of news item.".
- Organization comment "This class represents an organization with a formal legal status. We introduce this class as a subclass of <link>foaf:Organization</link> and <link>foaf:Group</link>, because we consider an organization as a kind of group.".
- PhDThesis comment "A thesis written to receive a PhD degree.".
- PostalAddress comment "Instances of this class represent exact postal addresses. Note that either <link>postbox</link> of <link>streetAddress</link> should be given.".
- Presentation comment "This class represents all kinds of presentations.".
- Proceedings comment "The proceedings of a conference.".
- Publication comment "Publications are both individual documents and collections of documents such as series, journals, etc.".
- PublicationContainer comment "This class comprises all kinds of publications which contain other publications, such as journal, proceedings, series, etc. An instance of PublicationContainer has an editor.".
- PublishingCompany comment "This class models companies that publish documents.".
- Region comment "This class defines geopraphical bodies that are regions, with the intended meaning \"sub-division of a country\".".
- ResearchInstitute comment "This class represents research institutes. These organizations have special research areas.".
- Researcher comment "This class represents all kinds of persons who are researchers. Each has a research area.".
- Series comment "A series or set of books.".
- SubCity comment "This class defines geopraphical bodies that can be contained in cities.".
- SubContinent comment "This class defines geopraphical bodies that can be contained in continents.".
- SubCountry comment "This class defines geopraphical bodies that can be contained in countries.".
- SubRegion comment "This class defines geopraphical bodies that can be contained in regions.".
- Techreport comment "A report published by a school or other organization, usually numbered within a series (<link>Series</link>). This concept has been merged from BibTex's techreport and manual types, since both are described very similiar.".
- TemporaryGroup comment "As <link>foaf:Project</link>, <link>Initiative</link> and <link>WorkingGroup</link> differ from Cluster in having a specific duration, we comprise these there temporal groups in this class which represents all kinds of temporary groups.".
- Thesis comment "Any kind of thesis produced to receive some sort of university degree.".
- Tool comment "This class represents any kind of software tool. At the moment, this class is clearly underspecified.".
- Topic comment "All research topics inherit from this concept. This should serve as a plugin point for the research topic ontology.".
- Tutorial comment "This class represents all kinds of tutorials.".
- University comment "This class represents universities. We decided to introduce two different classes to distinguish between universities and independent research institutes. The main difference is actually the different kinds of independence. In contrast to a university, a research institute is independent from the rigorous bureaucracy of the mainly state-run universities. On the other hand, a university is independent from the economy and the financial support of companies. Thus, the kind of research an independent research institute practises is generally more application-oriented.".
- Unpublished comment "A document which does have an author and title, but hasn't been formally published.".
- Volume comment "An individual volume of some <link>Journal</link>.".
- WorkPackage comment "A work package is a subdivision of a project. It stands in a part-of relationship to <link>foaf:Project</link>.".
- Workshop comment "This class represents all kinds of workshops".
- belongsToProject comment "Defines what project a workpackage belongs to.".
- containedInBook comment "The <link>Book</link> in which an Inbook is contained.".
- containedInJournal comment "The journal or magazine which contains this article.".
- containedInProceedings comment "The proceedings some paper or similar is contained in.".
- containsArticles comment "The articles or papers which a journal containes.".
- containsChapters comment "The chapters or similar which a book contains.".
- containsPapers comment "The papers or similar which a proceedings contains.".
- deliverables comment "The deliverables for this project. The inverse is <link>forProject</link>.".
- drivenBy comment "The <link>foaf:Agent</link> this project is driven by. This is inverse to <link>foaf:currentProject</link>. NOTE: How do we deal with the relation between drivenBy and <link>foaf:pastProject</link>?".
- forProject comment "The project for which this deliverable is produced. The inverse is <link>deliverables</link>.".
- givesPresentations comment "This property relates an agent to the presentations it gives. The inverse property is <link>presenter</link>.".
- givesTutorials comment "This property relates an agent to the tutorials it gives. The inverse property is <link>tutoredBy</link>.".