Dear Matteo and all
Looks good to me but I am a bit puzzled about two things:
- Why do we separate between two subclass “input” and “output” when we have already the two relations: “b:isInputOf” and “b:IsOutputof”? I mean, “inputs” are always
“inputs of” something so… In other words: why don’t we link directly the “activity” and “flow” classes instead of linking them only indirectly via the “input/output” subclasses?
- How do environmental exchanges fit this scheme.? For example how is the emission of carbon dioxide as output from the steel production represented in this framework?
Would we need a different class called, say, “environmental” that is linked to the “flow” class (in the same was the current “product” class is) or would environmental exchanges just be a different instance of the “product” class?
Hope these are not too stupid questions and thanks for the good work done so far.
From: <firstname.lastname@example.org> on behalf of "Matteo Lissandrini (AAU) via Groups.Io" <matteo@...>
Reply-To: "email@example.com" <firstname.lastname@example.org>
Date: Monday, 11 March 2019 at 12.42
To: "email@example.com" <firstname.lastname@example.org>
Subject: Re: [hackathon2019] Start of the #ontology sub-group #RDFFramework #ontology
after the call and the discussion I've drafted a possible schema with an example (please see ).
It is based on the works of :
A) A minimal ontology pattern for life cycle assessment data, by Janowicz et al.
B) An Ontology For Specifying Spatiotemporal Scopes in Life Cycle Assessment, by Yan et al.
The draft is currently incomplete and naturally all choices are up to discussion.
Current feedback include:
- Use OM ontology instead of QUDT
- Use xsd:dateTime requires to add hh:mm to the date.
- Explain the role of Literal in the figure
- Keep track and limits as much as possible the introduction of new terms in the vocabulary
- Limit as much as possible the number of ontologies we refer to
- Use the provo Ontology 
- "inInputOf" does not roll off the toungue
- replacing schema:Place with geonames. The way Place is defined (https://schema.org/Place) is weird and not helpful for our use case
- Consider the ontology for time: https://www.w3.org/TR/owl-time/
- Consider https://www.w3.org/TR/2017/NOTE-eo-qb-20170928/ for raster data
Here are my comments on a couple of points
- Regarding the ontology of units I went for QUDT because it seems more standard (is W3C member), but I leave the final decision to the domain experts.
Here is some relevant material:
1) the paper on OM  and the reviews of the paper 
2) the official websites [4,5]
- It is correct, dateTime requires time, we can use xsd:date. Do we need/want time?
- Literal here is the generic RDF concept of literal values, it has been added just to clarify a doubt that I noted during our last call.
- Regarding PROV-O i have the impression that this is not appropriate. The ontology, as I understand it, is designed to describe 'provenance' in the sense of Data Lineage , so I think there would be a semantic mismatch.
- I agree to use Geonames as URI for places, but as ontology I've investigate the definition, in Geoneames places are of type <http://www.geonames.org/ontology#Feature> which is defined as
a owl:Class ;
rdfs:comment "A geographical feature"@en ;
rdfs:subClassOf schema:Place, geo:SpatialThing ;
owl:equivalentClass <http://www.mindswap.org/2003/owl/geo/geoFeatures20040307.owl#GeographicFeature>, <http://geovocab.org/spatial#Feature> .
So it is rdfs:subClassOf schema:Place , this is why by adopting Schema Place we allow for the widest interoperability.
Please let me know your thoughts/feebdacks on these.
Note also that there are example use cases that are currently not well addressed by my draft, e.g., storage of goods.
I'm also not sure about the class name "ReferenceFlow", the way I understood it is probably better described by "ReferenceOutput" ?