[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Getting Back to Basics - How to describe Dates and Times andEvents?
John McClure said, > I'd support more going the extra INCH to an RDF statement of type. > Presuming that the type is defined by an RDF > Schema statement, which I hope it is, decorated as it can be with business > rules stated using DAML (DARPA's Actor Markup Language) and RuleML. > > <docRef > rdf:type="http://www.ebXML.org/Messages/Invoice">ABC-12345</docRef> > > In RDF, this is equivalent to > > <docRef>ABC-12345 > <rdf:type rdf:resource="http://www.ebXML.org/Messages/Invoice"/> > </docRef> John, Why is rdf better for the SME than the ebXML registry? The URI syntax Martin suggested is completely unambigous. RFC 2396. The ebXML registry provides a unified repository for *all* of the layers of the ebXML protocol stack, sitting in a database, with all of the necessary query and interface decisions optimized for the requirments of various applications and populations of users. Having it all in one place is much more efficient in terms of security, bandwidth, version control, and many other issues. There is a need for realism here. Nobody in ecommerce is going towards RDF. They are all going towards point solutions such as XML/biztalk, or sticking with EDI. Here in ebXML we are *trying* to get people to consider registries (relational databases containing metadata). I am using Martin's syntax in my Code List object, in the software, but not storing it on every row of the GL or the GL schema. First of all, the way we use Invoice number in a GL is just to store the invoice number, not the invoice itself. IMO, the URI to go find the document format is a detail or attribute of a document type, if a system wants to go that far. It is not a field in the transaction row. This goes back to the natural boundaries of a GL. A GL is that minimum necessary view of transactions for consolidated receivables and payables, for cash balance/cash flow, for tax and financial reporting. If you start talking about storing the business doc. itself, you are replicating what is being done on the business system (sales, purchasing, payment etc. modules.) Also- there is little point in URI syntax until there is a registry online and accessible from the internet, with a set of core components and business documents. This could be ebXML or UDDI or any other consortium. I fervently wish that somebody would built the ebXML RegRep, and fix it to include the most important service of all: a shared transaction repository. An STR is a single place for storing the shared elements of any 3rd party economic exchange. They are commonplace in securities and derivatives markets, and apparently in some exchanges like CIDX. A bank is like an STR. Banks are exceedingly efficient, at internal transfers but inefficient at external ones. ebXML is trying to perfect systems of replication analogous to two-phase commit. Which is better? Replication or shared repository? TOdd > Todd suggested: > > > <docRef> > > <docType>Invoice</docType> (required) > > <docNum>ABC-12345</docNum> (required) > > </docRef> > > Martin would prefer the much simpler > > <docRef docType="http://www.ebXML.org/Messages/Invoice">ABC-12345</docRef>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC