Re: Open ORG issues

On 14/02/13 17:12, James McKinney wrote:
>
> 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 :)

I've now raised them as issues to make things clear :)

> "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.

No. org:originalOrganization relates the org:ChangeEvent (aka 
prov:Activity) to the organization you started with, whereas 
prov:wasDerivedFrom relates the resulting organization back to the 
starting organization.

I think the property chain axiom suggested by PROV would be the best 
solution here.

> (Also, prov:used isn't linking to http://www.w3.org/TR/prov-o/#used)

Fixed.

> 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.

+1

> 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.

Agreed.

The whole ChangeEvent stuff it the aspect or ORG where we have the least 
evidence of use. Embellishing it further is not appropriate. We have 
enough hooks in there to allow ORG profiles to go further and use more 
of PROV which seems like the right place to stop.

>>> 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.

Sure. However, the point of a vocabulary is to enable interoperability. 
If your software is going to do something with the address then knowing 
you will always get a vCard enables to write something you can expect to 
work on any non-broken data. Leaving the range open means that consuming 
software has to be able to cope with ... anything.

However, I do agree that removing the constraint is the best option 
here. I'll fold that in as part of a current set of edits.

Dave

Received on Friday, 15 February 2013 17:18:02 UTC