Domains and Ranges: Barcelona discussion - FROZEN COPY FOR REFERENCE EDIT DomainsActionsDone INSTEAD
-
Note: In the following section, wherever we say "resource" we mean non-literal resource. See section on Problematic Properties.
-
Note: In Barcelona, the terms were taken out of order, starting with "audience". In these revised notes, the terms have been put back into their usual order.
DC-15 properties from /1.1/ namespace now declared also in /terms/
-
contributor: AGREED: approved
coverage: ![[AGREED]](DomainsActions_files/moin-inter.png){kind=small}
approved
LocationPeriodJurisdiction: AGREED: approve
Jurisdiction: AGREED: approved
creator: AGREED: approved
date: AGREED: domain is approved, propose range as literal (go to comment with this)
description: AGREED: domain of non-literal resource and range of rdfs:resource
format: AGREED: approved
identifier: AGREED: approved
Reference: AGREED: approved
language: AGREED: the defintion of language should include computer languages, sign languages, and written languages
ACTION 2007-03-18: define language (Diane Hillmann)
SUGGESTION: system for communicating ideas and feelings using sounds, signs, gestures, and marks SUGGESTION: add a comment to say that it includes written, spoken, sign, and computer languages
Language: AGREED: see language above
publisher: AGREED: approved
relation: AGREED: approved
rights: AGREED: approved
RightsStatement: AGREED: change definition to: A statement about the intellectual property rights (IPR) held in or over a Resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
source: AGREED: approved
subject: AGREED: approved
title: AGREED: domain is approved, range propose literal, and then send out for discussion
type: AGREED: approved
Terms which have always been in the /terms/ namespace
-
abstract: AGREED: domain non-literal and range is rdfs:resource
accessRights: approved
accrualMethod: AGREED: approved
-
AccrualMethod: AGREED: approved
-
Frequency: AGREED: approved
-
Policy: AGREED: approved
audience - AGREED: accept the domain of resource and range of AgentClass
-
AgentClass -- AGREED: approve the term with a change the definition of AgentClass to "a group of Agents"
bibliographicCitation -- AGREED: approved
-
BibliographicResource -- AGREED: approve with change to definition, changing "published resource" to "documentary resource"
conformsTo -- AGREED: approved
-
Standard AGREED: approved
dateAccepted refer to available
dateCopyrighted refer to available
dateSubmitted refer to available
educationLevel AGREED: approved
extent AGREED: approved
hasFormat AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
hasPart AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
hasVersion AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
instructionalMethod AGREED: approved
isFormatOf AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
IsPartOf -- isReferencedBy -- isREplacedBy -- isRequiredBy -- isVersionOf AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
issued AGREED: domain is ok, querying the range
license AGREED: approved
mediator AGREED: approved
medium AGREED: approved
modified AGREED: domain is ok, propose range as literal (go to comment with this)
provenance AGREED: approved
references AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
replaces AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
requires AGREED: non-literal resources is both the domain and range so left unspecified until Singapore
rightsHolder AGREED: approved
spatial AGREED: approved
Location: AGREED: approved AGREED: change definition to "a named place or spatial region"
tableOfContents: AGREED: rdfs:resource as range AGREED: not a case where we mean non-literal resource (because description allows images)
[may not have captured all approved 1.1 above, e.g., I did capture Location]
temporal AGREED: with change in the definition Period
Period AGREED: change definition to "interval of time that is named or defined by its start and end dates" AGREED: this is broader than the range of date and its subproperties and should be noted
valid AGREED: domain is ok, propose range as literal (go to comment with this)
== Problematic properties ==
-
ISSUE: A title with multiple encodings is different from multiple title statements.
ISSUE: When domain is stated to be rdfs:resource in /terms/ part of the Domains proposal we intend it to mean non-literal resource because the meaning of rdfs:Resource is broader and includes literals.
ISSUE: Where the domain and range is resource, we can either say nothing, or we can say rdfs:Resource (which is stating the obvious) -- this is related to our actions related to specifically stating non-literal resource.
ISSUE: Because we have inverses in the isFormatOf type properties, we need the same class at both ends of the inverse -- therefore we should make all non-literal resources (TBA).
AGREED: We are going to propose that range of description, abstract, and table of contents is rdfs:resource knowing that this causes OWL-DL incompatability for these properties - this will go out for comment - we're asking if this is reasonable to do this for these three properties.
AGREED: We need a class and will define a class of non-literal resources for both domains and ranges.
ACTION 2007-03-18: Andy to add a new class of non-literal resource to the wiki, use as domain and range as appropriate.
AGREED: Usage of this [non-literal] class for domains should be part of the next comment period.
ISSUE: Whether owl:Thing is a suitable thing for defining a class of non-literal resources. Formal semantics seem worryingly opaque in the OWL spec.
-
ACTION: Tom to transcribe easel graph into the meeting notes (Tom and Andy have pictures)
-
ACTION 2007-03-18: (for lack of volunteers, by default Tom): write a proposal capturing the issue of string, unspecified, and thing for the problematic DCTERMS properties (title and its subproperties, date and its subproperties, and description and its subproperties). Taking the following position:
-
1. Title and its subproperties as literals [check notes]
-
2. Date and its subproperties as literals
-
3. Description and its subproperties as range = rdfs:resource
-
Then send this proposal out for public comment. There are two audiences for this comment: (1) multiple script communities and (2) SW community asking: best practice for unspecified ranges. Note that we will use the non-literal resource in all cases where the domain of our properities is listed as rdfs:resource (in the proposal).