-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relax range of name (and many others) #29
Comments
Should all xsd:token and xsd:string elements be converted to rdfs:Literal to support langString? |
Probably not. Strings and tokens can be alpha-numeric codes that are language independent. These would often be best coded as xsd:token Also, I think you are using xsd:string for some dates (where xsd:date or schema:date would be better) e.g.
|
Sorry @aemnathanclinton I misread the question: yes you could change all xsd:token and xsd:string elements to rdfs:Literal. |
@philbarker, Looking at the properties you referenced, they are all xsd:string. There are only two properties that are xsd:token, and they are identifiers. Do you still recommend implementing rdfs:literal, or does xsd:string give you what you need? |
As I understand it, PESC transcript is used in Canada so they need to know which data is in English and which in French, hence langstring is better than string. |
OrganizationName has a range of xsd:token. We are trying to use CEDS ontology properties for the PESC Transcript standard, which has to work internationally. Many organizations represent their name in different languages, e.g. French and English in parts of Canada, and it is desirable to be able to use a langString so that the different language variations can be noted and applications can select the appropriate one. In order to accommodate this and any current use of the property where the language is not noted, we suggest the range be set to rdfs:Literal.
The similar considerations apply to many other properties that have xsd:token as their range, such as AddressCity, AddressCountyName, CalendarEventDayName, CourseTitle etc. etc.
The text was updated successfully, but these errors were encountered: