Matches in LOV for { ?s <http://www.w3.org/2000/01/rdf-schema#comment> ?o. }
- sensorOf comment "Association between a sensor and its sensed object".
- sleepTime comment "The time between connection trials".
- svgFootprint comment "A property holding the svg footprint for the given building environment object".
- timeToOff comment "The time in seconds during which the object is turned on".
- op comment "A general purpose ontology for observable properties. The ontology supports description of both qualitative and quantitative properties. The allowed scale or units of measure may be specified. A property may be linked to substances-or-taxa and to features or realms, if they play a role in the definition. \n\nThis ontology was developed to enable publication of a vocabulary of water quality properties for the Bioregional Assessments and eReefs projects.\n\nThis ontology extends the QUDT schema. \n\nSome key classes and properties are linked to SKOS, so that instances of an observable-property vocabulary are implicitly also SKOS concepts, and may be accessed through general purpose vocabulary APIs based on SKOS. ".
- PropertyKind comment "Superclass of qudt:QuantityKind\nThis class accommodates all kinds of properties, including those (qualities) that are not described by quantities (numeric values). \nMay carry an objectOfInterest property, to point to the substance or taxon with which the property is associated - e.g. tree-height, organism-count, nitrogen-concentration".
- QualityKind comment "non-numeric PropertyKind".
- ScaledQuantityKind comment "Scaled quantity kind has one or more unit properties, which indicate valid units of measure for this quantity kind. \n\nIt is likely that this class is equivalent to qudt:QuantityKind, but has been declared independently for governance of the attached qudt:unit property".
- SubstanceOrTaxon comment "Class of stuff and things, individuals of which identify a class of stuff and things that make observed properties concrete.".
- applicableVocabulary comment "Set of terms or concepts from which the value must be drawn. \nThis may be implemented as a skos:ConceptScheme or skos:Collection\n\nCompare with QUDT2 'applicable unit'".
- constraint comment "Constraint that refines the definition of an abservable property definition. This may include concerns such as realm of application, substance or taxon involved, applicable units or vocabulary. ".
- featureOfInterest comment "In an observable property definition, the feature-of-interest constrains the feature realm that the property is associated with.".
- matrix comment "In an observable property definition, the matrix is a special case of a feature-of-interest that provides the context (container feeaure or medium) for an observable property.".
- objectOfInterest comment "In an observable property definition, the object-of-interest constrains the substance or taxon involved in a count, concentration, presence, or other simialr property. ".
- procedure comment "link to procedure or sensor system used in making observation or estimate of property value".
- Document comment "A single document that is part of an ep:EPrint record. It may be a machine generated version of another document, eg. a thumbnail, in which case this will be expressed with relations from the http://eprints.org/relation/ namespace. It will have one or more files associated. Some documents can have multilple files, such as an HTML page plus image files. Resolving a document URI will redirect you to the primary file of the document.".
- EPrint comment "A single record in an EPrints Repository. Generally this will be described as BIBO and Dublin Core, and may have a number of associated ep:Documents. Resolving a URI of class ep:EPrint will direct to the HTML summary page for the record, in an HTML browser, or to an RDF (XML or N3) document in an RDF client. The RDF document will contain all available RDF information about the record including all attached ep:Document records and their metadata and links from the document to the files via ep:hasFile. Not all files may be available without authentication. If the files themselves contain semantic information of interest these will need to be resolved separately. References to people, organisations, publications and locations may be given URIs of the form /id/<typeofthing>/ext-<somevalue> -- in this case the URI will be resolvable as RDF+XML or N3 and may yield additional records in the repository referencing the same thing, although this is usually based on the hashing of metadata strings and may not be complete or perfect. The ext- indicates that this concept is not something the repository actually stores information about, it is just referenced by one or more records. For example, the RDF for an EPrint about a paper given at a conference may reference that conference with a URI of the form /id/event/ext-a43de4454. That URI will be resolvable but the repository does not contain full information about that event, just information derived from EPrint record metadata. It is hoped that the community may develop systems to link such URIs to the more definitive URI for an event, person, location etc.".
- Repository comment "An EPrints Repository. This will have a number of EPrints records associated with it via the ep:hasEPrint predicate, and the records will generally be expressed as BIBO & Dublin Core, plus EPrints extensions to describe the attached documents and files. Resolving the URI of this class using a client which prefers RDF XML (or text/n3) will return an RDF document describing the repository using voID and Dublin Core, plus a ep:hasEPrint link to every current record in the public part of the repository. See ep:EPrint for more description about such records. EPrints generally supports a sitemap.xml file which describes a set of data-dump-locations. Resolving these is the fastest way to obtain every bit of RDF data from an EPrints repository.".
- E21_Person comment "Note for SAWS: this includes any human being, named or otherwise".
- E56_Language comment "Note for SAWS: This represents language in which a material is written - this is put in the TEI header. \n\nNB in the TEI header we should use standards for languages, e.g. the more detailed ISO standards at http://www.loc.gov/standards/iso639-2/ , so use “http://id.loc.gov/vocabulary/iso639-2/grc” for Ancient Greek rather than “Greek”".
- geometry comment "A vocabulary for describing geographical regions in RDF. $Id: geometry# 81 2012-02-05 11:06:49Z non88sense@gmail.com $".
- BoundingBox comment "Represents a bounding box composed by four line segments.".
- Geometry comment "Super-class grouping all geometrical representations (also ones in non-RDF formats, such as KML, GML, WKT...).".
- GeometryCollection comment "Super-class grouping all composite geometrical representations.".
- LineString comment "Represents a series of points connected by straight lines.".
- LinearRing comment "Represents a series of points connected by straight lines, which form a closed shape. Last point must be the same as the first point.".
- MultiLineString comment "Describes a geometric shape composed of several LineString resources.".
- MultiPoint comment "Describes a collection of Point resources, which define a resource's geometric representation.".
- MultiPolygon comment "Describes a geometric shape composed of several Polygon resources.".
- Polygon comment "A closed area defined by an exterior boundary, and optionally one or more interior boundaries.".
- boundary comment "Super-property that groups all properties defining a polygon's boundaries.".
- exterior comment "Defines a polygon's outer boundary.".
- interior comment "Defines an polygon's boundary within its outer boundary, i.e. a polygon with 'holes' in it.".
- spatial comment "A vocabulary for describing topological relations between features. $Id: spatial# 81 2012-02-05 11:06:49Z non88sense@gmail.com $".
- C comment "Relation C(x,y), read as 'x is connected with y'. This relation holds when two regions share a common point. It is the primitive relation\n\t\t\t\tin the RCC theory.".
- DR comment "Relation DR(x,y), read as 'x is discrete from y'. In order to prevent an exponential growth of triples when handling large\n\t\t\t\t amounts of data, a closed world assumption may also be possible. More precisely, by considering not explicitely connected regions as discrete\n\t\t\t\t regions. Moreover, discrete regions, which are not explicitely labeled as externally connected, would be considered disconnected from\n\t\t\t\t eachother.".
- Feature comment "A geographical feature, capable of holding spatial relations.".
- NTPP comment "Relation NTPP(x,y), read as 'x is a non-tangential proper part of y'. This relation holds, whenever a region x is \n\t\t\t\t\t\t\t labeled as a proper part of a region y, and they do not share common point in their borders.".
- O comment "Relation O(x,y), read as 'x overlaps y'. A region x overlaps a region y, if they share at least one common point of their interiors.".
- P comment "Relation P(x,y), read as 'x is a part of y', holds whenever the region x is contained within the borders of the region y.".
- PP comment "Relation PP(x,y), read as 'x is a proper part of y', means that the region x is contained within the borders of the \n\t\t\t\tregion y, and region y is not contained within the borders of the region y, which means they are not equals.".
- PPi comment "Relation PPi(x,y), read as 'x properly contains y'. Inverse of the PP(x,y) relation.".
- Pi comment "Relation Pi(x,y), read as 'x contains y'. Inverse of the P(x,y) relation.".
- TPP comment "Relation TPP(x,y), read as 'x is a tangential proper part of y'. This relation holds, whenever a region x is \n\t\t\t\t\t\t labeled as a proper part of a region y, and they share at least one common point in their borders, which means that they are\n\t\t\t\t\t\t externally connected.".
- relators comment "\n\t\t\n<xhtml:div class=\"relatorsAbout\" title=\"About the Relator Codes:\" datatype=\"rdf:XMLLiteral\" property=\"rdfs:comment\" xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\" xmlns:madsrdf=\"http://www.loc.gov/mads/rdf/v1#\" xmlns:xhtml=\"http://www.w3.org/1999/xhtml\" xmlns:rdfs=\"http://www.w3.org/2000/01/rdf-schema#\">\n\t\t\t<xhtml:p>\n\t\t\t\tRelator terms and their associated codes designate the relationship between a name and a \n bibliographic resource. The relator codes are three-character lowercase alphabetic strings \n that serve as identifiers. Either the term or the code may be used as controlled values.\n\t\t\t</xhtml:p>\n\t\t</xhtml:div>\n\n\t".
- turismo comment "Esta ontología se ha construido dentro del proyecto financiado por el Ayuntamiento de Zaragoza: \"Un visitante, una ruta\", una aplicación informática para el cálculo de rutas turísticas en la ciudad de Zaragoza en base al perfil y contexto del usuario.".
- Accesibilidad-de-movilidad-reducida comment "La accesibilidad es el grado con el que algo puede ser usado, visitado o accedido por todas las personas, independientemente de sus capacidades técnicas o físicas. En el caso de personas con movilidad reducida (que implique el uso de ayudas técnicas como muletas, sillas de ruedas, etc.), el grado de accesibilidad se mide de acuerdo a la facilidad de desplazamiento de los turistas por el entorno de los distintos recursos de la ciudad. La descripción del grado de accesibilidad de cada monumento se ha extraído de la base de datos de Monumentos.".
- Calificacion comment "Calificación oficial proporcionada por el Patronato de Turismo para los distintos restaurantes de la ciudad de Zaragoza.".
- Dia-Festivo comment "Día no laborable relacionado con alguna fiesta local o nacional: Fiesta del Pilar, Navidad, etc. Estos días requieren un tratamiento independiente ya que los recursos turísticos tienen estos días un horario especial.".
- Dia-de-la-semana comment "Cada uno de los días de la semana".
- Dia-de-visita-turistica comment "Cada uno de los días de visita turística por la ciudad de Zaragoza que escoge el turista. Para cada uno de estos días, el sistema construirá una ruta específica atendiendo a su perfil y a la disponibilidad de los recursos de la ciudad.".
- Estilo-artistico comment "El estilo es el conjunto de características que individualizan la tendencia artística de una época: barroco, mudéjar, renacentista, etc. La descripción de los estilos de cada monumento se ha extraído de la base de datos de Monumentos.".
- Evento-de-zaragoza comment "Esta clase conceptualiza la Agenda de actividades de la ciudad de Zaragoza. Cada uno de los eventos de la Agenda son instancias de este concepto. Los eventos se utilizan como sugerencias complementarias a la ruta definida por el sistema.".
- Grupo-de-viaje comment "Colectivo de personas que realizan una visita turística a la ciudad de Zaragoza, y para los que el sistema calculará una ruta contextualizada.".
- Horario-de-visita comment "Horarios de visita de los recursos turísticos: museos, edificios, iglesias, etc. Para construir el horario de visita, se utiliza el horario de apertura y cierre del recurso, el día de la semana y la temporada.".
- Horario-de-visita_7 comment "".
- Interes-en-entorno-natural comment "".
- Interes-en-estilo-barroco comment "".
- Interes-turistico comment "El interés turístico es el grado de relevancia que tiene un recurso de la ciudad de Zaragoza para un determinado perfil de turista. Por ejemplo, si a un turista le gusta el arte barroco, el turista tendrá interés en el arte barroco y, por tanto, en cualquier monumento que se englobe dentro de este estilo. Los intereses de los perfiles se calculan a partir de las preferencias declaradas por el usuario y utilizando las reglas de negocio.".
- Monumento comment "Construcción que posee valor artístico, arqueológico, histórico, etc. Las bases de datos de Monumentos y el Catálogo de Edificios de la Ciudad de Zaragoza se han mapeado a este concepto. Se ha subclasificado este concepto para conseguir una organización más rica de los monumentos. Esta información es usada por el sistema para configurar la ruta de manera más acorde a las preferencias del usuario mediante las reglas de negocio. Por ejemplo, si el usuario viaja con niños, el sistema por defecto no le ofrecerá museos en la ruta.".
- Perfil-de-turista comment "El perfil de turista es el conjunto de rasgos particulares que caracterizan a un turista en particular para el cual se va a calcular la ruta. El perfil de turista contempla desde los días de visita a la ciudad de Zaragoza (único dato obligatorio), el tipo de viaje, si es un viaje en grupo, los intereses y las preferencias turísticas del perfil.".
- Preferencia-de-ruta comment "Una preferencia de ruta es una constricción contextual para el cálculo dinámico de la ruta. Los perfiles de turista pueden requerir configuraciones particulares de los parámetros que afectan a la confección de la ruta, por ejemplo, que la velocidad de desplazamiento se vea afectada por características de movilidad de los turistas. Las preferencias de ruta para cada perfil se calculan mediante las reglas de negocio: duración de la visita y velocidad de desplazamiento.".
- Preferencia-de-usuario comment "Actividades que el turista puede estar interesado en realizar como visitar museos, pasear, ir de compras, etc.".
- Recurso-comercial comment "Recurso de interés comercial que ofrece la ciudad de Zaragoza. La información tanto de los mercados como de los sectores se ha extraído directamente de la página web municipal del Ayuntamiento. Los recursos comerciales se muestran como sugerencias en la ruta, y siempre bajo demanda del usuario (selección de la casilla \"Me gusta ir de compras\").".
- Recurso-de-zaragoza comment "Recursos de interés comercial, turístico o de hostelería, que ofrece la ciudad de Zaragoza.".
- Recurso-hostelero comment "Recurso de interés hostelero que ofrece la ciudad de Zaragoza. Las bases de datos de restaurantes y alojamientos se han mapeado a sus subclases.".
- Recurso-turistico comment "Recurso de interés turístico que ofrece la ciudad de Zaragoza.".
- Ruta-turistica comment "Es el itinerario calculado dinámicamente por el sistema. Para cada día de estancia del turista se confecciona una ruta específica que consiste en una serie de visitas a determinados recursos turísticos de la ciudad de Zaragoza. La ruta se adapta además a las características del perfil del usuario como las preferencias, las limitaciones de movilidad, el alojamiento, los horarios de visitas de los monumentos, etc. El sistema no sólo genera un itinerario en el tiempo y espacio correspondientes, sino que además proporciona una serie de sugerencias para el turista que complementan su visita a la ciudad: eventos de interés, restaurantes cercanos y sectores comerciales.".
- Temporada comment "Espacio temporal de varios meses. A nivel turístico, el año se divide en temporada de verano y temporada de invierno. La temporada influye en los horarios de apertura y cierre de los recursos turísticos: museos, iglesias, etc. El mismo monumento, pongamos por caso, la Basílica del \nPilar, no tiene el mismo horario de visita en la temporada de invierno, que en la temporada de verano. En esta ontología, se siguen los siguientes \ncriterios: 1) Temporada de invierno: desde el 9 de octubre hasta el 30 de abril; 2) Temporada de verano: desde el 1 de mayo hasta el 8 de octubre.".
- Viaje comment "Un viaje a la ciudad de Zaragoza puede realizarse por distintos motivos. En esta ontología, se contamplan cuatro posibilidades: puramente turísticos, por motivos laborales, asistencia a un congreso o conferencia y por descanso.".
- Visita-turistica comment "Una visita turística es cada una de las partes de las que se compone una ruta turística. Una visita turística tiene como objetivo uno y sólo un recurso de Zaragoza que forma parte del itinerario de la ruta. Las visitas turísticas están ordenadas temporalmente y el sistema procura minimizar la distancia entre unas y otras de acuerdo a las características del perfil.".
- Zona-verde comment "Espacio verde en la ciudad de Zaragoza como puede ser parques, zonas ajardinadas, etc.".
- C1001 comment "Description is modified from: Guidelines for authority records and references / revised by the Working Group on GARE Revision. Second edition. München : K.G. Saur, 2001.".
- C1003 comment "Description is modified from that in Functional requirements for bibliographic records : final report, by the IFLA Study Group on the Functional Requirements for Bibliographic Records, published by K.G. Saur, 1998.".
- P2053 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P2054 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P2075 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P2076 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P2089 comment "Source documentation has label \"has reproduction\"; amended to improve consistency.".
- P2105 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P2106 comment "Source documentation has \"literary genre\", but other genres allowed.".
- P3004 comment "Source documentation has label \"Other Distinguishing Characteristic\", used also for an Expression attribute.".
- P3012 comment "Source document has label \"Other Distinguishing Characteristic\" used also for a Work attribute.".
- P3040 comment "Source documentation has \"includes\" prefixing the definition, interpreted as \"and other dates\" in the property description.".
- P3052 comment "Source documentation has \"marks/inscriptions\"; slash character replaced with \"or\" to improve clarity.".
- P3053 comment "Source documentation has \"acquisition/access\"; slash character replaced with \"or\" to improve clarity.".
- P3054 comment "Source documentation has \"fabricator/manufacturer\"; slash character replaced with \"or\" to improve clarity.".
- P3055 comment "Source documentation has \"publication/distribution\"; slash character replaced with \"or\" to improve clarity.".
- P3056 comment "Source documentation has \"publisher/distributor\"; slash character replaced with \"or\" to improve clarity.".
- P3057 comment "Source documentation has \"publication/distribution\"; slash character replaced with \"or\" to improve clarity.".
- P3058 comment "Source documentation has \"edition/issue\"; slash character replaced with \"or\" to improve clarity.".
- frbrer.rdf comment "This ontology is based on Functional requirements for bibliographic records, current text, February 2009.".
- ds.owl comment "This ontology offers OWL-Lite definition for object list. It is a restricted version of OWL-S ObjectList (http://www.daml.org/services/owl-s/1.1/generic/ObjectList.owl). \n It is compatible to rdf:List with the following differences: (i) OWL individuals as list members and (ii) appropriate property cardinality restriction. The range of first will specified by the subclasses.".
- List comment "A template for defining typed-list. It functions like rdf:List with object members.".
- first comment "The first item in the subject RDF list.".
- rest comment "The rest of the subject RDF list after the first item.".
- pml-provenance.owl comment "The provenance part of PML2 ontology. It is a fundamental component of PML2 ontology.".
- Agent comment "actionalble entities.".
- Document comment "A physical information container that is not actionable. They function like database.".
- DocumentFragment comment "A fragment of document that can be used as source.".