Re: Open ORG issues

On 2013-02-14, at 11:41 AM, Dave Reynolds wrote:

> Hi James,
> 
> On 14/02/13 15:57, James McKinney wrote:
>> Looking through the open issues, it seems to me that we can close them all (except possibly one) easily.
> 
> I hope so. I do think we are just about there on ORG. The challenge is to get agreement on the few remaining non-trivial ones.
> 
> There are also the formal comments from PROV that need addressing. They don't seem to have made it to the Issues tracker. They are recorded on the dispositions page (which is what I was expecting to eventually use for any transition meeting) but probably should also go in the tracker.
> http://www.w3.org/2011/gld/wiki/ORG_LC_comments

Ah, since they weren't made into issues in the tracker I wasn't sure if they were issues or not :)

"1. We RECOMMEND that ex:o2 prov:wasDerivedFrom ex:o1 be explicitly asserted."

Should org:originalOrganization be a subproperty of prov:wasDerivedFrom instead of prov:used? I think so. (Also, prov:used isn't linking to http://www.w3.org/TR/prov-o/#used)


Re: PROV semantic constraints

The constraints seem entirely reasonable and exactly what most users would expect, e.g. an entity cannot be used after it is invalidated, or it cannot be used before it is generated, etc. I don't think we are describing use of PROV in a way that violates its constraints. I also think if a user plans on using PROV, they should read PROV documents, not ORG documents. I think the links to PROV are sufficient.


Re: use of Invalidation: http://www.w3.org/TR/prov-dm/#term-Invalidation

There are certainly many things in PROV that are relevant to ORGs. Is it the responsibility of the ORG document to describe them all? I think that's a "nice-to-have", not a requirement. If the PROV WG wants to prepare a paragraph about Invalidation, then we can include it. Otherwise, I don't consider it a great loss.


>> http://www.w3.org/2011/gld/track/issues/45
>> "Align treatment of registered addresses between Org and RegOrg"
>> 
>> This is probably the biggest open issue. Can we just remove the range on org:siteAddress, given that there are no really good address ontologies that fulfill all requirements/use cases?
> 
> We do need a range-free version. The question is whether to have a sub-property of that which retains the vcard restriction and, if so, which of those to create a new name for.

If the point of the subproperty is only to limit the range, then I don't think we need a subproperty. If we inspect the object in the ex:site org:siteAddress ex:address statement, the object will tell us whether it is a vcard:VCard or whatever else. We don't need the property to tell us what the object's rdf:type is.

Received on Thursday, 14 February 2013 17:13:04 UTC