Comments (5)
@stain -- I'm not suggesting anything, still trying to get my head around this issue. At the moment we recommend additional Classes and Properties are use /rdfs?/ prefix and this is coded into the Javascript library and used for looking up term definitions when they are present in the crate.. We are also maintaining a schema (vocabulary) for a major project using the Schema.org Style Schema method (SOSS) where the terms are rdfs:Class
, rdf:Property
and (schema:)DefinedTerm
and (schema):DefinedTermSet
. If we change to using (schema:)Class in profiles then I'd want to go back and change all that (and still support the use of /rdfs?:/
)
I understand the idea of DefinedTerm
but when we know something is a class or a property, isn't it better to bring it into the schema.org world by defining it in a way that tools CAN operate on it as part of a class hierarchy -- we are starting to build more of these in our work.
from ro-crate.
The reason for adding DefinedTerm
to the @type
array was to unify a bit with the ad-hoc classes as well as how terms are imported (which may also be used beyond Class/Property, e.g. for roles). The idea being that any term imported is a DefinedTerm
but could also be something else, in which case it should (at least) have the name
from the Schema.org type.
The move to then use schema.org's types Class
and Property
which mirrors rdfs:Class
and rdfs:Property
is perhaps more controversial as these are not commonly used for defining ontologies - as you point out not even used by Schema.org's own definitions which are RDFS only. I also don't know of any tooling that support these. Perhaps they are sensible when only "quoting" such a class or property that is defined elsewhere, but not when defining classes/properties only directly within the profile.
In FAIR-IMPACT we have proposed to evolve the RO-Crate Profile to also work for any Semantic Artefact gathering - in which case it would IMHO stay in soft schema.org land because the artefacts would be fully defined in various ontology languages (e.g. SKOS, OWL2) and imposing rdfs:*
would then be too strong. @dgarijo may have different views.
So are you @ptsefton then proposing to change/remove the new text in https://www.researchobject.org/ro-crate/1.2-DRAFT/appendix/jsonld.html#add-local-definitions-of-ad-hoc-terms (which suggests rdfs:*
as an optional ad-on) from #232 to revert back to requiring rdfs:*
as in RO-Crate 1.1?
from ro-crate.
Then I think some middle ground is to encourage again use of rdfs:Class
and rdfs:Property
when defining them there-and-then in a crate (allowing general rdfs tooling to work, class hierarchies etc).
Then we can keep using schema.org's informal DefinedTerm
when quoting something already defined elsewhere (without representing their hierarchy etc) - in which case we should say where with url
and inDefinedTermset
etc! See for instance https://trefx.uk/trusted-wfrun-crate/0.3/ro-crate-preview.html#https%3A//w3id.org/shp%23CheckValue that quotes https://w3id.org/shp#CheckValue without re-declaring all its superclasses etc.
(I think I'll add to our profile docs that you use the inverse inDefinedTermSet
when quoting only SOME of the terms from a defined-elsewhere termset, or the hierarchical hasDefinedTerm when they are all defined there in the profile. )
This would however not permit your tooling to know how to apply these new terms, as it would not know if they are classes, properties or something else -- without parsing its defining ontology which we know from OWL imports can be a massive minefield can of worms, and can be using a myriad of different ontology standards and formats (and defining those explicitly is what I would want to add in the FAIR-IMPACT Semantic Artefact Crate).
This was my reasoning for adding lightweight Class
and Property
more as indicator, they have no hierarchy, but formally is what's expected by their domainIncludes
and rangeIncludes
rather than the rdfs variants. So it's inconsistent in schema.org's internal definition unless you consider these to be equivalent with rdfs
counterparts.
With the loosening in #260 to no longer require to have a known schema.org type, so we can have just rdfs:Class
and rdfs:Property
when defining inline.
BTW, the rdfs namespace is sadly also without a human-readable variant, so http://www.w3.org/2000/01/rdf-schema#Class just gives a Turtle file -- should therefore define these in the Crate profile in which case they would have to be declared as schema.org Class
-es by my logic above! ;-D
from ro-crate.
Follow generally Crate-O's mode file to do Schema.org-style schemas:
rdfs:Class
andrdf:Property
withdomainIncludes
andrangeIncludes
DefinedTerm
for other terms/constants.
Avoid too many types.
from ro-crate.
This is now implemented in #262 etc. as part of the revamp on Profiles.
from ro-crate.
Related Issues (20)
- Add ELN file format use case
- Not all favicons updated HOT 1
- Some old links do not work anymore HOT 3
- Use Case: Record Git repository, release tag/version, and dependencies within a workflow description inside RO-Crate HOT 1
- Use ETT table of contents
- Use only the `title: ` attribute in the frontmatter for titles, avoid duplicating title in Markdown
- Reinstate ETT logo in the footer HOT 1
- Review overwrites of ETT theme includes
- Add links to find out more about RO-Crate to top of homepage
- BioDT use case HOT 2
- BUG: Spec is hard to find HOT 1
- RO-Crate Profiles on the website as a menu option HOT 1
- Issue with ROHub downloads (contextual entities still not linked correctly - they are string values)
- Search results do not include spec pages HOT 2
- Use Case: I want to indicate where Web-based Data Entities should be downloaded to
- Use Case: Deep archive of RO-Crate with downloaded references
- Guidance and best practice for nested RO-Crates
- Use Case: how to reference data entities within a referenced RO-Crate HOT 2
- Use Case: How can the RO-Crate enable future maintenance/changes
- Use Case: Building combined knowledge graph of nested RO-Crates
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ro-crate.