updated uml also with qty and time #485
Conversation
|
👎 to this also for instants OWL-Time has |
I don't want all those time properties cluttering up the flows, and there will be more. We won't have the luxury of having the owl time vocabulary accessible but not explicitly defined, outside of rdf-land. owl time recommends using hasTime to reference the TemporalEntity in such cases, if I read it correctly. I'm not suggesting this is how we do the rdf definition, that you already set up. Just trying to translate that over with the least deviation we can manage. Might be confusing that the UML diagram has all the vocab prefixes in it. I like that because it shows how the other vocabs can be used specifically for things VF needs. But also the UML diagram is for non-rdf implementations. Hmmm.
We can't use inXSDDateTimeStamp for non-rdf implementations, XSD means nothing. And its a terrible name semantically. I could make up a new name? I think you talked about aliasing. |
Also, I'm not putting flows as subclasses of a time interval or instant, that makes no sense in the UML sense of subclasses, as we have discussed at length. Bunch of trade-offs. |
One can use properties on any instance without defining any of its classes as subclass.
I don't see how it clutters anything. Let's also keep in mind that one can use any numbers of properties from any vocab on any instance. While applications can require that instances conform to specific shapes, they can't assume anything about additional properties an instance use. |
That is not so true outside of semantic web paradigm. I also have a sense that semantic web people, with the AAA principle and all, come out of a situation where there is a need to try to make sense of the more chaotic data available on the web, maybe especially in querying for information from many sources. (To be clear, I don't have experience with semantic web in anything real, so i'm sure I misunderstand some things.) But for economic interaction, it seems like people will need to be a bit more disciplined and coordinated on their vocabularies. And there won't be an @context to rely on to find other vocabulary definitions. So in the holochain project for example, I think we will define what people can count on for VF framework (from VF and the pieces of other vocabularies we are using and have documented) that they can build with. In ssb, there will be a set of VF message types that are clearly defined as json-schemas. Those will include what is in the UML diagram, but nothing else. Then as people try to coordinate with each other in communicating between apps, and see what all they need, we can update VF as needed, or add pieces of other vocabularies to those schemas. I think our upcoming experiences will help a lot in seeing how to accommodate different technologies with one vocabulary. I really hope we can get some traction in these semantic web implementations. But we work with people who want to move in the direction we want to move, so will be shaped by what they want to do. |
Could you explain the problem you try to solve with this 'smushing'? I don't think aesthetics of an UML justify introducing this difference. |
The thing I smushed was the one data element in Instant into TemporalEntity. Didn't seem too horrible since Instant is a subclass of TemporalEntity. I can pull it out if you think it is important. Or maybe in the UML model it should be correct, but in say the graphql reference, it gets smushed again. That might be the best way. I also kind of bypassed inXSDDateTimeStamp and used its range because it is not workable in this vocabulary. And dateTimeStamp isn't that great either for fitting in with the rest of what is going on in TemporalEntity. Maybe I should just define a vf name for that, might be better and more correct? Otherwise, I think it is accurate. But in general, I think we do want to pick and choose carefully in pulling other vocabs into VF implementations that aren't rdf based. It can be overwhelming for very little return. It's not about the aesthetics of a UML diagram, but its not unrelated either, because if EconomicEvent say has 6 attributes plus 7 time attributes, which you would always use one or two of, it is confusing to have it flattened out, and giving over-emphasis to the time with no clarity of its structure. I tried to make it more like the way we use QuantityValue. More importantly, if you have a hasBeginning and hasEnd in an event in rdf, you have it set up to know that is an interval because it will infer the TemporalEntity. In other technologies, that isn't the case, and hasBeginning and hasEnd don't have anything holding them together just sitting in the event. So I made it explicit. It's like, here you express the time, you can do it with a TemporalEntity, which has this set of properties, use whichever make sense to express the time for this event. So in some ways it is intended to be more like the rdf implementation, and definitely more true to the owl time ontology. But it makes no difference to how it would be done in json-ld or whatever, which would follow the turtle definition. So I guess there may be 2 things here: the smushing I did do; and referencing the owl time model rather than flattening its properties into event, which seems like anti-smushing? I took a middle path, getting the time elements into the proper model, but condensing the inheritance within that model. I think maybe I should add Instant (in UML model but not graphql and json-schema references) and create a vf element to be sameAs inXSDDateTimeStamp. But I think it is very helpful not to smush the owl time elements into EconomicEvent without the rdf magic to know there is a TemporalEntity. What do you think about those changes? |
This doesn't make sense
I don't understand what 'set up' you refer to. Flow and Process 'hold together'
Not sure I understand what you would want to do here, if you think about defining property which instant can use to reference a Since for all the JSON based things you need to define local aliases for any IRI denoting a term (no matter if from Putting all those nuances aside, could you try to describe what particular issue do you see with using |
Well, trying for one more degree of normalization. And worried we will end up with 10 or 15 of them. Do you think we can stick to just the 5 we have? (without duration). hasBeginning, hasEnd, before, after, and occursAt (or better name)? I can live with smushing them into flows if we can hold it at those 5. |
So hasBeginning and hasEnd have a relationship with each other, making some kind of duration, not just separate elements of the flow. But not really needed, as you say, it is intuitively clear to humans. Thinking about names for the occursAt. Some options: hasInstant, hasPointInTime, hasMoment, hasDateTime, ??? In English, I might like hasPointInTime, it is clear (I think) and makes sense with the other time elements. |
I see no problem to just mention those explicitly. Sine everyone can use any property from any vocab us not mentioning it doesn't prevent someone from using it.
I don't really have opinion, my implementations will rely directly on |
|
ok tried a new one |
|
LGTM except that
|
|
fixed can you update the @context as you suggested for hasPointInTime?
also curious when you use the term 'local' what you actually mean, since it will definitely be used for communication between apps? |
Only between some subset of apps which somehow agreed that they will all use the same local aliases for the terms which in fact have globally unique IRIs denoting them. In broader ecosystem applications can use whatever local aliases that suits them as long as they communicate using global IRI identifiers, for example by providing JSON-LD |
@elf-pavlik are you OK with putting this up into master? I think the only thing in this that isn't decided yet is vf:quantifiedAs. And there are quite a few other small updates and fixes.
But, even if you don't want to merge, could you take a look at how I translated the qudt and time stuff? Thought it would be good to detail that in UML land. I smushed the time stuff a bit compared to the real model. And just used one time field, which can use whatever else we choose to add. Doesn't affect the rdf implementations, which would have access to the "real" quantity and time ontologies.