Data Portal @ linkeddatafragments.org

Matches in LOV for { ?s <http://www.w3.org/2004/02/skos/core#scopeNote> ?o. }

• dateOfConferenceEtc scopeNote "FRBR 4.7.4 and FRAD 4.3.".
• dateOfDeath scopeNote "FRBR 4.6.2 and FRAD 4.1.".
• dateOfEstablishment scopeNote "FRBR 4.7.4 and FRAD 4.3.".
• dateOfTermination scopeNote "FRBR 4.7.4 and FRAD 4.3.".
• familyHistory scopeNote "FRAD 4.2.".
• fullerFormOfName scopeNote "FRBR 4.6.1 and FRAD 4.1.".
• gender scopeNote "FRAD 4.1.".
• hereditaryTitle scopeNote "FRAD 4.2.".
• identifierForTheCorporateBody scopeNote "FRAD 5.2.".
• identifierForTheFamily scopeNote "FRAD 5.2.".
• locationOfHeadquarters scopeNote "FRBR 4.7.3 and FRAD 4.3.".
• nameOfTheCorporateBody scopeNote "FRBR 4.7.1 and FRAD 5.2.".
• nameOfTheFamily scopeNote "FRAD 5.2.".
• nameOfThePerson scopeNote "FRBR 4.6.1 and FRAD 5.2.".
• periodOfActivityOfThePerson scopeNote "FRBR 4.6.2 and FRAD 4.1.".
• placeAssociatedWithTheCorporateBody scopeNote "FRBR 4.7.3 and FRAD 4.3.".
• placeOfBirth scopeNote "FRAD 4.1.".
• placeOfDeath scopeNote "FRAD 4.1.".
• preferredNameForTheCorporateBody scopeNote "FRBR 4.6.1 and FRAD 5.2.".
• preferredNameForTheFamily scopeNote "FRAD 5.2.".
• preferredNameForThePerson scopeNote "FRBR 4.6.1 and FRAD 5.2.".
• professionOrOccupation scopeNote "FRAD 4.1.".
• titleOfThePerson scopeNote "FRBR 4.6.3 and FRAD 4.1.".
• editorOfCompilationExpression scopeNote "For compilations of data, information, etc., that result in new works, see Compiler.".
• Agent scopeNote "Based on FRBRoo/CIDOC-CRM concept of E39 Actor as agent.".
• Agent scopeNote "Rationale: This class is a domain of edm:wasPresentAt".
• EuropeanaObject scopeNote "Rationale: This class is used to tag objects that are the result of activity of Europeana, and, as such, objects on which Europeana holds rights".
• Event scopeNote "Rationale:This class is a domain of edm:happenedAt and the domain of edm:occurredAt".
• ProvidedCHO scopeNote "Rationale: This class is the range of edm:aggregatedCHO. A resource of type ProvidedCHO can be the subject of statements using edm:isRelatedTo or any more specific property.".
• ContentLocation scopeNote "Usage Notes: If the preservation repository uses the objectIdentifier as a handle for retrieving data, contentLocation is implicit and does not need to be recorded.".
• CopyrightInformation scopeNote "Usage Notes: When rights basis is a copyright, copyrightInformation should be provided. Repositories may need to extend this with more detailed information. See the California Digital Library's copyrightMD schema (www.cdlib.org/inside/projects/rights/schema/) for an example of a more detailed scheme.".
• CreatingApplication scopeNote "Usage Notes: This semantic unit applies to both objects created external to the repository and subsequently ingested, and to objects created by the repository, for example, through migration events. The creatingApplication container is repeatable if more than one application processed the object in turn. For example, a file could be created by Microsoft Word and later turned into a PDF using Adobe Acrobat. Details of both the Word and Acrobat applications may be recorded. However, if both files are stored in the repository, each file should be completely described as an Object entity and linked by using relationship information with a relationshipType \"derivation.\" It may also be repeated to record the creating application before the object was ingested as well as the creating application used as part of the ingest process. For example, an HTML file was created pre-ingest using Dreamweaver, and the Web crawler Heritrix then captured a snapshot of the files as part of the ingest. The amount of information needed for creatingApplication given here is minimal. For more granularity, extensibility is provided. Rather than having each repository record this locally, it would be preferable to have a registry of this information similar to format or environment registries.".
• Dependency scopeNote "Usage Notes: This semantic unit is for additional objects that are necessary to render a file or representation, not for required software or hardware. It may also be used for a non-executable component of the object, such as a font or style sheet. For things that the software requires, see swDependency. This semantic unit does not include objects required by structural relationships, such as child content objects (e.g., figures that are part of an article), which are recorded under relationship with a relationshipType of \"structural\". It is up to the repository to determine what constitutes a dependency in the context of the designated community. The objects noted may be internal or external to the preservation repository.".
• Environment scopeNote "Usage Notes: All of this semantic units' subunits are optional. At least one subunit (i.e. environmentNote, dependency, software, hardware, and/or environmentExtension) must be present if this container is included.".
• EventOutcomeDetail scopeNote "Usage Notes: This may be used to record all error and warning messages issued by a program involved in the event or to record a pointer to an error log. If the event was a validity check (e.g., profile conformance) any anomalies or quirks discovered would be recorded here. All subunits of this semantic unit are optional. At least one subunit (i.e. eventOutcomeDetailNote and/or eventOutcomeDetailExtension) must be present if this container is included.".
• EventOutcomeInformation scopeNote "Usage Notes: A repository may wish to supplement a coded eventOutcome value with additional information in eventOutcomeDetail. Since events may have more than one outcome, the container is repeatable. All subunits of this semantic unit are optional. At least one subunit (i.e. eventOutcome or eventOutcomeDetail) must be present if this container is included.".
• Fixity scopeNote "Usage Notes: To perform a fixity check, a message digest calculated at some earlier time is compared with a message digest calculated at a later time. If the digests are the same, the object was not altered in the interim. Recommended practice is to use two or more message digests calculated by different algorithms. (Note that the terms \"message digest\" and \"checksum\" are commonly used interchangeably. However, the term \"checksum\" is more correctly used for the product of a cyclical redundancy check (CRC), whereas the term \"message digest\" refers to the result of a cryptographic hash function, which is what is referred to here.) The act of performing a fixity check and the date it occurred would be recorded as an Event. The result of the check would be recorded as the eventOutcome. Therefore, only the messageDigestAlgorithm and messageDigest need to be recorded as objectCharacteristics for future comparison. Representation level: It could be argued that if a representation consists of a single file or if all the files comprised by a representation are combined (e.g., zipped) into a single file, then a fixity check could be performed on the representation. However, in both cases the fixity check is actually being performed on a file, which in this case happens to be coincidental with a representation. Bitstream level: Message digests can be computed for bitstreams although they are not as common as with files. For example, the JPX format, which is a JPEG2000 format, supports the inclusion of MD5 or SHA-1 message digests in internal metadata that was calculated on any range of bytes of the file.".
• Format scopeNote "Usage Notes: A bitstream embedded within a file may have different characteristics than the larger file. For example, a bitstream in LaTex format could be embedded within an SGML file, or multiple images using different colorspaces could be embedded within a TIFF file. format must be recorded for every object. When the bitstream format can be recognized by the repository and the repository might want to treat the bitstream differently from the embedding file for preservation purposes, format can be recorded for embedded bitstreams. Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either formatDesignation or formatRegistry) must be present if this container is included or both may be used. If the subunit (formatDesignation or formatRegistry) needs to be repeated, the entire format container is repeated. This allows for association of format designation with a particular set of format registry information. For example, if the precise format cannot be determined and two format designations are recorded, each is given within a separate format container. The format container may also be repeated for multiple format registry entries.".
• FormatDesignation scopeNote "Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. Both may be included. The most specific format (or format profile) should be recorded. A repository (or formats registry) may wish to use multipart format names (e.g., \"TIFF_GeoTIFF\" or \"WAVE_MPEG_BWF\") to achieve this specificity.".
• FormatRegistry scopeNote "Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. If more than one formatRegistry needs to be recorded the format container should be repeated to include each additional set of formatRegistry information. The PREMIS working group assumed that a number of format registries will be developed and maintained to support digital preservation efforts. The proposal for a Global Digital Format Registry (GDFR) (http://hul.harvard.edu/gdfr/documents.html#data), for example, would create a network-accessible registry designed to store detailed specifications on formats and profiles.".
• Inhibitors scopeNote "Usage Notes: Some file formats allow encryption for embedded bitstreams. Some file formats such as PDF use passwords to control access to content or specific functions. Although this is actually implemented at the bitstream level, for preservation purposes it is effectively managed at the file level; that is, passwords would not be recorded for individually addressable bitstreams. For certain types of inhibitor keys, more granularity may be required. If the inhibitor key information is identical to key information in digital signatures, use those semantic units.".
• LicenseInformation scopeNote "Usage Note: When rights basis is a license, licenseInformation should be provided.".
• ObjectCharacteristics scopeNote "Usage Notes: The semantic units included in objectCharacteristics should be treated as a set of information that pertains to a single object at a single compositionLevel. Object characteristics may be repeated when an object was created by applying two or more encodings, such as compression and encryption. In this case each repetition of objectCharacteristics would have an incrementally higher compositionLevel. When encryption is applied, the objectCharacteristics block must include an inhibitors semantic unit. A bitstream embedded within a file may have different object characteristics than the file. Where these characteristics are relevant for preservation, they should be recorded. When a single file is equivalent to a representation, objectCharacteristics may be applied and thus associated with the representation. In these cases, the relationship between the file comprising the representation and other associated files may be expressed using relationshipSubType.".
• PreservationLevel scopeNote "Usage Notes: If the repository offers only a single preservation level, this value does not need to be explicitly recorded within the repository. Application of a particular set of preservationLevel semantic units may only cover a single representation of an object: representations in other technical forms or serving other functions may have a different preservationLevel applied. The container may be repeated if a preservation level value needs to be recorded in additional contexts (see preservationLevelRole).".
• RelatedObjectIdentification scopeNote "Usage Notes: The related object may or may not be held within the preservation repository. Recommended practice is that objects reside within the repository unless there is a good reason to reference an object outside. Internal and external references should be clear.".
• RightsStatement scopeNote "Usage Notes: This semantic unit is optional because in some cases rights may be unknown. Institutions are encouraged to record rights information when possible. Either rightsStatement or rightsExtension must be present if the Rights entity is included. The rightsStatement should be repeated when the act(s) described has more than one basis, or when different acts have different bases.".
• Signature scopeNote "Usage Notes: Several of the semantic components of signatureInformation are taken from the W3C's XML-Signature Syntax and Processing; see www.w3.org/TR/2002/REC-xmldsig-core-20020212/ for more information on the structure and application of these semantic units.".
• SignificantProperties scopeNote "Usage Notes: All of this semantic unit's subunits are optional. At least one of the significantPropertiesValue and significantPropertiesExtension subunits must be present if this container is included or both may be used. Significant properties may be objective technical characteristics subjectively considered important, or subjectively determined characteristics. For example, a PDF may contain links that are not considered important and JavaScript that is considered important. Or future migrations of a TIFF image may require optimization for line clarity or for color; the option chosen would depend upon a curatorial judgment of the significant properties of the image. Listing significant properties implies that the repository plans to preserve these properties across time and requires them to acceptably survive preservation action; for example, to be maintained during emulation or after format migration. It also implies that the repository would note when preservation action results in modification of significant properties. In practice, significant properties might be used as measures of preservation success, as part of quality checking the results of a preservation action or evaluating the efficacy of a preservation method. For example, if the listed significant properties are not maintained after application of a particular preservation method, it may indicate a failure of the process or that the method is not well suited to the type of material. More experience with digital preservation is needed to determine the best ways of representing significant properties in general, and of representing modification of significant properties. The semantic units included in the significantProperties container aim to provide a flexible structure for describing significant properties, allowing general types of aspects, facets or attributes of an object to be declared and to be paired with specific significant details about the object pertaining to that aspect, facet or attribute. For example, some repositories may define significant properties for objects related to facets of content, appearance, structure, behavior, and context. Examples of facet:detail pairs in this case could include: significantPropertiesType = \"content\" significantPropertiesValue = \"all textual content and images\" significantPropertiesType = \"behavior\" significantPropertiesValue = \"editable\" Other repositories may choose to describe significant properties at a more granular attribute level; for example: significantPropertiesType = \"page count\" significantPropertiesValue = \"7\" significantPropertiesType = \"page width\" significantPropertiesValue = \"210 mm\" Each facet:detail pair should be contained in a separate, repeated significantProperties container. Further work on determining and describing significant properties may yield more detailed schemes to facilitate general description. Representing modification of significant properties as a result of preservation action also requires further work. One possible way involves the use of Object and Event information: Object A has significant properties volume and timing, which are recorded as significantProperties of A. In migrated version B, the timing is modified, which is noted in the eventOutcome of the migration event. Only volume is listed as a significant property of B.".
• StatuteInformation scopeNote "Usage Notes: When rights basis is a statute, statuteInformation should be provided.".
• Storage scopeNote "Usage Notes: Normally there would be a single storage location and medium for an object, because an object in another location would be considered a different object. The storage composite should be repeated if there are two or more copies that are identical bit-wise and managed as a unit except for the medium on which they are stored. They must have a single objectIdentifier and be managed as a single object by the repository. Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either contentLocation or storageMedium) must be present or both may be used.".
• hasCompositionLevel scopeNote "Usage Notes: A file or bitstream can be subject to multiple encodings that must be decoded in reverse order (highest to lowest). For example, file A may be compressed to create file B, which is encrypted to create file C. To recreate a copy of the base file A, one would have to unencrypt file C to create file B and then uncompress file B to create file A. A compositionLevel of zero indicates that the object is a base object and not subject to further decoding, while a level of 1 or higher indicates that one or more decodings must be applied. Numbering goes lowest to highest (first encoded = 0). 0 is base object; 1-n are subsequent encodings. Use 0 as the default if there is only one compositionLevel. When multiple file objects are bundled together as filestreams within a package file object (e.g., a ZIP file), the individual filestream objects are not composition levels of the package file object. They should be considered separate objects, each with their own composition levels. For example, two encrypted files zipped together and stored in an archive as one file object would be described as three separate objects, each with its own associated metadata. The storage location of the two inner objects would point to the ZIP file, but the ZIP file itself would have only a single composition level (of zero) whose format would be \"zip.\"".
• hasContentLocationValue scopeNote "Usage Notes: This could be a fully qualified path and filename, or the information used by a resolution system (e.g., a handle) or the native information used by a storage management system. For a bitstream or filestream, this would probably be the reference point and offset of the starting position of the bitstream. It is up to the repository to determine the level of granularity that should be recorded.".
• hasCreatingApplicationName scopeNote "Usage Notes: The creatingApplication is the application that created the object in its current format, not the application that created the copy written to storage. For example, if a document is created by Microsoft Word and subsequently copied to archive storage by a repository's Ingest program, the creatingApplication is Word, not the Ingest program.".
• hasDateCreatedByApplication scopeNote "Usage Notes: Use the most precise date available. This is the date the object was created by the creating application, not the date any copy was made externally or by the repository. For example, if a file is created by Microsoft Word in 2001 and two copies are made in 2003, the dateCreatedByApplication of all three files is 2001. The date a file is written to storage can be recorded as an Event. If the object itself contains internal creation and modification dates, the modification date should be used as dateCreatedByApplication. If the application is a Web harvester capturing an object at a point of time, use for date captured.".
• hasEndDate scopeNote "Usage Notes: Use \"0000-00-00T00:00:00+00:00\" for an open ended term of grant. Omit endDate if the ending date is unknown or the permission statement applies to many objects with different end dates.".
• hasEventDateTime scopeNote "Usage Notes: Recommended practice is to record the most specific time possible and to designate the time zone.".
• hasEventOutcome scopeNote "Usage Notes: Recommended practice is to use a controlled vocabulary that a system can act upon automatically. More detail about the outcome may be recorded in eventOutcomeDetail. Recommended practice is to define events with sufficient granularity that each event has a single outcome.".
• hasFormatName scopeNote "Usage Notes: For unidentified formats, formatName may be recorded as \"unknown\".".
• hasFormatRegistryName scopeNote "Usage Notes: This can be a formal name, internally used name, or URI.".
• hasHardwareName scopeNote "Usage Notes: Include manufacturer when this helps to identify or disambiguate the product. Include version for firmware or other components where that information is pertinent.".
• hasIdentifierType scopeNote "Usage Notes: The type of the identifier may be implicit within the repository as long it can be explicitly communicated when the item is disseminated outside of it.".
• hasLicenseTerms scopeNote "Usage Notes: This could contain the actual text of the license or agreement or a paraphrase or summary.".
• hasPreservationLevelValue scopeNote "Usage Notes: Only one preservationLevelValue may be recorded per preservationLevel container. If a further preservationLevelValue applies to the object in a different context, a separate preservationLevel container should be repeated.".
• hasSignatureValidationRules scopeNote "Usage Notes: This may include the canonicalization method used before calculating the message digest, if the object was normalized before signing. This value could also be a pointer to archive documentation.".
• hasSoftwareName scopeNote "Usage Notes: Include manufacturer when this helps to identify or disambiguate the product, for example, use \"Adobe Photoshop\" rather than \"Photoshop.\"".
• hasStatuteCitation scopeNote "Usage Notes: Use standard citation form when applicable.".
• value scopeNote "Used to describe the content of a bibo:Document and othr bibliographic resouces.\n\nWe suggest to use this property instead of the deprecated \"bibo:content\" one.".
• Collection scopeNote "Labelled collections can be used where you would like a set of concepts to be displayed under a 'node label' in the hierarchy.".
• ConceptScheme scopeNote "A concept scheme may be defined to include concepts from different sources.".
• OrderedCollection scopeNote "Ordered collections can be used where you would like a set of concepts to be displayed in a specific order, and optionally under a 'node label'.".
• broader scopeNote "By convention, skos:broader is only used to assert an immediate (i.e. direct) hierarchical link between two conceptual resources.".
• broaderTransitive scopeNote "By convention, skos:broaderTransitive is not used to make assertions. Rather, the properties can be used to draw inferences about the transitive closure of the hierarchical relation, which is useful e.g. when implementing a simple query expansion algorithm in a search application.".
• inScheme scopeNote "A concept may be a member of more than one concept scheme.".
• narrower scopeNote "By convention, skos:broader is only used to assert an immediate (i.e. direct) hierarchical link between two conceptual resources.".
• narrowerTransitive scopeNote "By convention, skos:narrowerTransitive is not used to make assertions. Rather, the properties can be used to draw inferences about the transitive closure of the hierarchical relation, which is useful e.g. when implementing a simple query expansion algorithm in a search application.".
• notation scopeNote "By convention, skos:notation is used with a typed literal in the object position of the triple.".
• note scopeNote "This property may be used directly, or as a super-property for more specific note types.".
• semanticRelation scopeNote "This property should not be used directly, but as a super-property for all properties denoting a relationship of meaning between concepts.".
• labelRelation scopeNote "skosxl:labelRelation is not intended to be used directly, but rather as the basis for a design pattern which can be refined for more specific labeling scenarios.".
• Agent scopeNote "Used to describe any \"agent\" related to bibliographic items. Such agents can be persons, organizations or groups of any kind.".
• Organization scopeNote "Ued to describe an organization related to bibliographic items such as a publishing company, etc.".
• Person scopeNote "Used to describe a Person related to a bibliographic ite such as an author, an editor, etc.".
• based_near scopeNote "Used to link an agent, related to bibliographic things, to a place where it is based near: can be a city, a monument, a building, etc.".
• depiction scopeNote "Used to link an agent with an image that depict it.".
• homepage scopeNote "Used to link an agent to its homepage (which is a web page accessible using a URL).".
• P2029 scopeNote "E.g. a sequel, a serial or series that has changed title. Excludes derivative works that modify the content of an earlier work.".
• P2031 scopeNote "Excludes specific characteristics represented by other properties.".
• P2032 scopeNote "Excludes specific characteristics represented by other properties.".
• P2033 scopeNote "Excludes specific characteristics represented by other properties.".
• P2034 scopeNote "Excludes specific characteristics represented by other properties.".
• P2035 scopeNote "Includes criticism, commentary, review, casebook, etc., and the object of that analysis (that is, the target work, expression, or manifestation).".
• P2036 scopeNote "Includes criticism, commentary, review, casebook, etc., and the object of that analysis (that is, the target work, expression, or manifestation).".
• P3016 scopeNote "Includes the title, publisher, date, etc., of the resource for which the controlled access point was originally created. Includes the title, edition, etc., of the reference source(s) used to establish the conventional name or title.".
• P3018 scopeNote "Includes the fuller form of name added to the base access point. Includes the title of nobility, title of royalty, or ecclesiastical title added to the base access point. Includes dates added to the base access point. Includes the place name associated with a corporate body added to the base access point. Includes a number associated with a corporate body or a musical work added to the base access point. Includes a title of an adaptation or version of a work added to the base access point. Includes the name and/or number of a section or part of a work added to the base access point. Includes a term designating the form of a work added to the base access point. Includes a term designating language of expression added to the base access point. Includes a term designating the key in which a musical work was originally composed added to the base access point. Includes a term designating the medium of performance for which a musical work was originally conceived added to the base access point. Includes other designations associated with persons and corporate bodies added to the base access point.".
• P3022 scopeNote "Includes personal names, corporate names, names of families, trade names, and titles of works and manifestations. Includes names of concepts, objects, events, and places.".
• P3024 scopeNote "Includes forms, genres, etc., (e.g., literary works, critical works, works on mathematics, detective novels) associated with a name used by an author.".
• P3045 scopeNote "Includes area of origin, etc.".
• P3046 scopeNote "Includes historical information pertaining to a work, including title changes for continuing resources.".
• P3047 scopeNote "E.g. Moir rare book collection, http://www.juilliardmanuscriptcollection.org/, Short loan collection (School of African and Oriental Studies, University of London), Library of Congress. Does not include collections where the item is originally published or manufactured as a component part.".
• P3050 scopeNote "Includes information about the subject of the work. Includes classification numbers.".

• first
• previous
• next